I understand there are many problems surrounding multi-user Xojo web apps including latency. Also I read that there is likely to be a maximum number of simultaneous users in the hundreds. If I wanted to work on a project that could be expandable to a very large number of simultaneous users - up to say a million or more -does this mean.
I should forget about doing it in Xojo.
I should forget about doing it even with Xojo running a coordinating app and JavaScript handling all the browser activity.
I would need to build the app in some other language altogether, for example???
To do this, I would need to use a specialist server service company to provide the hardware.
To do this, I would need to have my own dedicated and administered server likely to cost in excess of ??? per year.
I know there a lot of unknowns here so if you think my question as it stands is unanswerable donât bother trying to answer it. Thanks.
a million concurrent users? woah⊠what type of web app are you planning to build?
by the time you reach a million users, your app should be profitable enough to hire an entire team/department and build/migrate the app to any language on this planet
Are you talking about one million total users, or one million users accessing the site at the same time? Those are two very different questions. Especially if those million users are distributed across the world.
Thank you for those responses. Adam, you seem to suggest it is do-able in some language without suggesting which one. Do you have a suggestion? Gabriel and Tim, I wanât envisaging starting off with anything like that number of users but beginning something that would be eventually expandable to something very big given the resources, and and âa million usersâ was just a for instance.
I was contemplating a global quiz and that would necessitate all the questions being asked and answered more or less simultaneously.
The questions could be encrypted and delivered in a period prior to the start of the quiz. I thought the time taken to answer each question could be measured locally between the moment a question appears on screen and the moment a respond button is pressed returning an answer along with the time taken. The answers could be âmarkedâ and collated into a leaderboard after receipt back at the server.
But even if that is all possible, it would mean a huge amount of data flooding in at the server in a short period following the release of each question. This would be necessary to prevent cheating by collaboration over a longer period.
The way I see your app it would need two type of servers:
The database (backend) that holds all quiz questions and answers
The web-app (frontend) that serves questions to the users and gets the quiz answers
The database part could run on a single instance (MySQL, Postgres, MongoDB) and handle thousands of insertions per second as long as they are done per batch (multiple insertions at once).
The web-app could run on several instances with a load balancer. You could even have web apps running in multiple locations in the world to have better response times.
Start small with one web-app, I am sure Xojo web apps can handle a few hundred concurrent users. As soon as you get many users, run multiple instances of the web-app on the same server then scale horizontally with more servers.
Note on batch insertions: when the web-app gets quiz responses, donât send each response directly to the database but keep the responses in memory and insert data in the database by batches of 100 responses, maybe even up to 1000, or once every two seconds.
You might also need to find a way for each web-app instance to communicate with each other for synchronization: presenting the quiz at the same time on each instance.
At that scale, you will face a lot of challenges⊠no matter the language and technology stack you use.
Even if you code your application in Assembly, you will have to scale horizontally. Itâs unlikely a single machine will be able to physically deal with such amount of traffic.
Slower interpreted languages like Ruby, Python or PHP are behind the biggest websites around. See GitHub, Instagram, Twitter or Facebook.
Xojo Web can work as a full stack solution, dealing with the backend and frontend. But it can also work as simple API server, using Application.HandleURL.
You have to invest in a good architecture, the programming language is implementation details. Any can do the job.
Iâll give you an example of a webapp for b2b that at the moment is hosted on a Linode Nanode 1 GB.
This VPS is hosting the following:
The xojo webapp web interface for the users via Nginx
The xojo webapp that handles the API
The MariaDB database
At the moment, the VPS handles @ 46~50 users simultaneously without a problem (thatâs the max I have at the moment and the vps usage suggest I can add a few more). It wasnât easy though and lotâs of optimizations weâre done to the VPS and the coding of the webapp. At the lowest, at least 10 to 15 users are simultaneously logged in and perform some kind of operation that involves reading/writing to the database.
Over 20+ webpages (not instantiated) and more then 30+ webdialogs⊠basically it is a bigâish project itâs what Iâm trying to say.
So, there are more factors to take in consideration then just the coding language.
PHP may be interpreted but it isnât slow. I wouldnât be surprised if its database support and file io was faster / more efficient than Xojo. It also scales better than Xojo on a single instance due to its better use of threading.
Sorry but I have to kindly disagree with your entire reply.
But in any case, I wasnât attacking PHP or any other language. My point is you can scale any web application, no matter the language youâre using (including PHP)
PHP is not just an interpreted language, it has a backend optimization for speed, an RTE with JIT (Run Time Environment / Just In Time compiler).
In the past Facebook used Zend, the precompiled PHP source into opcodes the Zend Engine would read and just ârunâ (call sequences of functions) not needing further âinterpretationâ as the interpretation for syntax and some semantics correctness occurred at the fast âcompilationâ (JIT) phase.
Facebook and their billion+ users faced complexity and cost problems at one point, so they wrote their own âPHP Compilerâ to reach a 5x + speed (the HipHop compiler), not to avoid fails, but to need less active instances. It worked at some extent, but their workflow was affected.
At one point they ended migrating to something they created inspired on Zend. The HHVM, the HipHop Virtual Machine. A non-stop pipeline. Something you input source code, it immediately generates bytecodes that its very fast interpreter can run, and the RTE will compile such intermediary codes into native optimized CPU code that will be used as soon as possible instead of those intermediary codes. So PHP is not exactly interpreted code, it may be, but it can be native very optimized code too.
The difference of Xojo and other languages, is that those languages operates disconnected from the client, when a request comes in they just start a process, reads session variables to the memory, if any, or requested to do so; receive an input stream, process it, returns results, and release the process. So scaling is easier, the session is maintained in another level. But Xojo is a server itself, needing to be there all the time, keeping sessions internally there, needing heartbeats from the client of the session or it dies, etc. Others can get new instances up and down without breaking sessions. Those disconnected designs makes things easier for scaling up and down launching more instances dynamically, never breaking things if the next new instance attend the current session of a client that had its instance dead 1 second ago.
Yes, but nothing stops you from starting with a normal Xojo Web app, then turning it into a headless backend if needed. You can just expose an API and consume it from any frontend framework you like.
If you already know Xojo and you want to create a web application that can scale pretty well, you can. There is no reason to just give up with a language before even performing any benchmark.
And again, Iâm not against PHP (or any language), it paid my bills in the past (from PHP 4 to PHP 8) and did its job. If you compare it with other languages it can be much more slower, while still being able to serve traffic intensive web applications.
I did this in a local scale. I found out that to be reliable enough, Web 1 can handle ONLY 15 concurrent users⊠Web2 is suposed to be better but i havent tested that way, being optimist, lets say 25 users.
Xojo being not multithreaded means that each instance needs to load its own memory, so the hardware requeriments are a lot higher than a multithreaded server. Do the math
As for alternatives, the forum guidelines forbid to talk about any tool which âmay compete with Xojoâ so, asking for it or answeing that could be sanctioned.
Well, unfortunately there isnt an official number of users and every single time someone ask xojo that, the answer is the same, âit is imposible to know, you have to test your appâ
Well, at least my answer is with an actual app with similar requierements, a quiz where all the user loging in at the same time, requesting info and clicking something virtually simultaneous all of them.
What exactly is a âintensive applicationâ for you? All the users do a login at the same time?, click a button at the same time?
For one of my web applications we managed to get 60-70 users in a single web app
instance without any problem. The system draws dashboard based on user defined settings.
I am running on Amazon Lightsail with the help from Lifeboat, 2 servers for a total of
8 processors & 8 web app instances. Lifeboat helps a lot with the load balancing configuration, secure connection and app instance management. Be careful to make sure that your database servers are also properly configured and have adequate numbers of processors and RAM.
If you are not using XOJO cloud, i would highly recommend Lifeboat by Tim Parnell
to help configure the web app instances.
What I have always read, as an answer, is that it depends on the hardware and software that you apply on your server. Look at Ricardo Cruzâs comments.
You can always design a system for 20 or 20,000 or 200,000 users. None of them will have the same characteristics as the hardware or the purpose of the software.
By application intensive, I mean a system that has to deliver data intensively.
I told you about starting working at 7:30 a.m. and ending at 6:00 p.m. About 200 users connected at the same time in the morning.
Scaling is hard. Look at how many major games launch with connection problems on day one. You donât just design a system to handle a million simultaneous users. You build, test to identify bottlenecks, make changes, rinse and repeat.
@Gabriel_L is absolutely right. If a million simultaneous users is even on your radar, youâre doing exceptionally well and will have the resources to hire people to solve problems for you.
You have to start small. Hereâs something to consider. Ark Survival Evolved is extremely successful, and has never hit a million concurrent players.
Thatâs not a metric. Doing nothing connected users or dead sessions not timed out yet doesnât count as concurrent processing.
An IRL test could be: Make a listbox presenting 100000 records from the db being loaded dynamically while scrolling, ask 50 people to run it at the same time and scroll the list. Are they comfortable with the result/speed? Is it acceptable or unbearable? If acceptable add more people to the test until unbearable, try less until acceptable, you will locate some acceptable point that few more users will make things uncomfortable, the saturation point of such architecture.
