Do not set the value too high as it will increase memory and CPU usage. This is not the number of maximum users as the number of connections does not map one-to-one with the number of connected users. The maximum number of allowed secure connected sockets. You can use these integer values: 3 (TLSv1), 4 (TLSv11), 5 (TLSv12, the default). You must specify this port via the command-line in order for the web app to allow secure connections.Īllows you to specify the type of security used.
The port the web app listens to for a secure connection. The default is 200. If you do not want any unsecured connections, set this value to 0. The maximum number of allowed connected sockets for unsecured connections. This can be used to change the port that was used to build the web app. The standard (not secure) port the web app listens to for a connection.
#XOJO WEB APP FULL#
mywebapp -secureport=8100įor full details refer to the WebApplication page. You can use these command-line parameters to change settings when you launch the web app.Īssign values to the parameters using the = separator, not a blank space. If you have the port set at 8080 for example, then you can access the web server using the URL followed by the port like this:įor more specific information about Linux, refer to UserGuide:Deploy Web App to Linux. To make it easier to launch on a specific port, you can include the port as a command-line parameter: You can run multiple stand-alone web app on the same server, but each web application has to be listening on a unique port and must have unique Application Identifiers. This command runs a standalone web app on macOS or Linux: To start a stand-alone web app, you launch the app from the command line, terminal or ssh connection. This web server listens on the port specified in the Shared Build settings. When you create a stand-along web app, you get a single app that consists of both your app and a standalone web server.
In addition to differences in how they operate, they are also deployed differently. You can create three types of web apps, Stand-alone, CGI and Xojo Cloud.
#XOJO WEB APP SOFTWARE#
BANano 4.50 released and Anywhere Software drops a bomb!.There is little point in evaluating the other things in Web 2.0 without this being addressed first.Īmazing #BlackFriday 50% discount on #B4i until November 29!Ĭoupons:… /i/web/status/1… 1 week ago
Anyhow, action will be needed from Xojo if they want Web 2.0 to succeed. Maybe HTTP/2 could help a bit, or WebSockets, or doing stuff in batch making less requests? Or maybe there just isn’t one quick fix and going back to the whiteboard and rethink the whole event system is the only right decision in the long run. I can’t see an immediate fix for this problem. As demonstrated in my previous post, adding 100 components does 200+ roundtrips to the server, it even happens for events like shown and hidden. That is why the golden rule is: avoid many roundtrips to the server at all costs!īut here is the rub: this is exactly what Xojo’s event system does by design. You can not assume your users are living next door to your server. Well, of course that may be a variable in the equation! But, this is something EVERY web app builder has to take into account. Xojo is giving as the main reasons for such slow behavior the distance from the server, latency, number of hops and the quality of your network connection.