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 .
3 Likes
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.
1 Like
You confirm what has already has said.
In summary:
- It is possible to handle many users.
- Point one depends on the architecture design and the application.
3 Likes
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.
6 Likes
I am following this discussion with great interest and am very grateful for all the attempts to clarify the position.
1 Like
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 !!
16 Likes
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.
3 Likes
Of course you can, but that is a lot of hardware to handle just a million requests.
Our Java API handles about the same amount of traffic for a fraction of the price without even needing load balancing yet. At about 5 million/day we plan to start a new instance although tests showed 10 million was the breaking point in peak moments. But we want to play on the safe side. 
Running on one Debian server, 4CPU (4 Cores / socket), 8GB RAM. The Java API can handle about 2500 request/second. Same server also runs our MySQL, Web Apps and a couple of background workers handling various tasks and data.
The server is virtualized so the datacenter we use can add memory/disk, even a complete copy of the server in an instance if it should be needed.
EDIT: Damn I did it again! This is Alain Bailleul. I posted while being logged in on a colleagues PC⊠
3 Likes
Eye catcher phrase. I would say a fraction of the cost (and it includes maintenance and hardware upgrades)
I donât understand the reason for insisting that other ways are possibly more efficient, for example, JAVA.
The original question was: Can XOJO do it?
Correct. Sorry, my native language is not English.
1 Like
The answer is yes, but investing more in the platform to make it so.
Guess what? Idem. 
2 Likes
No, is not. There are actually several questions. One of them is actually about using other languajes, so bringing up the comparisson is on topic. Another question is about Servers, so it is on topic to say, Yes, you can do it, but need 10x the hardware (and the electric bill that came with that)
1 Like
No need to assume your app has the same requirements as Brunoâs.
Each app will vary on its needs, like hardware specs, but also the amount of people required to build, run and maintain the project.
With Xojo Web you can have your solution up & running with a few clicks, either using Xojo Cloud or Lifeboat, and keep growing from there.
4 Likes
Works both ways. No need to assume our appâs requirements are lower than Brunoâs. And our solution doesnât require many people too. Deployment is simple: copy-and-paste.
Deployment is just a step of the process. There is also a build system to deal with, JDK version incompatibilities between dev computers and so on.
If youâre happy with it, cool, thatâs fine.
Iâm surprised this myth is still around! It hasnât more incompatibilities than between devs using Xojo versions. (Web 1/2, the different frameworks over the years, âŠ) But I agree, just like with Xojo, it is best to all work with the same version if you work in a team. And building nowadays is also just clicking a button with a âplayâ icon on it
And to be absolutely clear: I respect Brunoâs solution and if it works well for him that is fantastic! I was only pointing out how we (after a long analysis) came up with a cheap, but very robust solution for us. Everyone takes from it what he wants (or not).
1 Like
@Steve_Hill maybe you should consider the following: what language/platform/technologies do you already have expertise with?
If (like me) youâre already good with Xojo, but not with other tools like Java, maybe Xojo is the way to go. It will work. Even though other ways may be more efficient. Sometimes the cost of learning a new language/platform or hiring people outweighs the additional hardware cost that Xojo could requires.
But if you already have people that code web apps the âtraditionalâ way (or have budget to hire a team) and donât know Xojo, then maybe youâll find Xojo is not to be the best way to go for you.
Sometimes the best tool to do the job is the one youâre already proficient with.
11 Likes
I believe Xojo Web could scale to 1 million concurrent users if the load balancer was smart enough. But at that scale microservices are often more efficient. Xojo Web is a general purpose x-platform custom app tool which doesnât compile to microsoervices. This means it would be more expensive to run large-scale apps using Xojo, which utilises server-side processing for easier control of the end-user experience and protection of the appâs business logic. If this level of customization is not needed then a boiler-plate programming language with minimal server-side processing may do.
Xojo with open-source Aloe-Express can compile to microservices and has the advantage of code being more portable between mobile and desktop versions of your app too. However you would have a lot more work to do on the client-side - write once, test everywhere.
However if you are wanting simple questionaire Web pages I suspect AI will soon do that for non-coders for free and charge for the hosting like survey monkey.