I love Meteor to be honest. But I had so much headache when trying to put meteor apps to production that I’ve stopped using it in new projects. It was about 5 years ago, there was not so much info about how to scale meteor apps and it disappointed me in a hard way.
Even dropping pub/sub and using only meteor methods could hardly solve the problem. As only online users become more than 100, meteor server took 100% of CPU and more and hosting provider stopped my VM. It was… painful.
After investigating the problem I found out that this was all around nodejs socket implementation that took almost all CPU resources (besides meteor pub/sub resources consuming). So I had to fight hard with the core of the meteor. I’ve turned off the meteor native implementation of sockets, setup the separate socket server written in Go (centrifuge), have written my own pub/sub to replace the native meteor implementation and although it was far from meteor comfort of using it, it solved the problem - at least several hundreds and up to 1000 of concurrent users let the cpu hardly move more than 15-20%. I was happy, but…
I’ve faced the question - now my system hardly reminded the meteor app as it supposed to be. Now this is a simple client-server app (SPA) that hardly differ from other, non-meteor apps but with self-made huge subsystem, that solve the problem you can not face in other frameworks. So why should I use it?
Now my personal tools are - Nuxt.js for client and server API is in Go. Resources used - minimum. Comfort? Yes. Not like in meteor, but it’s own. Hi load? Easy. Thousands or even tenth’s of thousands. Or more by using some tricks. And there is no questions on vertical or horizontal scaling. It’s quite easy in Go world.
But having my old systems in meteor running, one is my personal blog with fiction books I write, I still look at meteor to see if I can return to it at least in a borders of my old projects that is still alive.
So, is Meteor still unable to process at least 1000 concurrent users without dances with a tambourine?
Can you be more specific on 1000 concurrent users? That number by itself is quiet nebulous. 1000 concurrent users on a tiny container with no indexes in the DB, I would guess not.
On the other hand I’m currently working with a company that handles magnitudes more concurrent users, but we had to scale, optimize DB queries, subscriptions, etc. In general pretty much the same thing like with any other Node based application with sockets. But we had tools like RedisOplog to help us.
Now there have been some improvements over the years and even more are on its way.
Can you be more specific on 1000 concurrent users?
Nothing special. A blog with 100 and more users opened an application. Some small subscriptions (user object, current posts list and so on). But subscriptions in most cases in meteor is evil, so was used as less as possible (this was a prime feature when advertising meteor, but mostly not usable in production as is). And in this circumstances CPU worked heavily for about 100%. Anyway, I used the other very simple application with a single subscription - just to react on 1 event and the same - 100 or more users crashed server. To be honest it was made on Meteor 1.2 and less. But later upgrading to latest versions changed nothing. It was exactly Nodejs socket server implementation fault (I spent a log of time to find the bottleneck). Nodejs spend it’s events cycle resources to support sockets living instead of application service. The same is for ssl encryption, but we’re about meteor’s core.
I know there was some other attempts to make it decent, i.e. in C++ implementation for Node, but this is not a Meteor core implementation and as far as I understand nothing will change until this module change. Until now all my attempts to test meteor with simple application with 100> users led to a heavy loading of server and unusability it in all. I mean just to take Meteor and fastly create a production even a simple application without late headache, as users come, is not possible. But if I do it with Go server and some React or Vue boilerplate I get fast and scalable application with no any mentioned problems.
I would say, Meteor is easy at start, but a headache later.
With my experiences, subscribe to a list of documents is not effective. I will create a single document which has some list status likes last post… then subscribe to. If there was changes I would use method to load the data.
Then use redis oplog. It helps a lot.
I’ve played with it a lot a couple of years ago and tired of all this. Now I’m happy with my Vue.js + Go stack (I became insane in high loads struggling with meteor) so unlikely will come back to Meteor for new projects but I have a couple production meteor apps that might be evolved. So I’m asking somebody who is still struggling with high load in meteor on its own server if he knows something…
BTW it is not easy to test meteor app for high load because we cannot emulate meteor client behavior in some testing tool in a large amount. Unfortunately I’ve faced with problems and later tested on a real users.
And once again - I’ve written above, I’ve created a simple app with 1 subscription and it failed on 100 users or even less
Doesn’t matter what you do in your app. Can you confirm that 100+ concurrent users works well with your app and does not utilize all server’s CPU resources?
When I faced this problem I surprisingly found no one real user with real high load meteor applications! I mean on its own server. All those that developed more or less high load apps hosted’em on Galaxy and event didn’t know how many resources they utilize. Other “gurus” with their advises finally appeared to had no one high load app implemented in meteor! I’ve tried to find help in many Meteor related resources and I’ve come to a conclusion that nobody write production ready high load meteor applications!
I don’t know, may be now the situation has changed but I’m on another railway already.
What in my words made you think like that? Do you just wish not to listen bad words on Meteor? Every tool has its cons and pros. I’ve faced the cons that made me hurt. Explain me how I was wrong and probably I will come back to meteor in my next project.
I don’t think it’s reasonable for forum members to be held hostage because they’re concerned. On the one hand, you state:
and then you say:
Nothing you’ve said so far has indicated any great desire to return to Meteor - in fact, quite the opposite. You have provided no code we can look at to understand how you have developed your Meteor projects, so it’s unfair to expect us to offer any help except in the most general terms.
There are several topics about moving off Meteor, so this is not a problem here. Perhaps suggestions about how it may be improved would get better traction.
Ok. Leave all I said aside. I just asked a simple question - could anybody confirm to have a production heavy load app (its funny to say about 100+ users to be heavy load but let it be) in meteor on their own VPS (not Galaxy). And if yes - how many CPU resources does server side utilize? As far as I understand this is mostly Nodejs problem but I’m interested in if and how meteor users workaround it.
Nothing you’ve said so far has indicated any great desire to return to Meteor
I said I have 2 production systems in meteor so I’m not trolling here.
You have provided no code we can look at to understand how you have developed your Meteor projects
I see you don’t understand what I’m talking about. As I said - take a simple app with 1 subscription, put timer in it and let it update value to all subscribed users. On how many users it will stuck? My experience let me answer - about 100 users. So what code do you want for such simple app?
There are several topics about moving off Meteor, so this is not a problem here. Perhaps suggestions about how it may be improved would get better traction.
I’m not moving off Meteor. I’ve already moved. But I still have running apps in it and this topic is about productivity and I have a question. If this question is so bad why just not answer it? I have a real usage of meteor applications. I see only offence from you to my question. Its not serious
In case you mean there was a severe issue with the websocket implementation for Node.js 5 years ago, it is worth noting that this package had 10 releases since. So it is very well possible that the problem you experienced at that time is already fixed.
Oh VPS. It is absolutely not advisable to host a Meteor app, or for that matter, any other kind of app in production on a VPS; the reason being is that in that arrangement all you’re getting are nominal resources in terms of number and speed of CPUs, memory and network throughput / latency, because those resources are shared with any number of other customers. So it all depends what the other tenants do or not do with their allotted resources overlapping with yours: if they are busy, your app’s performance will be lousy and vica versa. You need a controlled environment in production, such as a VM with dedicated resources or bare metal. E.g. AWS EC2 instances are real VMs.
Do you have full-stack reactivity with Go, something similar to pub/sub in Meteor? If so could you please share that framework, because I’m curious.
After some projects I made for different clients and for myself and found out that reactivity is something that you should use only if you cannot live without it in current situations. Currently I prefer (and it almost always suites the task) to use SSE (Server Sent Events), serverside simple controlling this in Go or some server emitters (like whatsup uses for real communications or else) and Vue store bound to it. But most often - without any framework. Golang is good in it. Or I like graphql with its subscriptions
In fact, this is a really good point, and it leads us to the next question: how do we test this reliably? Speaking of Meteor’s reactivity, we’d need a generic (maybe even configurable) test application that spawns a controlled number of DDP connections to a given server with simulated clients, and measures their performance while it makes updates in MongoDB that are designed to trigger a subscription recalculation. At the same time the host’s metrics need to be logged.
In case you mean there was a severe issue with the websocket implementation for Node.js 5 years ago, it is worth noting that this package had 10 releases since. So it is very well possible that the problem you experienced at that time is already fixed.
Thanks. Maybe It worth to check it, although I doubt in its efficiency, because as they said:
This is a (mostly) pure JavaScript implementation of the WebSocket protocol
So either you or I or someone else makes an in-depth exploration of the code of the newest release, or we can take an empirical approach by actually measuring the performance.
It’s not surprising to see a javascript implementation in a javascript environment; it is usually enough to limit the native code to the part that needs to be super efficient. 1% or less wouldn’t surprise me at all.