if Session.SessionCounter is relevant, what is the maximum number that a CGI application can reasonably support?
beyond this limit (and in the absence of a load balancer), is there any way to automatically switch new connections to (one or more) other running webapps?
See blog article:
It’s better to have 4 copies running, so if something crashes, even with only 4 visitors, one doesn’t take down the other’s sessions. How many people can go on one instance, depends on what your app does.
By default, a CGI app should be able to handle about 50 concurrent users if the app isn’t too busy. It’s a tricky number to nail down because it has a lot to do with the other things that your app does.
You can increase this number to some extent by modifying the args array in the app.Open event like this:
The number of sessions is about that number divided by 4. So 300 would be roughly 75 sessions.
thank you both.
I’m trying Christian’s solution.
It seems to me that if I use different names for the webapp:
(e.g. $StatusURL = “http://127.0.0.1:9090/cgi-bin/myapp".$x."/myapp".$x.".cgi”)
it works regularly.
but if I use the same name:
(e.g. $StatusURL = “http://127.0.0.1:9090/cgi-bin/myapp".$x."/myapp.cgi”),
there are problems with the ports (“Application launched, but unable to connect using port…”).
is it possible or am I doing something wrong?
They must be separate names to avoid conflicts.
Each launch makes a mutex file in the temp dir using the app’s name. It’s used to know if the app is already running when the next request comes in. Even if they’re in different directories, they must have different names because they use the same temp directory.
Wouldn’t it be a good option to take complex and time consuming business logic out of the webapp itself and use a named pipe or other type of connection to another processes running the heavy stuff?
can you give some examples of how it works?
However, apart from the distribution of tasks, I may have many almost simultaneous requests for access to the webapp.
my first fear is the high number of open sessions.
thanks again everyone.
one more question:
does the problem of overload caused by too many open sessions also exist for the own web services created as Xojo’s CGI webapp?
if so, is Christian’s solution (or something similar) applicable?
My reply was just a question. I know how to work with helper-applications so I thought it might be an idea to give a web-app more time to handle sessions rather than keep them busy doing heavy domain-logic stuff.