Scaling Meteor/Galaxy: Sessions per container?

Hi folks! Scaling question: how many concurrent sessions / connections do you expect to get out of a single Galaxy container? I realize this is highly variable depending on the application, but just curious what sort of usage others expect from Galaxy or other hosting services.

Im not sure what is the limit of sessions per container but in my current setup we have a Standard container and we get around 250 concurrent sessions consuming 42% of RAM and in a standar of 0.30-0.70 ECU.

This is a VERY variable question, there are factors that can make this 1k times or 10k times different. It would be cool if people described their app architecture a bit.

  • Do you use pub/sub heavily?
  • How much data loads on your client?
  • Do you use Blaze, React, Vue, Svelte, etc.?
  • Do you use Methods over Pub/Sub when you don’t need Pub/Sub?
  • What size of containers are you using? (see graphic below)

It would also be cool for people to share screen shots of their APM dashboard to give more details too.

What I’m hoping is that we prevent “dogma” about this answer emerging :grinning:. Then everyone will start to talk about how you can only get “X” connections out of a container, which is just not a good way to look at things. You can get “X” * 1000 connections out of a container if you optimize your app and use best engineering principles for what you are building.

But I do like the goal of sharing our performance if we keep all focusing on how we can improve it. But obviously have fun with this. Would really be great so see answers to the above questions!

And also please read this too, along with other APM Docs and share you “favorite optimizations”!

Where did you get the most performance gains?

Hey, I love this topic! Performance is really important and Meteor can deliver great numbers without giving up on delivering amazing features.

About Galaxy, as you probably know Galaxy runs on AWS, using ECS then your containers are running in a very reliable provider. The best part about Galaxy when you talk about performance is that you can receive insights from people that really understand Meteor internals contacting support :wink:

Talking specifically about your question, as others have said it’s impossible to answer a number, this depends a LOT more on your code than on Meteor or Galaxy or servers. And that is the case not only for Meteor, for any application written in any language/package system. How many users an application written in Java using JSF as a view layer with PostgresSQL as database can handle per container of 512 MB? I worked more than 10 years with these technologies and still today I can’t answer this question as well.

I prefer to tackle performance from the problem perspective, what problem are you having right now? So you need to find the first and more important bottleneck and work to improve it then you can proceed forever doing this cycle, remember, performance is an infinite game, it never ends, never. Every code that you add or every behavior change from your clients can affect performance.

And what I know for sure is that Meteor is able to deliver the desired performance in most cases, I never got in a state with Meteor that I was not able to fix and improve performance. I’ve been using Meteor for at least 6 years in many different projects, social apps, enterprise apps, internal apps, Galaxy (it’s also a Meteor app), etc. Also we have thousands of apps running on Galaxy and they are making money right? Otherwise they wouldn’t be running apps at all.

If you are using Subscriptions my answer here can provide some insights for you.