Multi-user web app with a great many simultaneous users

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. :wink:

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… :sweat_smile:


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. :smiley:


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.


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 :wink:

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.


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.

What would be the advantage of keeping Xojo only as a backend at that point?

@Bruno_Frechette, thank you, I’ve no objection at all to learning whatever techniques are necessary if they work efficiently, are well and clearly documented and are going to save me time and money.

I’ve been following this discussion with great interest. I didn’t expect my question to attract as many answers in such depth as it has and I am grateful for all the comments. It has been very useful to me and I hope it helps others as well.

Someone may be very familiar with the use of a hammer but that doesn’t mean he should use one to bash in a handful of screws.


If you have a million concurrent users idea but nothing in the works now you are missing the opportunity to grow sooner.

If you have experience with Xojo Web and nothing else (but you are willing to learn), I will say that one good approach is to create something that can start growing and give you some money in return.

At some point in that growth you either: learned something that will handle the load with fewer resources or you have enough money to pay a team to do it for you. If your idea is good enough maybe you can even get some funding for your new company and get the money to grow faster to that million or more concurrent users.

I don’t think many successful projects started by knowing exactly what they will be using 5 or 10 years from now. They started small and they grew by adjusting what they use to be able to support all their users.

On the other hand, if you don’t know Xojo web enough to create your idea into a product, then maybe find someone that can do it for you using some more used tools, at least you know that you may need a team and will be easier to find coders that know something else.

In short, don’t wait until you know exactly what you need when you get to one million concurrent users. Work on your idea. Fund your idea. Make a profit sooner. Good luck.


A Xojo backend (say with Aloe-Express) could provide possible code reuse for desktop and mobile versions.

1 Like

But you’ll want the more recent version:

Anyone has empirical results on the performance of Aloe Express vs plain Xojo Web app?

If it is better than plain Xojo web app, especially for micro web services, it would be interesting.

Both are still Xojo based.

I am not familiar with the Express which @Greg_O linked, but the original AloeExpress was a console application so needed a different Xojo license than a Xojo Web application. You could also add the AloeExpress modules to a Desktop application. I have done that in the past to add remote API access into what is otherwise a Desktop application. I don’t believe that it works with a Xojo Web only license. Or at least I don’t think the original AloeExpress did.

But I think Xojo’s WebApplication and AloeExpress (and Express??) are targeting different use cases.

AloeExpress (and Express??) are aimed more at non-UI access such as exposing an API while a WebApplication is aimed at users connecting from a browser or more generic “web server” usage.

At least as I understand it.