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=175678:@Eric Wilson]Also, if I offload media to another server, won’t browsers object to cross site scripting or something like that?[/quote]
As long as it’s not JavaScript, you should be fine.
Thanks Christian & Greg for your speeeeeedy replies. I have a couple more questions…
-
Assuming folks take quite a while before interacting back to the server, is there any limit to the number of simultaneous sessions a Web app can support?
-
If two different sessions try to reach an app at the same time, does the app queue the requests or is that the load balancer’s job?
-
If two different browsers on the same client machine access the app, won’t that confuse the solution unless one uses ssl?
Thanks again,
Eric
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 instance.
[quote=175729:@Eric Wilson]Thanks Christian & Greg for your speeeeeedy replies. I have a couple more questions…
-
Assuming folks take quite a while before interacting back to the server, is there any limit to the number of simultaneous sessions a Web app can support?
-
If two different sessions try to reach an app at the same time, does the app queue the requests or is that the load balancer’s job?
-
If two different browsers on the same client machine access the app, won’t that confuse the solution unless one uses ssl?
Thanks again,
Eric[/quote]
Eric,
-
10-20 simultaneous connections - I generally plan on 15 max.
-
Load balancer would hold the connection to the client while it waits from a response from a backend processor. Settings/performance vary based on load balancer and setup.
-
Each browser that runs the javascript framework registers as a unique session. You can count those two against the total session maximum. The web app will not get confused.
Hope that helps.
If a the clients are generally inactive, you should be able to get a lot more than 20 browsers connected. The Xojo cloud framework is set for 500 socket connections maximum, but each browser will use more than one when communicating with the server. Each browser tries to maintain a connection with the server all the time , so depending on your app, you should be able to push close to 100. Again, this very much depends on how your app is coded. If you have long running methods, it will be better to create a console app and spawn them off so the main app (and the rest of the sessions) doesn’t get bogged down.
Can we have the reference of the microprocessor used at this moment in xojo cloud please?
There is something that escapes me in these stories of threads.
Accept that a session receives a request, and that the processing of this request takes 3 seconds. As each session is threaded, this treatment of 3 seconds is made in the session thread. Therefore, it should not completely block all other sessions?
OK, other sessions will have little power available, but this thread won’t monopolize all resources of the application? The session thread’s priority level is 5?
Therefore, I do not see why another thread fired from the session thread would improve things for other threads in session?
First of all, because these are virtual machines which exist in a virtual environment, all we can tell you is how many virtual CPUs you have. Rackspace (our current provider) guarantees that apps with short lived processing needs will get the CPU time that they request, so if you have an app which continually uses a lot of CPU time (long running tight loops and such) the appearance of actual speed will probably drop a little. FWIW, this is no different than any other hosting provider. The general rule is that if you are causing an imposition for your neighbors, they’ll step in and police the situation.
Sessions aren’t threaded, requests are. If a single browser makes five requests, five threads are created and to keep things responsive, you need to yield time to the other threads. There is currently no way for you to directly yield the thread associated with the current request, but you could probably use App.CurrentThread as long as you check for Nil first.
[quote=175825:@olivier vidal]-
OK, other sessions will have little power available, but this thread won’t monopolize all resources of the application? The session thread’s priority level is 5?
Therefore, I do not see why another thread fired from the session thread would improve things for other threads in session?[/quote]
The request threads have a default priority of 5.
One of the reasons that threads improve performance is that you’re not waiting for their process to complete before responding to the browser. Let’s say that your 3 second thread is getting data from a user, doing a calculation and then inserting the result into a database. The browser may not need to wait for the calculation and the data insert. Send a response to the client (even if it is a dialog saying please wait) and set up a thread to complete the process, maybe even with a lower priority. With web applications, apparent responsiveness to users is usually the number one priority, even if all you’re saying is “please wait a moment”.
ok, thank you Greg.
For what it’s worth, the concept of helper apps instead of threads is an even better solution in my opinion because when you have multiple cores available, you should get even better performance.
Thanks so much for your replies Greg, Phillip & Christian – this has been very helpful to me.
To maximise concurrent connections suppose the Apps only maintains U.I. states (with no data controls) such that all content requests are directed to external processes or caches: And also suppose an outside load ballancer directs requests to these U.I. Apps running on different cores of a VM: Would this solution become confused if a user wanted to view two instances of the app to access different content in separate browser tabs, or would a user need to switch to private browsing to get a separate framework?
Thanks for your help,
Eric
[quote=175905:@Eric Wilson]Thanks so much for your replies Greg, Phillip & Christian – this has been very helpful to me.
To maximise concurrent connections suppose the Apps only maintains U.I. states (with no data controls) such that all content requests are directed to external processes or caches: And also suppose an outside load ballancer directs requests to these U.I. Apps running on different cores of a VM: Would this solution become confused if a user wanted to view two instances of the app to access different content in separate browser tabs, or would a user need to switch to private browsing to get a separate framework? [/quote]
Each browser gets its own session and depending on how your load balancer is set up, they may even end up on separate instances of your app.
Thanks Greg: But by “each browser” do you mean each browser window, each browser tab, each private browser, or all of them?
All of them.
Excellent, thanks!
Will the limit of concurrent connections increase when the move to 64bit occurs?
I’m curious what people are using for their load balancers? Pound? LVSP? We’re testing out an inhouse use web server that (if it all works) will run a xojo app, it might have as many as 100 simultaneous connections, and I’d be interested to hear about load balancing techniques that would also keep sessions on an existing path to prevent cross server scripting issues…
I’m using HAproxy for load balancing a WE stand alone app with the tutorial by @John Joyce
http://john-joyce.com/xojo-and-load-balancing-with-haproxy/
I’ve also enabled SSL termination with HAproxy to enable SSL in a simple way.
Works great so far. I’ve not tested it with that many users but it connects to the least busy node at least 
Also check out the tip on how to start multiple app instances on different ports really easy here: http://john-joyce.com/xojo-and-load-balancing-with-nginx/
Great info, thanks for the links!
Memory isn’t the limiting factor
Not necessarily. The limiting factors are a combination of processing power, memory and the ServerSocket itself. When we initially tested the framework in the fall of 2010, it was found that they behaved best with a maximum of 200 concurrent connections, and all of the defaults were set that way.