I’m working on the business case for an application that we intend to write using Meteor. Our portotype is running pretty nicely on a min-requirements dev server (512M/1core) on vultr.com.
But I’ve been wondering how many users you can usually serve concurrently using Galaxy. So if you have some experience and can let me know how many concurrent users you have served using the compact, standard, double and quad containers, that would be really helpful.
About the application
The collections are all indexed on the parameters that are used for publications and publcations usually request only 12-24 items at a time. The most complex pages may subscribe to 2-3 collections. I use paging rather than infinite load to reduce the data stored at any time.
All insert and update functionality is done when the user presses save, so the number of updates are at a rather low frequency and no data is changed at high frequency (through automation).
We expect to have up to 200 concurrent users within 3 months of going live, so I want to make sure that Galaxy can cope with that level and won’t cost us an arm and a leg or might require us to consider scaling horizontally.
This has been discussed numerous times on the forum, it completely depends on the complelxity of the app and if the code is somewhat optimized. The only accurate way to deduce the number of connections/server is to actually run some load tests, see this thread: Galaxy: What container size and how many of them should I use?
Now given your description we’re likely talking a relatively simple app with not that many publications nor complex ones. In most cases you’ll be able to reach 300-500 connections per server. I’m talking about a micro instance from aws, not sure what the equivalent is on galaxy, but it’s 1GB ram and 1 cpu and I’m pretty sure they’re using the exact same instances.
It would surprise me if you wouldn’t be able to handle 200 connections on a single server, if so there’s probably some optimization you could/need to do.
In general it’s better to scale horizontal than vertical, most of the time it’s better to start an extra smaller server when you start to reach performance limits than to upgrade your instance to a larger one.
Thanks @nlammertyn
I totally understand that it will require some load testing for a firm assessment.
In this case my key conisderation was simply to get a ball park idea. My other Meteor applications have less than 30 concurrent users and run fine on a 1GB Digital Ocean Droplet. Just I’m looking for a way to ensure I’m not anywhere near a level that is critical or that Galaxy might perform significantly different to a mup based setup.
Based on your response and the link you sent, I’m pretty certain that my estimate of 50c per concurrent user per month should be something that’s in the right ball park.