Hello,
Working a web app for a client that needs to be able to handle 50-100 simultaneous sessions (Yes, simultaneous). Each session has its own MySQL connection and calls to it have been kept minimal. Most of the heavy lifting has been off loaded to a different desktop app (This will be a console app in the future). The web app is running on OSX, what tools, aside from command line output, do people suggest using to try and figure out what is going on? How much memory the app is using, what parts of the app are using the most memory? Etc? Any advice would be much appreciated.
I asked a question about scaling in 2015 as part of this thread:
Xojo Inc.'s Greg O’Lone said:
If the workload is heavy you will need to load balance between instances. Greg told me:
[quote]
Standalone instances running on different ports with a load balancer in front of them will work just fine. Just make sure the load balancer is set such that each client always goes back to the same instance of your app. Since we store session persistence info in memory, that’s the only way it’ll work.[/quote]
Christian Schmitz said:
[quote]
another way is to put the app several times on a webserver in different folders.
Than have an entry script which moves people to their instanc[/quote]
As for my company we have chosen to put stand-alone apps in Docker and are currently testing with AWS auto-scaling.
We are just getting started and use the built-in Docker command-line reporting and AWS cloud reporting as well as Linux system monitoring. Our app is made of a lot of Web services so we can see what each component does. However if your app is monolithic I suppose you will have to do different things and watch what happens.
What do you mean by this? AS in, client request comes in, load balancer connects them to instance A of the app, make sure they stay with instance A?
How are your tests with AWS going?
There are three ways to deploy a Xojo Web app;
(a) “stand-alone” executable which is a mini Web server.
(b) CGI application for use with an ordinary Web server.
© using Xojo cloud.
We use stand-alone in Docker containers. Deployment on AWS has been fine so far. The AWS load balancer sends requests from Web browsers to the right instances automatically as one would expect. Most of our Web services behind those instances are stateless but we have figured out sticky sessions for those that aren’t. It’s early days and we are still writing many of our Web services but we are discovering some really nice synergies between creating a distributed Xojo Web app and AWS services such as their distributed file system. And by breaking our app up into Web services we can work out the cheapest/best server type for each part of the system.
We don’t use different ports for each instance with AWS because their infrastructure handles all that kind of plumbing! Docker Swarms will do the same kind of thing if one has the time to learn the ins-and-outs. For us they offered no advantage over AWS and we can go back to them at any time and AWS has better monitoring tools than Docker Swarm.
If your client only has 100-50 user’s and it’s unlikely that number would expand to thousands, I would recommend running two or three stand alone instances of your WebApp on a single host. Use HAproxy to handle the load balancing as it supports sticky sessions well.
Here is a thread with some more info
https://forum.xojo.com/42926-standalone-app-listening-on-multiple-ports
Let us know how you go!
I’m doing loadbalancing on a Linux server by using haproxy in front of several instances of a standalone Xojo webapp.
Haproxy takes an incoming request and distributes it to one of the instances and maintains the connection to it.
You can install haproxy on macOS as well:
http://macappstore.org/haproxy/
There used to be a helpful blog post of John Joyce on how to setup Haproxy for Xojo Webapps, but I no longer find a readable link to it, at the moment.
Wayback Machine is your friend in those cases 
As said for one client we simply send them to a short link which is a php script which distributes them with a redirection to one of 4 instances.
Just IP as number mod 4.
Usually we have just 2or 3 active per instance and no problem.
The apps are mostly idle presenting forms for users to fill. Only if several would create pdf at same time it may cause wait times.
Best to have enough instances to give everyone their own in average.
@Christian Schmitz do you mean that an instance can hold only 2-3 clients?
This depends on your app and what you do.
An app which is mostly form entry can be easily handle 20 people.
It depends how many people do something which may block others.
And how many people should be kicked out when one crashes the app.
not really ideal scenario for a business application. in these conversations there is always the doubt (or perhaps the mystery) if a Xojo web app is suitable for use, especially if distributed on a geographical intranet.
As with all tools it depends on how the app is written. However one must keep in mind a Xojo Web application relies more on server-side processing which provides faster development times, preserves the developer’s IP in the code, and can allow better UI state management. The trade-off for these benefits is that Xojo Web requires more server resources to make all this happen.
However requiring more resources does not mean unscalable and does not mean unreasonable. It means for intensive UX Xojo-web should be considered part of the presentation layer in the application architecture such as talking to other Xojo Code (e.g. via Rapid Services ) or shelling out to a Console app to launch longer-running jobs on a different core.
So by using Docker with Swarm or AWS there’s no reason I can see why linear scalability cannot be achieved with Xojo. In terms of resources and benefits, I regard Xojo Web sits somewhere between ordinary Web browser execution and Remote Display Protocols. That middle ground can be a very productive place to be!