I’ve seen various mentions that realtime reactivity makes Meteor not scale well. It is a valid concern, but it’s also not a big one.
I wanted to re-share that it is easy to both make reactivity fine-grained and/or throttle it:
Not only that, but the same trick can be used on the server side to throttle data for a publication, or even to throttle data from one collection to another.
Here are some more ideas:
No matter what system we’re in, “lots of data” is always going to be a problem. I think it is better to start with such a simple and nice developer experience, then add a little work to it when big data needs happen, than to start with something else.
Is there something else that makes Meteor not scale? Let’s try to debunk it.
So far the benefits of using Meteor outweigh the work needed to limit realtime data.
Meteor is awesome to develop with, although the downside is it’s performance isn’t amazing unless you master it. The app itself doesn’t use much resources but it’s the database that does. Mongo is pretty good, I think you can do some big numbers with it. Compared with MySQL Percona it does feel slightly slower and not as well under heavy stress. At around 300-400 concurrent users my dual quadcore starts to chug. With Percona it can easily handle up to 10k concurrent.
I think a MySQL driver and nonreactive setup should be part of the manual and demo. Not everyone needs reactive data but they do need Meteor.
The most understated feature which I have only encountered now after months of looking is Tracker.nonreactive() there is barely one line of information on this in the manual and I haven’t seen it mentioned here in the forum. I learned about it from a brochure produced by Project Ricochet about how to get good performance from Meteor.
Besides disabling reactivity on non-essential subscriptions. Utilizing oplog and memcached infront of your publication / Method call will get better mileage although it is not to the level of Percona as of yet. I run 4.5 million daily visitors / 800req/s and 45gbps throughput on percona and it doesn’t flinch, it is behind 3 nginx servers loadbalanced and I am certain Meteor can do those levels, but not without a lot of love and tuning. Percona is ready out the box and require little tuning to get there.
@truedon Indeed there isn’t much documentation around reactivity performance. Solid.js has Meteor-like dependency-tracking reactivity, and it specializes in that with a whole community around it; that’s all they think about. Learning Solid will help any Meteor developer to think about depedency-tracking reactivity in various ways including performance considerations.
Was this that Ricochet article (along with the “whitepaper” it links to) that you were referring to?
I started a new topic here, and would love any input:
I’ve seen it, but I haven’t dug into its implementations. My intent is to make the best thing possible for web. Unity and Unreal (etc) are not web-first, but native-first, platforms. But I’d like to make something for web, and later make compiling to native a secondary option. I’ve got somethings in motion for this, but it will take some time.
The problem has always been oplog tailing, there’s no official solution - vendor-supported or third party.
Redis-Oplog seemed to have done wonders for many companies - but it’s pretty much a deprecated project. Even if works well now, nobody would want to stake a company on it.
It places a hard limit on how much Meteor can scale - i.e. even as you add more servers, your application wont be able to handle many more concurrent users
