Here is my experience so for. When you scale, every part of your stack will be pushed to the edge, and for the Meteor app server (like any other web server) you need to pay close attention to the average memory and CPU usage. Again I speak from my own testing, the most expensive from what I’ve seen in Meteor is the number of unique publications you’ve per user and the size of those publications on a given page.
It has been shown many times in the community the you can scale Meteor app horizontally, here is a video of the folks from classcraft claiming they can go up to 30k of concurrent session with their stack and LumindPDF supporting 5k concurrent session on Galaxy. In my load tests I was also able to grow horizontally indefinitely. So the question is not whether it’ll scale or not, but how much it’ll cost to scale per user session when you’ve a lot of specialized pub/sub serving many users and also whether you’re prepared to scale.
For me the biggest selling point when it comes to Meteor is the convention over configuration, the package system and the many specialized packages packages, RPC methods, community, flexibility and maturity. But historically (I’d stay after Benjamin joined and the pivot to multiple view layers) Meteor was a highly coupled framework with a focus on real-time pub/sub and I think that’s why we’ve two type of usage in the community. Those who see Meteor as a full-stack real-time pub/sub and those who see it as a flexible tools with convention over configuration.
Going forward, I think Meteor needs to build on its strengths, specifically the convention over configuration, developers experience and flexibility, and double down on entrepreneurs and SMB. These values are missing in the node ecosystem, it’ll give Meteor a long-term competitive advantage. The focus on pub/sub is actually the root of Meteor issues in my opinion, if developers start using RPC methods and only add pub/sub when needed and then optimize those when scaling then there won’t be an issue. But if they start doing pub/sub for everything, create many user specific publications without any consideration to performance then host it on 1 GB instance and invite everyone to join then surely it’ll crash. With that said, I think there is a room to improve the Meteor’s pub/sub. Specially, we need have a section on the guide for performance because right now the information is all over the place and technically I think Meteor’s pub/sub engine needs to be decoupled from the application server. The pub/sub engine (mergebox and diffing algorithms) should be made scalable on a separate cluster from the application server with their own UI dashboard, DDP interface and alerts.
Meanwhile, here is what I think would be a good recommendation (and please community keep me honest here):
- If you don’t need real-time then just use Meteor methods or Apollo. This will make Meteor as scalable as any other socket based node app
- Do use out of the box pub/sub to validate ideas quickly but don’t expect to scale without any tweaks
- If you’ve a lot of per user pub/sub observers and you don’t want to worry about the technicalities of scaling, then I’d recommend Galaxy
- Use as many re-usable publications as you can, the cost of scaling those are minimal compared to user specific publications (from my test, on average user specific publications are around 6 times more expensive in memory then generic re-usable publications)
- If you’ve many user specific publications then I’d either switch to redis or really bump up the memory per VM
- If you expect a lot of traffic spike then you need to overprovision the VMs or cluster meteor instances on the CPUs. Remember node is single threaded so by default it doesn’t leverage the multiple CPUs, so you either fork multiple meteor processes or scale the app horizontally with many small nodes and put load balancer in front of it, this is true for all node applications
- If you really want to have full control over you reactivity try the awesome redis-oplog package by cult-of-coders.
I hope that helps, and again I really believe Meteor is the tool for entrepreneurs in the NodeJS ecosystem. By the time you start worrying about serving thousands of concurrent users, you’d have already validated your idea (which is critical for entrepreneurship) and you can start optimizing the weak points of your app for performance, this is much better approach for entrepreneurs then creating their own stack, building their pub/sub engine, glueing hundreds of NPM packages, configuring web-pack just to find out their ideas were invalid.
