1

We are evaluating Meteor for our new generation of enterprise-scale system. One of the amazing built-in features is that every data model in the client is bound to the model in the database and is updated once the server updates. but I'm concerned about the scalability.

What would be the architecture needed to invalidate millions of connected users?

I guess the basic question is how the database is bound to the model on the server and client. Extrapolating more, let's say we have multiple webservers running, and one database. Is it supported? If so, how? If anyone could describe the underlying technology that made it happen, it would help a lot.

I guess this could be a general question for scaling of any web app that uses a reactive model. First, that's true - and any discussion on that is great, too (what's the best design to implement that?).

Second, specifically with Meteor, as it seems more monolithic (in the sense that "everything is done for you"), we are looking for some more visibility to help us see inside (without reading the whole code base) and help us decide.

many thanks, Lior

Lior
  • 40,466
  • 12
  • 38
  • 40

5 Answers5

2

let's say we have multiple webservers running, and one database. Is it supported?

Yes, in order to provide convenience for the freshman(this is important for a new project), meteor embed a MongoDB server inside it, when you use "meteor" command to start the web server, it also start a MongoDB server, and its port is two adding the web server's port...it's easy to start. Also, it provide a way to change this behavior, see this question

So, you can share one database between multiple web servers.

As to the second question, as you see, meteor is cool and it is like magic, but there is a price, all magic things have a price, it do a lot for you internally and it's like a black box, in some situation, this will drive you crazy if you don't known what's going on inside it! so if you are thinking use it in a big formal project, be careful! Especially it's too young, even the document is not comprehensive and detailed enough and it's changing quickly and its developers maybe too busy to develop new functionality that they don't have time to answer you question...I'm using meteor in a internal project which don't have restrict requirement, that's fine, a real project for millions user? I don't think it's a good idea right now.

Community
  • 1
  • 1
Aaron Wang
  • 1,091
  • 1
  • 11
  • 17
2

David Glasser's answer from the google group:

The short answer is that: if Meteor doesn't scale, any other work we do on the platform will be wasted. The current implementation of the database connector is essentially the original draft of database connector code. It works great for development now, and we're going to make sure that it works great for large scale improvements soon.

TimDog
  • 8,758
  • 5
  • 41
  • 50
  • [Smart Collections](http://meteorhacks.com/introducing-smart-collections.html) is the so called improved version. You can use it today. (This is a community contribution, not something in the core) – Arunoda Susiripala Aug 01 '13 at 16:03
1

I've working on the Scaling Issues with Meteor and I could able to add some great improvements.

Smart Collections is the core of this. It is a whole new mongodb driver implementation for Meteor.

And Smart Collection does MongoDB Oplog based scaling support. Which is the perfect way to scale meteor apps.

Arunoda Susiripala
  • 2,516
  • 1
  • 25
  • 30
1

as 05-12-2015, Meteor mongo collections are doing a good job at scale. This is from the Smart Collections official page: "Smart Collection is now retired & Meteor’s Collection implementation has fixes for most of the performance bottlenecks. It is also using the MongoDB oplog just like Smart Collections."

Victor Chigne
  • 186
  • 8
0

Wanted to provide a more recent answer:

Sending the minimum amount of data to the client helps make the sub/pub process faster, and helps protect against inadvertent data exposure. This is why specifying only the fields the client needs is a best practice for publish functions. Limits are wise to setup, especially for views that theoretically could have an infinite list. When limiting the result set of a query, typically the query is also sorted. So keeping indexing in mind is critical for performance.

You can also increase the memory for MongoDB, and using tools like Kadira and Compose are helpful in scaling as well. The quote above and more tips can be found on this case study about scaling a real meteor app.

Melissa Lower
  • 1
  • 1