Worker threads no longer require the experimental flag with Node 12 (as being used with the current version of Meteor)
1 Like
Meteor’s pub/sub is obviously not laid out for high performance real-time processing.
There are lots of things in the world that look like they could be used for various alternative purposes, whereas, at a closer look, they shouldn’t. For example while a wrench looks at first sight very suitable to be used as a hammer, and indeed, it will do the job for a while, or, in the heat of a battle a screwdriver could be seen as a great substitute for a drill, both are in fact very bad ideas.
The same goes for Meteor’s pub/sub and high performance real-time processing. The API doesn’t reveal that fact; if you read the manual, there are no hints on performance bottlenecks. But we have now the empirical knowledge on what is and what isn’t possible with Meteor. If we have a family car, we shouldn’t try to use it as if it was a race car.
Here’s an essay on how to build distributed real-time systems. It is very well possible with Meteor, whereas in this scenario the Meteor server is going to be just one item in a puzzle, not necessarily the “main thing”. And for this to work one will need a microservice architecture. Good news is that many of us already use redis, which is a very useful part in such a scenario / architecture.
1 Like
Thank you for the hint, I missed that bit. What do you think about our chances to use worker threads to make Meteor methods and/or publish-subscribe multi-threaded?
1 Like
Seems like pub-sub is normally an issue of memory and worker threads are normally a solution for using multiple cpu and not hogging the main thread. So not sure about worker threads being a solution to the pub-sub issues normally encountered
What about methods? Blocking the event loop is typically what could slow down Meteor. Ordinary method code is usually not expected to be a problem, since it typically does something with MongoDB, i.e. the operation will end up being idle in a Fiber, thus clearing the event loop. However, what isn’t a problem if occurring just occasionally can grow to become a problem once there are too many Meteor methods running “concurrently”, still in the same main thread: then they will start blocking each other.
It seems to me that this is a scenario that occurs very naturally in every Meteor app, once a certain threshold of users invoking methods is reached. This is one of the scenarios where autoscaling gets triggered in Galaxy, or manual autoscaling would need to be done based on the performance metrics: the allotted CPU is around 100%. With worker threads, please correct me if I’m wrong, more than one CPU cores would be used by the same Meteor instance, hence instead of adding more instances one could simply add more CPUs. Wouldn’t that be an achievement? Couldn’t that be seen as a performance improvement?
Why just don’t rewrite some meteor’s parts in native langs (c++, golang or whatever)? Say, replace socket server it would process it’s heavy parts easily, the same for ssl, the same for pub/sub. The typical user even will not have to change his code but server becomes not multithreaded in its original sense, but at least less resources hangry and easily horizontal scaling… Why all of you just want to make it running in javascript only, in one event loop? After all V8, the core of node, is written in c++.
3 Likes
I don’t take your word for it that the websocket package used in Meteor is indeed poorly performing.
All we have from you so far is a claim that you failed to substantiate. Your VPS environment is not suitable for any performance testing anyway. You didn’t provide us with any measurement data (let alone reliable one), nor did you show any piece of code that makes your story plausible or believable, such as that you have “set up a separate socket server written in Go” and “written my own pub/sub to replace the native meteor implementation”.
You claim to have already solved these problems, yet you don’t stop demanding that we, as a community provide a solution for you to the very problem that allegedly needs no solving anymore. Why all the fuzz if you have your own perfectly performing websocket server written in Go that you can use with Meteor?
2 Likes
Please check the PRs for Meteor. There are already some that are experimenting with ideas discussed here.
1 Like
We use Meteor v1.8.1; we didn’t update it to the latest version yet.
The app has 2M+ users. This is the default meteor usage; we haven’t used any special trick. We are using AWS with Horizontal scaling.
4 Likes
Your VPS environment is not suitable for any performance testing anyway
If I have 2 same apps running at the same VPS and the one is “not suitable” as you say for this “hardware” but the second - suitable, as I say, because it works fine, I would say that the first app is not suitable for using. All the differences between apps was just the pub/sub subsystem differ although having the same publications and subscriptions
You claim to have already solved these problems, yet you don’t stop demanding that we, as a community provide a solution for you to the very problem that allegedly needs no solving anymore. Why all the fuzz if you have your own perfectly performing websocket server written in Go that you can use with Meteor?
Ok. Lets finish at this point. You play with your toys and I’ll play with mine’s…
Nice. Could you give as the resources used for peaks of usage?
I am sorry, but your question isn’t clear to me
How many resources used by you application when 2M+ people come to your site and if in this situation it is automatically horizontal scaling (or manually? Or you have constant resources (VMs, CPUs, RAMs)?) - what are these resources?
1 Like
I didn’t say that a VPS was not suitable for your app. I wrote this: “Your VPS environment is not suitable for any performance testing anyway.”
It may very well be that there was a bug in your app back then, which you mistakenly attributed to one of Meteor’s component. Maybe there were circumstances when method calls or subscription code escalated in that app of yours due to bugs you never discovered, perhaps up to the point of endless loops on the server, and that caused 100% CPU usage. Then you rewrote a few parts, and the bug was gone. It wouldn’t be the first time in software engineering that a bug appears to be somewhere, whereas in reality it was caused by something else. I guess we will never know.
You can send me an email at sanjay @ deligence.com and then I’ll share as much information as I can. Can’t share all these details here publicly.
maybe it useful to share with us what apps you have running or have in mind to create?
Well… Currently I have 2 meteor apps running.
First is a quiz system for american’s young jewry. It has a few UI clients - administrators or operators but thousands of participants. System sends sms to a groups of young jewry with questions about their’s history via twilio or nexmo. They respond. Some wins, gets scores and so on. This is still in meteor 1.2.1. It works fine just because of few UI clients. But it had one issue right as I told before when I’ve created second separate simple meteor app that was necessary once for a raffle with a simple UI - system just randomly selected connected users (with a phone) when a button pressed and all of them gets message who wins through pub/sub. This raffle server was connected to first quiz system’s server for some simple authorization and getting user’s names by their phone numbers. It was a dead simple system of 2 subsystems. And and stucked when users became 50-100. So the raffle at that point mostly failed. The main quiz system works about 5 years and I sometimes makes some small fixes or additional workflow changes.
The second app is my personal blog. Firstly it was written in meteor, don’t remember exactly, by I guess it was version of <1.2. Later I was struggling with it when there was breaking changes in 1.3 and now it stopped at 1.8 version. It has a self made pub/sub as I mentioned before, not perfect, not as mature as meteor’s original (it is not very well in a bad connection or sometimes not reconnects when laptop sleeps and woke up and has less abilities) but it lets my server’s CPU almost sleep: 2-3% with about 30-50 users online and about 20-30% with about 400-500 concurrent users online. I mean server, not meteor’s server application! I have such a peaks when deploying new chapters of my books and users comes. Not sure it can be interesting to you, blog is in russian but you may take a look at it: https://yasinskii.ru/. In that blog besides by books I have some posts with all my troubles with meteor I faced but they in russian too and don’t think you will read it. So right now I plan some changes to a site, some other integrated tools for a writers, although I have some - I write texts right on site and readers may correct mistakes (there is some git-like subsystem for text changes for users) right when they read (many people likes this and feels as involved in process of book creation). But I plan to expand this tools. That’s why I was attracted by the changes in meteor state today.
1 Like
Nice, I like the book idea, I was looking for something of that nature for personal blogging and publishing as well.
For the raffle winning message, you’ll need a socket for sure, so stateless Rest won’t work. But I would use a DDP streamer and bypass the merge box to communicate the winning message. I’d have also used JAMStack with DDP backend for the client that expecting thousands of hits.
And for you the blog I would have used Meteor methods without pub/sub. I think those two approaches would have solved your issues 
And for you the blog I would have used Meteor methods without pub/sub. I think those two approaches would have solved your issues
Maybe. But I liked meteor for all its features. Without pub/sub its just like any other framework - Next.js, Nuxt.js, Sapper. With its features of course, but nothing special. Besides, for the last time I prefer concept of separation client server and api server. It lets more flexibility for tooling and client’s demands.
For example take a look at https://github.com/create-go-app/cli - you can choose any framework for client just like meteor (React, Vue, Svelte), api server is in Go but you can choose router framework, database, etc. Plus using websockets in Go is like a breath. Or just REST. Http, https, http/2, SSE, automatically get let’sencrypt sertificates. Plus green threads and normal threads. One interesting thing about Go. If app has several green-threads running in one OS thread and one green-thread “hangs” by this blocking other green-threads, Go core will run new OS thread and move these other non-hang green-threads there and they will continue to work. I was shocked when new this. For last year Golang is like meteor for me 5 years ago…
Maybe you will be interested in my project for collecting of books links (aka url aggregator). Nuxt.js, Golang server, Mongodb, SSE for simple reactivity, recommendations… https://blinks.authors.city/
Anyway, thanks for interesting conversation.
1 Like