I have never been worried about scaling meteor apps and each time I hear the scaling questions about meteor I feel it one of those buzz questions and in truth not a smart question to ask in most context. My thoughts are clear on this in the followng post.
But lately my biggest concern with Meteor and this might not be a full meteor issue but more about websockets and reactive applications. Is cost at scale. I believe everyone has been ignoring this. But maybe this isn’t a big deal and every language, framework or tech is similar. Why I’m asking about this here.
The average VM depending on your code can handle anywhere between 150 to 350 concurrent users. So if you have 10,000 concurrent users which I believe is not crazy consumer scale yoru looking at the following
I’m using Modules.io as Meteor Galxey in my point of view is not for startups and not realstic I think they missed the ball here.
Using the 512 RAM servo size which is $28.80 per servo and $288 for 10 so if each servo can handle 350 current users (10,000 / 350) I need about 28 servers for simple sake let round up to 30 that would be $288 * 3 = $864 per month.
And let’s look at factor of 5 that would be $4,320 per month
I wonder if this is ok and in pair with other languages / frameworks?
I know from my previous start which was Ruby on Rails with Angularjs front end we were able to scale to millions of requests at the cost of $1,000 to $2,000 per month (to clarify that was on Microsoft Azure, VM Linux. We had replicate set for Mongo primary and two secondaries and then for the app a load balancer and two machines plus running and another for backup if one went down. For the client just one machine and running mode of the static files from CDN).
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 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).
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
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…
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.
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.
Most people try to keep their business expenses as a guarded secret.