It’s right.
In fact, the tests took three months before launching the application. For this, little more than fifty people hired. The work is to access at the same time and raise an order. All timed and with cell phone in hand to communicate what is happening.
This is not a reliable method. You should use professional stress software that emulates true load testing. (If you’re looking for a free one I can recommend JMeter, but there are plenty of paying ones that do it even better).
We ran some tests with some of them on Xojo web to see if it could be suitable for our projects and it couldn’t handle 50 concurrent users. After 25 it started to give errors and most pages were reported as unresponsive (averaging at 15secs up to 30secs, most of the stress bots timed out after 30 seconds). It could handle about 4K of hits spread over 5 minutes with a 3 minute peak load.
Same test written in PHP and Java could easily handle 500, avg 1sec and max response time around 5secs. Handled 100K+ hits spread of 5 minutes with a 3 minute peak load. This was plenty for our projects.
All tested without load balancing, as PHP and Java didn’t need it yet at that point. Achieving the same with Xojo (I guess with scaling, both vertical and horizontal?) would not have been cost effective.
I’m sure plenty of small projects can be done with Xojo, but for bigger ones and certainly one the size like the OP suggested, Xojo is not your tool.
Web1 or Web2? I’ve heard that Web2 got better results than Web1.
Web 2
I agree with you. Hiring people to do tests is not recommended. That way is how my client wanted to do it.
Your case seems strange to me. After twenty-five users, it already began to give errors.
That’s very few users for any small app.
Did you make sure to close the database on every connection?
Yes, and we did not suspect the problem to be the database access, but rather the UI part. We did not run a pure database (with a REST API) test on Xojo, but we did on Java with a single instance (as that is were we ended up with, together with native JavaScript PWAs) and 2.5K SELECTS / sec was not a problem. This last test was a single bot sequentially running random queries. I would be surprised if Xojo couldn’t at least handle a couple of hundreds of such REST API calls per sec too.
The test app was a small Web App (compare it a bit with Xojo’s own Showcase app) and the bots script was very simple: Show a list, enter a search term, click a button and show the details.
I can not show you the full (rather expensive) report as this is company property, but here are some results to get the big picture with a similar load (50 bots), running one instance of the server app:
Xojo Web 2:
Test Duration: 05:30
Bots: 50
Iterations: 9
Hits: 4156
Errors: 248
Avg Response Time: 15.45s
Max Response Time: 30s (Timeout)
Errors reported:
Java + JavaScript PWA:
Test Duration: 05:42
Bots: 50
Iterations: 508
Hits: 306825
Errors: 0
Avg Response Time: 0.63s
Max Response Time: 0.75s
Errors reported:
But as said before, our requirements were for bigger projects (25K users, CRM like WebApps open almost the whole day) and this is probably not Xojos intented size or usage. As others pointed out, the OP could maybe use Xojo’s RAD capabilities to quickly prototype his project. If high usage numbers are indeed reached, there’s plenty of time (and hopefully resources by then) to re-evaluate.
You could be using the same JavaScript PWA frontend, talking to a Xojo Web backend, otherwise you are not comparing the same technologies.
Xojo Web can perfectly play together with dedicated frontend frameworks, like React, Vue or Svelte. Either embedding them with the Xojo Web SDK or exposing an API on the server and consuming it from the browser as a SPA/PWA.
Yes, I was going to say that, I do both with the first framework and it works well. I’d be interested to see Alain’s figures in this context!
Sorry, yes I should’ve added also the pure Java test, not using a PWA. I was trying to answer the OPs question to show in which direction we did finally go for bigger projects and did skip showing a test step.
So but for your comparision (framework 1) I can give you the results with Java (you can compare this with the numbers from Xojo in the previous post). As this first test was not not satisfying enough for us (Xojo 10x slower and errors), we did not proceed into testing the second framework (Xojo - PWA) so I can not give you any numbers about that one.
Java (no PWA, comparable with wath Xojo with UI does):
Test Duration: 05:12
Bots: 50
Iterations: 78
Hits: 42871
Errors: 0
Avg Response Time: 1.25s
Max Response Time: 4.87s
Errors reported:
The reason we investigated Xojo was because of the RAD claim for the browsers side. If we had to write the HTML/CSS/JavaScript anyway to write the PWA, it did make little sense for us to go with the slower/more error prone one instead of the battle-proven Java.
I’m going to refrain now from this topic as I feel I’m in dangerous waters of being banned from the forum, what is not my wish. I’ve given our results and interprete them as you want. Other type Web Apps may produce different results, I do no know that. The main objective of posting these results was to assist the OP by showing him our findings and the process we went through to make our decision.
Note that this is only the essence from the final report we received, which gives you further detailed information and some nice graphs ;-). It defintely is worth going through such a process if you are planning a big Web App. Surprises further down the road are no fun.
It is a question almost everyone has (independant of the tool they use), and is one of the hardest to answer.
I wish the OP the best of luck with his project, no matter what his decision will be!
We appreciate you sharing your experience. I don’t want to derail this discussion but since you brought it up, I want to be very clear that you have never had any warnings or been contacted by moderators that I am aware of so why would you think you were close to being banned? We take banning of people very seriously and have only banned a handful of people (7) for violating guidelines in our 25 years.
It was because of this forum rule:
Do not advertise or promote other companies or products, including posting links, which may compete with Xojo, Inc.
Which is very hard to follow when reporting this kind of thing if you can not name other tools. Thank you for putting me at ease! 
As far as I know, we have never banned anyone without warnings (letting them know).
Edit: Sorry for taking this thread off-topic. Alain, please feel free to contact me privately if you want.
I was deliberately vague due to the same concerns Alain described above. Following Jason’s previous comments I’ll add some more details.
I saw similar performance as Alain from Web 1 and Web 2, and have since switched to a HTML/JS front end and an API backend developed using libsoup in an alternative language. This is comparable to the difference Alain reports above with Java/JavaScript .
This numbers are based on a real world web app (similar to the one OP was talking about) tested with real users in various instances.
If sounds like a mockery, well, it is the actual performace measured.
And dont get me wrong, I used Xojo after all, I just had to fire up 8 instances for the 120 users groups and 12 instances for the largest 200 users one.
Of cours that YMMV with a different kind of app but in my case, more than 15 users and the app started to disconnect some users and had to refresh the page to login again.
It was “OK” because it was known that the largest group was 200 and the server had 12 cores, it ran the 12 instnaces fine, but scalling beyond 200 (again, for this specific app), I would have needed another tool.
You confirm what has already has said.
In summary:
What’s important here is, Xojo can handle various small business scenarios, specially for intranets. And that alone makes it a valuable tool for such niche.
I am following this discussion with great interest and am very grateful for all the attempts to clarify the position.
Just to jump in the ring and bring my 2 cents worth of experience 
I currently use a Xojo web app as an API backend to handle around a million https rest connections per day with a fair amount of data. I understand it’s not the same as having a user facing web app, but my setup is fairly scaleable and may help seeing that some things we think cannot be done may be accomplished by having a good architecture where Xojo is a part of the solution and other pieces can be incorportated.
I have a 2 (for redundancy) haproxy load balancers facing the internet runing on Debian. They handle SSL termination and pass the connections to the backend servers.
I have 5 backend servers, all Mac Minis running MacOS. Each server has one instance of my webapp per physical core to take advantage of all the power in the machine. The Minis do a lot of local caching so that they each will hit the database once for a given information and they will hit the apache server once for any given media file.
I have 2 Postgres databases, one master and one hot standby.
I have an apache server to handle static media files (mps audio and mp4 video) and some static text configuration files.
My setup scales fairly well. I have done it and will do it again as our traffic increases. Simply add more Mac Minis as backends and add them to haproxy load balancers. The database can be replicated and the load distributed among instances. The apache server is fairly idle as most files are requested only once per backend instance and then cached.
In my opinion, no matter the technology/language/framework, the most important thing is to plan the setup to be scaleable from the start, and no single tool will be able to handle all the required parts.
Again, just my two cents.
Again it’s not the same as a full GUI Xojo web app.
But my setup works, and has been working for years, reliably. And I would dare say the project of the OP could be done with Xojo. It’s not a matter whether Xojo can do it or not, it’s a matter of planning the architecture. As it would be with any software or language.
… now I’m ready to be shot at !!! Remember, I’m just a guy trying to help !!
If you add on top of that a CDN such as Cloudflare, the server will be idle most of the time.
For one of my apps, the backend is an apache server, thanks to Cloudflare, 25% of total bandwidth and 10% of API requests are cached.
18M api requests per month and 30GB bandwidth.