High-Level Guide to Scaling Meteor
The first and highest-impact place to optimize is in softwareland:
- Mongo schema design, indexing, and oplog
- Subscription and query design (also try to avoid types of queries that use the polling driver)
For server architecture, place at the front a SockJS-safe, sticky-session load balancer that distributes connections to app servers based on least connections.
On the application servers:
- CPU: Run an instance of meteor for each CPU core, since node is single-threaded.
- Memory: Meteor’s MergeBox is keeping on the server a copy of each client’s client-specific subscription data, so make as many publications as you can general-purpose (as in, they return the same data for all users or a group of users, rather than different data for each user).
A floor for your per-client memory usage is how much additional memory your publications take up when another user connects. Looking at...
Continue reading →