Performance of Meteor web application against 100000 parallel users


On a DELL notebook equipped with Ms-Win10 machine with 8GB RAM, I run a simple load
performance test, to check the performance of node.js web server (i.e. running the basic
Microscope Meteor web application), with 100000 current users (5 seconds delay between each concurrent
user), using Apache JMeter.

Frankly speaking: I was shocked that node.js web server could not stand out the load, and the basic load test. Attached the screen shots, as reference to reader.

Kindly seeking your help or at least some hints how to configure node.js web-service for standing a better load, and able to run this performance not just against 100000 concurrent users, but more.

Thanks and BR,
Mohi Jarada (Budapest-Hungary)

Is this some kind of a joke?

1 Like

No. It’s not a joke. Have you done any benchmarking (performance load) with Meteor JS web applications. I had done for Java and PHP web applications in the past, I know their limitations against any web-server is used. Currently node.js is being used and I would like to know technically if this is the right framework, for my new web application or not.

JS is great scripting language and would like to know, it’s standing point at server side, using node.js

I think it’s a good idea, but if you have serious technical articles from Meteor JS technical forum, happy to read it and learn more.


I’m afraid that for such amount of concurrent users you should consider something more scalable like Elixir.
I recall hearing some people from MDG saying that thousands of concurrent clients are possible on galaxy, but 100000++ users seem over the edge.

Anyway never had any site with some many users at the same time, so maybe someone else can give you more input from real situations.

Well, I’m not sure what you expected but pretty much any single-system server will crash and burn at 10E5 concurrent users.

That’s what load-balancers are for.

Plus, running a stresstest on a server a notebook. The CPU demands from the network adapter alone should pretty much ensure that you’ll run out of resources, fast.

Not to mention that your “screenshot” is so badly done that I’m doubting your technical competency altogether. Here’s a hint: Either use PNG or don’t set the compression factor to 80%. No one can read that.


Thank you so much Toni. Basically I am new to Meteor world and forum, I came from Java and PHP web worlds, where we build enterprise Java web applications with > 10000-50000 parallel users in the past, using MVC Java framework and enterprise application servers.

I will check your suggestion.

Well I am really surprised from your shaming feedback and shame that such a technical person exists on this forum. Neither my Win10 or my Linux machine crashed, just node.js

I own a 20 years of IT experience and doing more that 5 years in load-testing using amazing open source tools, one of them is Apache JMeter.

It looks to me, that your technical expertise is really poor based on your given feedback.

Awaiting from other smart people feedback, may be they had done this before or at least experienced it.

1 Like

And obviously your 20 years of experience make you unable to post a report that’s not a badly compressed screenshot which is pasted into Word which is then screenshotted again.

Oh well, have fun waiting on someone who’s able to glean some useful info from your post. I have a friend who’s an archeologist and as such has some experience with decyphering hieroglyphs. Maybe I could ask him?


Until now, I did not receive any technical suggestions from you, to my original idea. Are you an IT expert in this field or not?

Would u like to help or what? I am really surprised how rude you are!

1 Like

How exactly are we supposed to help you? Or why?
First of all, again, 100,000 concurrent users is a lot of users. What real-world application should such a test even have?
Secondly, we don’t know anything about your test hardware setup other than your “Dell laptop with 8 GB of RAM”. Is that even the client or the server or both?
Thirdly, we don’t know anything about your test software setup other than Apache JMeter. What exactly did you test? What did the Meteor app look like?
Fourthly, your “report” is a piece of garbage no one on Earth can get any useful information out of.

Lastly, I’m not “rude”. I’m only honest. I know what stresstest reports look like and yours isn’t one by any definition.


I’m just curious, what tool did you use to run this performance test?

Edit: Ah, Apache JMeter.

The fun part is that his tool obviously crashed (I can just make out the “not responding” in the status bar).

I’m not sure how one does draw any useful information from that.

Yes. Apache JMeter. Also there a smart team who created a Java Sample for JMeter, here is the source we I started my IT investigation for this matter:

Ok. Interesting technical answer. Can you provide then any technical reports about the real performance of any Meteor web application, using many current users?

Can you provide these details instead of educating me?

We don’t even know what you’re testing with. Why should anyone bother?

It’s written in my initial forum, repeating:

  1. Using Meteor basic Microscope web application
  2. Using Apache JMeter and recording a web-socket sampler, for 100 000; just to check load of node.js
  3. Basic excellent idea came from this smart team:
  4. Happy to share my JMeter test plan file and original word document of all screen shots, as this forum only allow me to load one single image file.

You should bother, as I thought I can invest for this new technology, but as I far I can see there is no smart suggestions, to give me smart feedback that I can tell my business friends to invest on JS technology!

What a pity!

Not sure if trolling, but:

If all you care about is stress testing a node.js server with concurrent socket connections, check out this article.

if you really plan on having 100,000/s oh well, PHP, JS, Ruby may not be what you are looking for, go for something more barebones, C, Erlang, Go, and definitely not on a laptop.

Websockets imply more resources, it’s not static like a php website, pls keep that in mind.

You can use meteor without websockets, it’ll fallback to sockjs an emulator for websockets that works through ajax, you will not benefit from it’s true reactivity but you still would have access to a lot of nice things, that enable rapid development.

So you want stats, there are some guys from codefights, which documented their struggle with Meteor. They needed 10 containers (1 core 1GB) for 1000 concurrent users. That’s very very disappointing. The reason was oplog tailing, without it, Meteor is as fast as any js framework + websockets.

The oplog tailing is it’s main issue, problem which I am going to personally take care of: Meteor Scaling - Redis Oplog [Status: Prod ready] to enable horizontal scaling. We’ll be launching a social network in Meteor soon, the news is going to hit 300,000 people, so we can expect 2000-5000 requests per second. This is why, we’re focusing on this so heavily, we invested a lot, Meteor has helped us make something truly magical and great, but now it’s time for us to contribute to Meteor and bring it to next level, it deserves it! (We already did by introducing [Grapher] ( and gave it to the world)

So all in all, if you embark on Meteor’s train right now, you’ll be
hit with some great stuff in the near future, that’ll make Meteor super scalable.


Look like someone else doing the test and then gave him a report as ms word document. Looking at the ‘screenshot’ alone I also doubt he is a technical guy.

Thank you so much. I will check out this week asap. Appreciated.