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
@brendan that comment makes sense in the context of this thread where performance under load is of essence.
I chose Meteor due to its simplicity and ease of use for a novice like myself.
That’s a core competency and a core disadvantage of Meteor. Meteor makes app development achievable to the masses, but it also creates a false impression that it is a toy framework for prototypes.
If you don’t have very specific challenges you need to tackle, you’re in good hands with Meteor.
2 Likes
Understood, much appreciated.
1 Like
I have to respectfully disagree that being a blanket stack because you still need to introduce some kind of javascript view framework to provide a full app experience. So you need to know to technologies, elixir and javascript
Ah I thought you meant blanket as in a one stop shop as opposed to a JavaScript stack. It does have support for the frontend (in a Rails ‘assets’ way) 
It does make me wonder what possibilities Node has with concurrency if JS offered true immutable data structures and basic concurrency constructs. Running a Node process on each core in the background… anyway I guess that’s what clustering is for.
It already has great functional support (much better than OO lol), and pretty much has feature parity with Elixir with the exception of pattern matching (although ES6 de-structuring gets you close).
2 Likes
thought you meant blanket as in a one stop shop
Yep, that’s what I did. An IMHO, javascript is an optional view technology for a Phoenix app to create a thicker client to offload some of the server work to the client. I could have just as well brought up swift or java to create a native mobile client, etc. So that’s why I think Phoenix or anything for that matter is not a blanket technology to cover everything. An speaking of everything, an app can be an authentication server, a database, a client/server app where the client is a desktop app etc.
Maybe these examples sound a little off, my point being “really high velocity” apps require mix and match of technologies where each piece best addresses a certain concern. And that’s why I had opposed to the original question in the first place. Perhaps I’m trying to say any single so-called full-stack-framework alone is definitely the wrong choice to build and maintain a web-scale app.
what possibilities Node has with concurrency
I have not followed up much on that but I thought the jxcore guys took a stab at it.
For me, if I really wanted threads, workers and multicore and not want to give up javascript, I’d go for vert.x which has increadible performance, and works on top of the java virtual machine. It used to perform quite good on techempower bechmarks, no recent data, though.
It already has great functional support
Yep, after countless years hating scripts in java, now I’m loving the script in javascript
1 Like
Thanks guys for all these interesting insights!
1 Like
The term connectivity between clients (or better: [stateful connection] (Stateful and Stateless Connections (Linktionary term))) is a technical one. It means that the server software has to keep a track record about each connection it has with a client software, e.g. a browser or a mobile app. It has nothing to do with connecting people.