Here’s a topic idea for XOJO bloggers. Do a stress test (speed, concurrent users, etc) between Web1.0, Web2.0, and maybe a few other web platforms (B4J?). I’ve searched around and there doesn’t appear to be anything like that available.
It’s surprising to me that performance isn’t discussed more often. I found it to be quite an issue with Web1.0 but had to figure it out myself after building a project. A little late in the process to realize you can’t build the next Amazon with it (kidding of course, my projects were always small and meant to be so).
Any takers?
Alain did some initial tests for web 2.0 in his blog (Xojo 2020r1.1 Update: Web 2.0 evaluation continued – Alwaysbusy's Corner), but I don’t know if he would be willing to spend more time in it and do like stress tests comparisons between web 2.0 and for example BA4nano.
For B4J (aka Jetty Java), we let a professional company do stress tests on our HTTP/2 Webapps. For the WebSockets app (with ABMaterial interface in the browser for the users) it could handle up to 500 concurrent (as in simultaneous <2ms) requests without a problem. From 500+ a slowdown was rapidly notable and at 750+ it became not usable.
Conclusion was that one physical server would be able to easily handle 25.000 users (normal request usage with a new request send > 2ms after the response of the previous one) for this particular webapp. We have an agreement with our host provider they will add physical servers on the fly to join the pool and load balancing should kick in (we insisted as we wanted maximum performance for our users) but haven’t had a report from them that this had been needed yet.
For our REST API (also B4J/Jetty Java), 2000+/sec requests (mostly MySQL requests) was about the limit they could test (after that it was MySQL that started to get to its limit e.g. on INSERT queries, not the WebServer).
Stress tests should really be done on a WebApp basis as numbers can greatly differ between them. Jetty does a pretty damn good job.
This was not really a stress test (one should leave that to the professionals but it is expensive like hell), but my blog post was just to point out a serious flaw in their event design that would prevent them ever to get good results. No idea if they since tackled this problem, I haven’t read anything about it in their release notes.
BANano will probably be more in the range of the REST API test, as all user interaction is handled on the Browser side, using Jetty mainly as a backend for the database connection.
2 Likes
As far as I can say is that under this conditions Web 1.0 and Web 2.0 are dead with 100+ Connections while a Jetty Solution will stay alive at 500+ users. It depends on the use of the Database while the Jetty Server can handle much more than the Mysql Database. But on the other side: we have done a stress test like this on an ISeries Machine (IBM Iseries 7) where the Border was reached at 5000+ user connections. It depends on the Hardware where Java will always win against all other languages while the implementation on Iseries is a charme and Xojo App would not even be able to run on. So the result is: you can write with Xojo if you plan around 300 concurrent users with a medium Database use. If you need more, Xojo (Web 1, Web 2) will not be your platform or you do load balancing one more servers. That can be a solution but it helps not that much. I prefer therefore Java Jetty Solutions from the beginning.
Are you sure about this number for concurrent (as in: all 300 requests all done simultaneously, Jetty only can do about 500 of those)? 30 concurrent seems like more realistic for Xojo (or about 300 user connections where requests are more spread over time).
Under realistic conditions I mean concurrent users as users online not like under Stress Test conditions which would mean: users which concurrently using at the same moment the Database. It is a description how many users you could have under normal conditions with a Website you wrote under normal conditions. Jetty I was testing with full stress what is not possible with Xojo. But if I would write: Xojo fails the full stress tests I would get post from the cool aid drinkers which would say: Xojo can do thousands.
On the other Site I can say: with the same Application I can handle with GWT and REST API under the same use and Server conditions with Java around 60k users where Xojo can handle 300. But that is from some reasons not fair. First: they can not say I want a JavaScript or Java as the base (Vaadin allows both). And so I was testing a Java Server Face with a not optimized Codebase. If I am optimizing I have as Result a frontend Application as JavaScript and only use the Database Server. That depends. On Series I could have so a Load of 100k users without any problem while my Site is JavaScript and deployed to the client as is while Xojo would run behind. But we are not living in a world where they can do this.
Ah ok, I consider concurrent as really accessing the same resource simultaneously. In realistic conditions I do not use the term concurrent, hence my confusion 
. No way Xojo could get in the same neighborhood as Java.
Exactly. Our Java stress tests were done from the client request right up to the page being rendered in the browser. Something that is (as far as I know) not possible with Xojo to benchmark, but as one just manually surfs to a Xojo WebApp and let it fully render, it is immediately clear Xojo can never match Java (it is scary to look at e.g. a Lighthouse Report generated for their Showcase WebApp with a 29% performance score compared with 90%+ (often a 99%) score for a B4J/Jetty WebApp).
You are correct that Stress Tests are in many cases no way realistic, but that is just the point of them: at which point will my WebApp start to fail? This is extremely valuable information on which one can prepare the hardware en load balancing strategies, especially if one talks about WebApps where usage will grow big and fast.
We are in the business where our users really rely on fast and accurate data pretty much real-time (tens of thousands of handheld scanners send lots of data to our server, where separate tools process the incoming data) and thousands of project managers, planners, suppliers have to track this data to take quick actions in our WebApps. This really would not be possible with Xojo (and probably is not made to do so).