I want to know when they say “concurrent” what do they mean? Are the users actively fetching data or are just connected?
If we use little to no pub/sub and rely on methods to fetch data, how many users can we handle at a time?
And what about if they are all real time pub/sub? Then how many concurrent users?
For simple sake we can say a concurrent is a user that is connected to your site pub/sub to data.
Of course you have to scale your DB for read and writes but that’s another topic.
I believe that “cheap” scaling comes with proper architecture of the application. Granted one of meteors big draws is that it is easy to pick up for almost anyone and proper architecture is not webdev 101.
I have built and deployed meteor systems that were able to handle 10’s of thousands of writes per second while maintaining around 4,000 concurrent users across 3 m3.medium EC2 instances. We use a microservice architecture with kubernetes as the container management system.
This solution costs just over $100/month and could scale up to at least 10,000 concurrent users for not much more (I don’t think).
I know Plenty of Fish (POF) isn’t written in meteor but it gets 1.2 billion page views/month, and 500,000 average unique logins per day and it only uses 2 load balanced web servers with 2 Quad Core Intel Xeon X5355 @ 2.66Ghz, 8 Gigs of RAM (using about 800 MBs), 2 hard drives, runs Windows x64 Server 2003 and 3 DB servers.
I personally believe that the “cheap” scalability of an application is the duty of the developer and not of the framework. That being said, some things inside of a framework can make scaling easier or more difficult (pub/sub).
If you have 150 to 350 concurrent users, is $864 per month cost-prohibitive?
no1 is stopping you from grabbing 1gb droplet on DO and try how many authenticated DDP connections it can handle
for example https://github.com/meteorhacks/meteor-down comes to my mind
You might want to watch the video linked in the above thread.
Oplog tailing is the bottleneck for scaling with meteor. Scaling your mongo cluster isn’t going to do much for you.
That’s the impetus behind the Phoenix Thread. Reactivity that scales both vertically and horizontally.
@shock As I suggested in my post this data is somewhat already out there it might not be exact but no need to run a test
@jacobin I know this why my post was not directed about the DB scaling I’m interested in comparing the cost of scaling the app.
Horizontally scaling does not alleviate the oplog tailing O(no) issue. Discussing the cost of doing something you can’t actually do is rather silly.
The cost, will be hiring devs to remove meteor’s reactivity and replacing it with Redis/RethinkDB/Postgres pub/sub.
Depends on your app. Is it by its nature really intensive/realtime/dataheavy? Plus the nature of your target audience; is this a niche project/or does it appeal to the general public. Really, your business model. Can I get X $ from Y clients to cover Z $ in server fees.
$864 sounds way over what I’d like for 150-350 concurrent users, but then again I don’t know what exactly your app does. @khamoud’s answer makes me optimistic! Im not sure I’ll be able to reach that efficiency, but it’s nice to see that its certainly possible. And @khamoud thanks for the data! This isn’t something you can really find by googling, especially not with this specificity 
Most people try to keep their business expenses as a guarded secret.
One of the problems is that by default most everything with meteor seems to be reactive. Cursors for user profiles? I even see people doing insane things like pushing reactive chat through the database instead of rabbitmq/mttq.
Certainly using a stateless rest/microservices architecture like khamoud will get you to scale a bit higher… but at some point the oplog tailing is still going to cry O(no!) when you add in reactivity.
redis + MySql cold storage is my Solution for a lot of the heavier read/write data. Meteor supports multiple dbs, but it’s far from firstclass.I think it’s time meteor got some new significant db functionality besides minimongo and oplog trailing…
Also, I think you’ll like:
https://meteor.hackpad.com/Proposal-for-deprecating-user-profile-3UljX1VayvV
Ran into this myself earlier today:
I agree. Hansoft’s solution mentioned in the video uses Redis as a broker between meteor and the database. It was tested up to 10k users per node with flying colors.
@SkinnyGeek1010 is working on using Phoenix in a similar manner, but only for rest requests not reactivity.
MDG supposedly had one guy ‘starting work investigating’ a database abstraction abstraction layer a few weeks back. That just isn’t enough. Putting people to work on a new frontend when your backend doesn’t really work is insanity.
Pls give me the link where is written how many concurrent users 1gb droplet can handle without anything else than pub/sub on accounts for users to log in.
all the other is application specific and does not automatically need to use any other pub/sub.
I believe it was calculation for 10k users
That makes a lot more sense lmao.
Codefights has 200k users. I wonder how much they’re paying for Galaxy.
I think it also depends on how much you’re trying to do with your app. I read a comment by Arunoda recently that said that 70 percent of publications don’t need to be reactive. This means every app is wasting a lot of resources. If you hit really big scale you probably want to work out other solutions that don’t make every call for data reactive. He’s coming out with a post soon on how they made use of graphql to solve this problem for kadira.
Either way, the more real time your app, the more it’ll cost you to run each month. Scaling any site might mean having to cut down on some features to make it work at massive scale for a low cost. Each site will have its own scaling challenges. Not sure how smart it is to compare meteor and rails. If rails is less offering less features, then of course it’ll be easier to get more concurrent users.
That’s total registered users. If you watch their video talk, Codefights peak concurrent users was 1000 over 20 Galaxy containers.
iirc The meteor podcast on Galaxy said the entry tier gives you 10 containers at $599. So perhaps they use the $999 tier.
They also discussed jumping through hoops to limit subscriptions.
Agreed. I was able to vastly improve the number of concurrent users for the Blonk app (to 400 or so) by using Meteor methods to fetch data and then upsert it into a local minimongo collection.
This allows you still use the same query techniques but the data won’t update… saving unneeded re-rendering and CPU cycles in a lot of cases.
Yea, you def. won’t have the same developer experience as on the tutorials using autopublish.
One company I heard of was sloppy and could only get 10 concurrent users per box and was spending like 15k a month on servers.
This is interesting and something I’ve been thinking about for a while myself. Does anyone know of a neat, simple way to stop a publication being reactive?
Realistically, only things like forums or chatrooms need to be fully reactive. Most other things (such as user profiles etc) don’t need to be.