Performance of Meteor web application against 100000 parallel users

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: https://www.blazemeter.com/blog/websocket-testing-apache-jmeter
  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] (http://grapher.cultofcoders.com) 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.

17 Likes

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.

Waw. Thank you so much. Much appreciated.

just make an imgur album for screenshots

Why would you need 100k concurrent users? And why are you benchmarking on a laptop?

If you’re wanting high concurrency then I would go along with what other people are saying in the article and go with something like Elixir, Go or plain old C. However, even then there’s little chance your laptop will handle 100k concurrent users.

Testing for 100k concurrent users on a Dell laptop is like a blacksmith forging a sword with a butter-knife… Use the right tools.

If you decide to use Meteor then I’d avoid MongoDB as @diaconutheodor makes some good points about oplog tailing above. I’d recommend going with Apollo (GraphQL) and using Redis for speed with something like Postgres for your data integrity (essentically, use Redis as a cache for data that needs quick access).

If you are trying to bench for 100k users, this would take extremely cautious measures in the design of your application (your data structure/schema & pub/sub’s especially) to be able to even attempt that.

Without seeing how you created your project, we are completely in the dark… so how are we supposed to help you?

We would have to see all the pub/sub code in the project, to even start to begin giving advice. And that’s just a starting point. With Meteor (or any other framework) you would need to make many, many drastic measures to support that many users.

That’s why people think you are trolling/are not sure if serious. You are asking for advice, giving us very little to work with, providing very poor quality screenshots, giving far too little information, and testing on a system that was not built to handle such stressful tests.

How is your laptop possibly supposed to emulate a web server that you would use to support 100k concurrent users…? You would likely be deploying on cloud systems with external databases. Your laptop is not comparable!

Wow this is really impressive. I’m so glad to know that you are making Meteor scalable, because I (and I guess a lot of other people) really want to use Meteor in production for big projects.

Keep the good work, we really need it and we appreciate it so much!! Thank you a lot! :))

1 Like

Please, please, please keep us updated on this. Start an email list or something so that I know when this is coming out.

Follow this guys: @cluxter @mz103

Here is my draft code:

Not reliable, not working for now, it’s more than I expected :slight_smile: but the POC is done. It just works smooth as butter :slight_smile: now, it’s just the ground work, TDD approach, lots of tests, etc.

3 Likes

Out of curiosity, what made you decide on the NPM redis package, rather than slava:redis-livedata and slava:miniredis?

Thanks to a lot of people here who shared very good constructive help and hints. I will continue my IT deep investigation with node.js and Meteor. If I will finish my testing and technical investigations, happy to share it with you all.
BR, Mohi

The responses here are rude and ridiculous.

Only a handful of helpful ones.

Yes, you will struggle to scale Meteor past 1000 concurrent users. We run 20 or so 512MB instances on DO and we can deal with a few hundred concurrent. Hitting around 700 or so and it’s been a struggle to get there.

Elixir is a good option if you want to scale massively and might be a better option than Meteor if you need to hit big scale.

And to those asking why you’d want to hit 100,000 users, the answer should be obvious, but if you ever have a popular website you’ll want that. Of course there’ll be scaling challenges no matter what platform you use, but I can’t really fathom someone handling 100k concurrent with Meteor atm.

3 Likes

Thank you so much Elie, for the respect and for deep understanding for my initial thread. I totally agree with you. 5 years ago we did a similar load-testing with Government web-application based on Java enterprise framework and a lot of open source tools. It was really tough and a struggle, clustering Oracle db with JBoss and later we finally reached that using IBM Web-sphere, configuring the application server with commercial expensive load-balancer. It was really tough job scaling that web-application on that technologies, at that period of time.

I will check with your recommendation about Elixir. Again many thanks.

@mjarada2016 @elie

Yes, Elixir… Erlang VM… enough said it’s good, but:

https://www.quora.com/When-did-Facebook-switch-away-from-using-Erlang-for-Facebook-Chat

Give this a read.

2 Likes