Imagine a small app that has very little transactions. A couple of request from a database at the beginning and one post to the database at the end. Has only 10 forms, mostly small. Some complex logic to redraw a screen based on data received, but nothing to write home about.
Assuming a well configured server like: 1024MB VPS RAM, SSD Disks, Good bandwidth.
Question 1: if to be used by 1000 users simultaneously, is Xojo Web able to handle it? Question 2: at what point do you need to start getting creative with load balancers, memory and so on?
It’s really going to depend on the actual app and actual deployment system. For example, if you have some event handler that sucks up time and doesn’t yield, it will bog the app down due to the cooperative nature of the threading model. Another example, if you have a page with a WebTimer firing every second, 1000 simultaneous users will generate 1000+ requests per second.
So the answer is… Create a load test harness. Test early and often. Benchmark like nobody’s watching. Track CPU and memory use. And don’t underestimate bandwidth requirements.
Also, you will probably save a lot of overhead by deploying stand-alone. For most apps, that alone should near double capacity over CGI deployment.
I guess my question is that I know how to measure PHP apps and similar stuff. I have seen lots of sites build with those kind of languages, but when it comes to XOJO Web, I haven’t seen strong guidelines and examples for implementation beyond company wide use. I am sure there are tons of examples and people doing it all the time, however I haven’t seen it.
Is there any documentation on this regard that you are aware of?
Any generic documentation on this is necessarily going to be complete BS. Comes down to the task/threading model. With PHP, you have the benefit of the OS’s task manager keeping any particular operation from getting out of hand and affecting responsiveness to other clients. You don’t have that with a Web Edition app. Perceived performance of a Web Edition app is going to be highly dependent on the code in it.
And that’s not all bad either. Design-wise, the cooperative threading in Web Edition is more akin to nginx’s no-thread approach than the threaded and forked approach of Apache.
Andres - I wanted to chime in here as well. I come from a PHP background and one thing that definitely came as a change to me is the way that Xojo is, by default, limited to a single core of a single processor for handling all it’s connections and tasks. That means that you as the programmer are responsible for determining the way that your applications scale across multiple cores/processors and utilize system resources. In the world of PHP, much of these concurrency issues are handled by the web server in a typical setup. So by contrast, in Xojo, it is quite easy to create a web app that does not take full advantage of all system resources. By investing the time in trying different development techniques and testing, you can drastically improve the performance of a Xojo app. The key is in delegating tasks - either through using helper apps (via the shell, or IPCsockets for instance) or load balancing with something like nginx as a front-end proxy - or BOTH. Of course, the code specific to your app can create bottlenecks within it as well … small changes can make drastic differences. Again, testing is important.
Personally, I have found load balancing between instances of a stand alone app to be the simplest to implement, because it lets me develop one Xojo app and then multiply it across as many server cores as necessary. But, helper apps are something that I am exploring currently, with IPCsockets. It is new to me… At least, it is good to have options!