Could Meteor work in an app as big as Uber? Could it handle that many simultaneous users, given the right hosting/deployment setup? What are some of the biggest current Meteor apps and how many simultaneous users are they estimated to support?
8 Likes
Rocket.chat is about to roll out for a Brazilian university which expects 5k+ concurrent users. I’m interested to see how that is going to work out.
4 Likes
Frankly, I find such comparissons odd and off-topic.
Meteor is a platform for rapid development of reactive web/mobile apps. We’ve also seen it to be capable of scaling well for many commercial apps (workpop, classcraft, respondly etc)
But then, comparing that to an app with millions of users, perhaps hundreds of thousands of concurrent ones, an app that is constantly in development and maintenance by hundreds of engineers from tens of different core competencies on a very diverse technology stack just does not make any sense and it does not serve any purpose.
I’m sorry if I sound kind of harsh here, but we, as engineers, need to understand what makes comparisons and benchmarks valid and be vocal about those that are not, so that people trying to evaluate a piece of technology don’t get mislead by irrelevant comments.
10 Likes
Thanks for these excellent points. At the same time, I am part of a group that is developing a new web app and is currently deciding on our technology stack. We want to work in node.js. It is essential that we choose a framework that is capable of scaling to an extremely high number of concurrent users. Is Meteor a good choice from this point of view?
3 Likes
a framework that is capable of scaling to an extremely high number of concurrent users
Depends on a couple of things
- what’s your extreme?
- what’s the load profile? what does the concurrency actually mean translated in terms of what the app will do during a user session lifecycle?
- realtime updates?
- updates with huge json/binary payloads? static payloads? cachable data?
- no updates?
- batched?
- non/deterministic?
- what about frequency?
- does a typical unit of server task require long cpu tasks (calculations, processing etc) or short staggerred or consistent ones?
There of course are more data points required in order to identify and assess how much of your core requirements meteor can satisfy.
That being said, Meteor has been deployed in production by commercial entities with apps that target large user bases in different types of workloads.
Check this out https://www.meteor.com/case-studies/build-apps-with-meteor
https://kadira.io/academy/ might also be interesting from a performance considerations standpoint. Kadira itself is also built on meteor and handles millions of data points flowing in from thousands of meteor apps, and sure is an interesting case.
Also, MDG (the company behind Meteor) provides consulting, support and assessment services as well as a recently announced commercial hosting/management service. You can also seek evaluation and assessment support from Meteor partners.
5 Likes
@serkandurusoy: I don’t agree with you on this, sorry. In my opinion, @vikr00001’s question is completely valid. He is not asking how many developers you need to build an app like Uber in Meteor, he’s asking if the framework can cope with such a hugh user-base, i.e. how scalable the platform is in general.
21 Likes
I think the correct question should be how many concurrent users can you put on 1 server/container/bucket or however you want to call it.
And that highly depend on type of subscriptions, queries and how much data is overlapping and can be cached.
Still I think for most type of services that number of users can easily pay for servers 
1 Like
The question is valid, but the context is not clear. I don’t know what Uber’s simultaneous user connection count is like, nor what they needed to do to make it scale. Nor do we know what @vikr00001’s requirements are, nor what funding and development effort can be brought to bear to permit the scaling he/she might expect to see. All scaling is a balancing act between the amount of money you get to throw at your infrastructure and what tolerance you are prepared to accept on KPIs such as end-user response time (classic UX stuff). All this is intertwined and (I think) @serkandurusoy is just pointing out that you need to consider a lot of factors. Would you expect to serve 10,000 simultaneous users of a reactive app on Meteor’s free hosting?
2 Likes
Yes, of course 
Just kiddin’
LOL - I like your style!
1 Like
Ok guys, according to some lead that techcrunch had uncovered, Uber has an average of 1 million booked/completed rides a day. I’d say the traffic during typical US east/west coast rush hours would ammount to 200K concurrent users.
That number not being totally relevant, could please someone name me single one piece of blanket technology/framework/languge that can be used to create an app - any kind of app - that will service 200K concurrent users in any type of usage scenario.
I stand by the validity of my comment to every single letter. This question, in its current form, has no answer. It requires a series of follow up questions that will themselves require a series of follow up questions in order to reach a conclusive answer.
If the question were in the range of “can I serve 10K concurrent users for an app with a reactive interface in a uber-like functionality” then I’d say “yeah, why not, but we still need to talk some specifics”.
4 Likes
This is an informative and helpful discussion.
In my initial post I posited, “given the right hosting/deployment setup”, i.e. considerations of number of servers aside, is Meteor a strong choice for an app that may need to scale up extensively. Based on the discussion, that might be revised to:
- Is Meteor a strong choice in terms of number of concurrent users that can be supported per server, when compared to other node.js frameworks?
To provide initial feedback on @serkandurusoy’s excellent questions:
- realtime updates? Yes.
- updates with huge json/binary payloads? No.
- static payloads? No, dynamic for the most part.
- cachable data? We’re building to support a continuously updated database.
- no updates? We anticipate updates.
- non/deterministic? The majority of features would require a deterministic approach.
- what about frequency? There is one feature we have in mind that might require a higher frequency of calls from client to servers, e.g. what Uber does when it provides real-time updates on where the Uber vehicle is located.
- does a typical unit of server task require long cpu tasks (calculations, processing etc) or short staggerred or consistent ones? Short and staggered.
@serkandurusoy, does this provide some of the additional info you requested?
2 Likes
@vikr00001 very clearly indeed. So let’s go over one final detail:
There is one feature we have in mind that might require a higher frequency
Does that feature require the complete data history be persisted onto the database or can they be discarded once delivered to the connected clients?
1 Like
The complete data history of those real-time updates can be discarded once delivered.
I find this whole thread to be so confusing and at the same time so confused.
What you need to know:
- Meteor can work on running multiple instances of your server, most of your scaling load would go into database and database queries.
- Scaling your database is a question of a different discussion. Very often you can make it scale better if you apply knowledge specific to your application to shard data or optimize queries in a smart way.
- Most of the big applications utilize a lot of caching, it is not unheard of to reduce amount of real-time data sync in a Meteor app to reduce the load.
- Uber certainly doesn’t use a single framework in their infrastructure. Once you get to any “big” scale (however you define it, it could even be “extremely high number”), you would need to identify the slow parts and replace them with more optimized solutions to your problem. Every framework in the world is aiming to assist in a general case.
- Pretty sure Uber is running lots and lots of server boxes for their services, if you have “extremely high number” of simultaneous users, be prepared to scale out to multiple boxes too. To do it easier, Galaxy exists.
14 Likes
Now then, I gather that the app you are looking to build will more or less be a typical web/mobile app
- with a few collections (tables),
- significantly more reads than writes
- bulk of writes being inserts rather than updates/removes
- frontend doing most of the work
- backend acting more or less like an authentication manager and a data source
- the data would fit into a few gigs of ram on your database server and has a known schema/structure
Please object to any one of those remarks above as you see fit for your environment
Now, this would translate as:
- mongodb is probably sufficient for your app therefore you won’t need to jump through hoops or make sacrifices to swap out mongodb for another database, which is possible but requires more work and more knowledge of how meteor reactivity works.
- for the highest frequency part of your app, you can use direct *streams" instead of typical mongodb reactive data publications and subscriptions, lifting bulk of the load off of your database
These two points then translate as
- If you find a typical MEAN stack or any other node based framework sufficient in terms of per-server performance/capacity, you’ll find that Meteor will not be significantly better or worse than your assessment of the former
Now, to translate all these to actual numbers is still hard because in high velocity environments, every single byte counts. You really can’t compare the activity stream of “Yo” to “Facebook” or “Twitter” where one is just a “yo” where the latter publishes bulky document and media structures.
Still, I really don’t want you to leave this thread with no idea whatsoever. So I’ll make a bold move and share the following link with you: https://www.youtube.com/watch?v=S--huUwlr9Y Somewhere in that video is depicted that http://www.classcraft.com/ has scaled up to 6400 concurrent users on a server with 8 cores.
The typical meteor instance I’ve outlined above should be able to handle up to 200 concurrent sessions and as long as your server operations are short and not CPU bound, you can actually run up to 4 instances per core on a newish multi-core server. (No, 1 core = 1 process is just a myth that’s valid for very old CPU’s, some capped cloud “processing units” and cpu-bound long-running taks).
Meteor apps also are more cpu-bound then they are ram-bound so having faster CPU’s is more important than having more RAM.
There are optimizations you can do to further increase that number, though which I’d be happy to discuss.
But you should not forget that Meteor is a platform for connected clients which significantly changes the definition of concurrent users from what it is in a request/response app where a connection is something that happens in a fraction of a second every once in a while. But in the connected client world where websockets is the trnansport, a session is active and does consume resources until it disconnects. Yet, this also opens up optimization routes where you can sacrifice the “connectedness” in favor of performance, but then you slowly begin losing the point of using Meteor 
Let me know if you have more questions. Perhaps there are other people we can ping to join the discussion. Still, the most definitive answer would come from MDG if you choose to purchase their services at this point.
6 Likes
@serkandurusoy, thanks for the detail. But I always get confused with comments like the one above. (Preface: I am completely new to ALL development, just learned how to write Javascript and building my first app). I understand that Meteor has specific benefits for apps that require connectivity between clients. But that doesn’t necessarily mean it’s only for those purposes, correct? My project has specific value for an individual user, regardless of any collaboration with others (although I will provide expanded capabilities for that purpose). I may sacrifice the connectedness, because I just don’t need it, but still want to use Meteor.
I chose Meteor due to its simplicity and ease of use for a novice like myself. But so far, I see no reason why I can’t keep using it beyond prototyping. I would think adoption of the framework would benefit from use by all types of apps, not just those that take advantage of every feature offered. Really hoping I’m not wrong, or else I’ve gone pretty far in the wrong direction!
1 Like
At the end of the day you should choose Meteor because it’s productive and easy to use.
It should help your development speed increase not your network throughput.
Â
I agree there are prob. only a few out there. The only blanket framework I know of that can match/exceed that would be Phoenix which runs on Elixir. This is only because it runs on the Erlang VM which was designed from the start for huge concurrency. It can even spin up millions of lightweight threads (VM not OS threads) on a regular laptop. This also means you have to use a diff. language on the backend and are still at the mercy of it’s package system.
Because of it’s immutable / pure functional nature it (Erlang/Elixir) is able to run across all cores of the machine and scales vertically really well for most apps. Whatsapp was able to use a single (large) server to server over 2 million concurrent connections and had a team of 30 or so (which i’m sure some had a full time job managing it!).
IMHO if you know you need huge scale on day one then Ruby/Python/NodeJS are all inefficient languages to tack that problem. They’re all more prone to be swapped out bit by bit to handle load depending of the app. The framework isn’t going to really ding the performance much relative to that scale.
10 Likes
Thank you very much for this extremely informative post!
1 Like
I think the most important thing stated here was what @slava said about the role of frameworks in overall. They are there to help you get to the stage where you’ve already got enough money to switch into individualized technology focused on directly addressing your needs. At some point in time, you will want to drop them and invest in your own stack, just like Facebook or Google do. But first, you need to actually get to that stage. Which I hope you do, good luck.
5 Likes