@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
1 Like
@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:
1 Like
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.
6 Likes
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.
2 Likes
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.
[quote="jacobin, post:20, topic:13716"] They also discussed jumping through hoops to limit subscriptions. [/quote]
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.
3 Likes
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.
1 Like
As skinny geek mentioned, you can use meteor methods to send data and
insert it into user collections.
If it stays as is it will be a major issue as successful apps will be forced to move on from Meteor relatively early (and that will ultimately lead to people avoiding Meteor altogether).
With that said, because of the above I think both the community and MDG will find solutions to these problems. It’s just a question of how long that takes.
1 Like
I believe @msavin still has a package to this but it uses a reactive var instead of minimongo.
Which, at times can be better than minimongo because the data doesn’t get mixed together. For example in Blonk we needed to pull in a users profile in the chatroom but also didn’t want it to get mixed up in the profiles feed. Since they could both be on screen at the same time it takes hacks to mark the different data before it hits minimongo.
Surely there should be an easier way to do this? I think it’s great that Meteor is reactive, but you’d think it would be easier to make it un-reactive as well… 
I would expect that if u r doing low level publications without keeping Cursor there, it should be quite cheap for resources.
And also non-reactive.
