44

We are building a web app which will be used during a contest to vote contestants and display real-time vote statistics on a central display.

The contest will last 15 minutes and around 4000 users will be connecting to the web app in that lapse of time and send votes, which however are unique per user device.

We are thinking to develop such web app using Meteor.js. However, due to our little experience in developing services for such big amount of concurrent users and the beta state of Meteor.js, we have some concerns regarding the actual feasibility of the project.

The following are the questions we are addressing:

  1. Is there any benchmark on how many concurrent users Meteor can handle? I assume this depends on the complexity of the web app itself. In our case it would be rather straight forward, only the client used for the central display will be subscribed to the live Mongo query votes.find({}), the rest of the users will only see the vote / already voted button.

Having some data from a real case or test scenario would help us a lot.

  1. Would Meteor's infrastructure be able to handle 4000 users? Or should we go for some other hosting solution as listed in this deleted question (you need 10k+ rep to see it)?

  2. Are there any performance considerations specific to Meteor.js we should be aware of?

We have seen already similar posts, however none of them was dealing with such large amount of users in such a short time:

Also, we could use the Cluster smart package. Anyone has any experience with this?

Community
  • 1
  • 1
francesco
  • 441
  • 1
  • 4
  • 4
  • +1 Good question. I have a lot of experience programming Meteor but also know little about how it would perform under load. The cluster smart package is kind of silly IMHO and syncs slowly; it's more of a proof of concept and I wouldn't expect it to be as stable as core Meteor. – Andrew Mao Aug 10 '13 at 02:04
  • 1
    Also, props for doing a good deal of proper research before asking this question. – Andrew Mao Aug 10 '13 at 02:12
  • 1
    Just to clear things. Cluster mentioned in this question is history. Now we've another cluster package: https://github.com/meteorhacks/cluster (It's by the same author for the same purpose in a better way) – Arunoda Susiripala Feb 22 '15 at 06:32

3 Answers3

38

UPDATE ClassCraft reports one Meteor server handling 6400 concurrent users. Read more in the Scalability section of my Why Meteor article.

See also the forum post
How Many Simultaneous Users Does the Biggest Current Meteor App Support?

Here's a benchmark not exactly about concurrent users, but rather about setting up subscriptions (arguably a more stressful test).

Arunoda has recently published the results of a test using meteor-down (a load testing tool similar to @alanning's meteor-load-test) and Cluster, a Meteor load balancing tool.

The test was run on the cheapest Digital Ocean servers (512MB RAM, $5/month), and the results were rather impressive:

enter image description here

For all the above scenarios, server response time is less than 8ms.

Essentially one commodity machine can handle 2500 Meteor subscriptions per minute and respond within 8 miliseconds. Horizontal scaling takes less than 5% overhead.

You can read more about the test at Meteor Cluster Performance Test: Impressive Results.

Dan Dascalescu
  • 110,650
  • 40
  • 276
  • 363
11

https://github.com/alanning/meteor-load-test

If you mock up the app quickly, it should be fairly straightforward to set up a test for 4000 connections over a 15 minute period. I haven't used it personally but plan to do so once I finish fleshing out my own application.

Andy Eskridge
  • 262
  • 2
  • 13
  • Good reference - however, test on a local connection because otherwise traffic and not Meteor will become the bottleneck. – Andrew Mao Aug 10 '13 at 02:05
4

I think the honest answer is that every case is different, and there are no hard and fast rules that people can give you in terms of how your system will perform under different loads.

Your best bet is to actually build a simple prototype of your system, with one or two functions, and then look to run some performance testing using multiple concurrent users to determine what the limitations are. This should give you a good basis to then iterate on your prototype and work out if/how you can support the number of users you require.

robjohncox
  • 3,319
  • 3
  • 22
  • 46