Hello all!
In the best weeks, I will have to start developing a new web-app for one of my customers.
This is a huge Company that may have 500/700 operators using the web-app concurrently.
One of my first task, is to set up the server.
My web-app will be used to manage textual data (no images, no heavy calculation), how is the minimal hardware and software requirements? The server will be Linux-Baden and will have cubesql server to manage the database…
Many thanks for all your suggestions!
You are going to need to run multiple processes and load balance across them for that number of concurrent users.
I’m worried about this problem! could be nice to to explore this topic, which I think could interesting for many people and with increasing importance for professional projects.
For example how run multiple processes? and how load balance across them?
Thank you for any contribution.
It’s great to see it’s a good topic. Let’s wait for more details from the other users…
Search for “load balancing” (with the quotes) and you will find lots of threads with plenty of valuable information.
Ok for the load balance, and let’s assume that we can manage X different web-app that will be virtually the same app, on the same server… how can be the minimal server hardware in a situation like that?
I’m sorry but I cant’t reproduce a situation like this (5-600 users online) to stimate the cpu/ram usage…
Thank you!
i’m also interested in this!
Many thanks for all your suggestions!
[quote=144405:@Sergio Tamborini]Ok for the load balance, and let’s assume that we can manage X different web-app that will be virtually the same app, on the same server… how can be the minimal server hardware in a situation like that?
I’m sorry but I cant’t reproduce a situation like this (5-600 users online) to stimate the cpu/ram usage…
Thank you![/quote]
Difficult to say without knowing what the app does. There does come a point in time where users will start to lose their connections to the web app. That’s the point where you have exceeded the maximum for that process.
Let’s say it takes 1 second for the single core aware Xojo app to respond to you pressing a button. Let’s say the timeout is 30 second before the app thinks its been disconnected. If 31 people hit the button then the 31st person will get disconnected because the app did not respond in a timely fashion.
That is extremely over simplistic though. For instance we don’t know (or I don’t know) off hand if the app forcefully does a “ping” to active connections to remind them its still around. That would only slow things down but not prompt a “disconnect” notice. Things would still take an epically long time. Then you have to consider how many active connections the Xojo app can handle at any given time never mind the processing of the events and responding to the browsers. I mean simply how many connections can be opened simultaneously before it spends more time managing the connections than actually processing the requests.
This is all fairly difficult without an example app and a testing toolkit. That being said there are two ways to do this:
1 is easy.
2 is harder.
I wish Xojo would stress test the EddiesElectronics example file.
The basic solution is to simply distribute load across multiple processes and servers. That’s the load balancer solution that has been suggested. This is also a problem for database servers and there are various solutions for handling a lot of connections to a database server as well. I’d also recommend researching that a bit. Depending on how your app is written you could easily overwhelm the db server with 500 or more concurrent connections. It would be best to look at that before deploying and running into trouble after users start working on the system.
I agree completely. Until Xojo provides some metrics as to what Web can handle and provide some real working examples it is unlikely it will gain as much traction as it could. To spend all that time to develop a product and not provide some useful criteria and blow it off on “every case is different, proceed at your own risk” is astonishing.
Right now a potential user has to spend way too much time researching and buying resources before they can even figure out if Xojo Web is the right product for them.
Right now, Phillip seems to be the resident expert on this and provides the most helpful advice. It sounds like he has spent a lot of time researching and experimenting with Web to discover it’s capabilities. More of this really should be coming from Xojo.
Xojo is being marketed as an easy solution to bring a desktop app to the web. But by doing this the next natural question is how many users can it support? When the user starts hearing “It depends” and all this talk of load balancers, CPU cores, bla, bla it suddenly doesn’t look so easy.
The whole reason and business case for cloud computing is scalability, but Xojo Cloud doesn’t really offer that, nor do they say what it will handle.
I doubt this will be his weak link. There are databases that can handle thousands if not hundreds of thousands of transactions per second. Most database services, especially the new cloud based DBs will clearly state what they will handle and what they wont, and scaling is very easy now. Xojo needs something like this, otherwise it simply will not be taken seriously for business apps.
Anyway that’s one potential user’s perspective on the situation, take it for what it is worth. I wish it was different as Xojo Web seems like an interesting proposition.
Keep in mind scalability never comes for free. There are some architectural aspects of Xojo web apps that make them tougher to scale. For one it’s a persistent process unlike say PHP which can fire up multiple instances. As a persistent process its unable to access multiple cores. It also has no shared session state meaning if you do load balancing you need to use some form of sticky sessions.
Those caveats are not insurmountable however. I’m not 100% sure Xojo has to identify performance characteristics. Maybe with the Xojo Cloud they should try but certainly not for the web development framework. Truth be told how you use it will be the number one contributing factor.
For instance if you create a “clock” where each second a timer updates the label then you are encouraging a large number of requests depending on the number of users. Just because Xojo Web provides the ability to have very desktop like apps does not mean you actually want to wire up all the possible events. Then again maybe you do… trial and error and some insight into how web apps work and whats going on behind the scenes will help you tremendously.
When someone asks “well I’m going to have 500 concurrent users” I know immediately some load balancing is going to be needed. Could you do this with a simple PHP installation on Apache? Perhaps. You might spend 100x more time developing that solution however. I believe developer time is more valuable than hardware costs. Get the product in the customers hands faster and you will have a happy customer. The load balancing issues can be solved.
Sergio,
Here is some information I put together on this topic. Let me know if it helps:
http://john-joyce.com/xojo-and-load-balancing-with-nginx/
http://john-joyce.com/xojo-and-load-balancing-with-haproxy/
John
All of the load balancing topics seem to point to standalone apps. Is there any additional information/tips for cgi apps or on Xojo cloud?
(disclaimer: I was at the XDC load balancing session, which is where a lot of these topics seem to end with “you should have just been there!” The session focused a lot on testing load balancing rather than implementing, which is why I’m asking these questions here)
CGI load balancing is kind of a complex topic. To be honest there is very little benefit to do it because you will get much better performance out of standalone.