Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Social networking sites needs to handle many concurrent users e.g. for chat functionality.

What web frameworks scales well and are able to handle more than 10.000 concurrent users connected with Comet or WebSockets. The server is a Linux VPS with limited memory, e.g. 1GB-8GB.

I have been looking for some Java frameworks but they consume much memory per connection. So I'm looking for other alternatives too.

Are there any good frameworks that are able to handle more than 10.000 concurrent users with limited memory resources?

share|improve this question

closed as off-topic by gnat, Kilian Foth, Ozz, GlenH7, MichaelT Oct 2 '13 at 15:40

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – gnat, Kilian Foth, Ozz, GlenH7, MichaelT
If this question can be reworded to fit the rules in the help center, please edit the question.

To me, this question reads like "How do I make my Nissan Micra perform like a Ferrari?" 10000 concurrents on 1G of memory? Really? When supporting so many users you have to come to terms with the fact that the supporting hardware costs money. If you can't monetize 10000 users well enough to afford improved hardware, I'd suggest your business model is flawed. After all, on the grand scale of things, hardware is cheap. –  spender Apr 5 '11 at 13:12
@spender: 100kB per connected user sounds much for me. –  Jonas Apr 5 '11 at 13:17
@spender: why do you think should 1GB RAM be limiting factor? Anything libevent-based will have no trouble at all serving even more concurrent request in less memory. CPU and I/O are limiting factors here. –  vartec Apr 5 '11 at 14:53
btw. "on the grand scale of things, hardware is cheap" -- not really, on grand scale of things datacenters upkeep might take significant part of your revenue. For example before Facebook started to make their own DCs, in 2007 had revenue of $150M, spent half of it on servers in Rackable's DC. –  vartec Apr 5 '11 at 16:31

7 Answers 7

up vote 4 down vote accepted

Try to look at node.js. This article explains it's magic under the hood.

share|improve this answer
However, I'm pretty sure that each node.js connection uses a 2MB memory heap - which obviously won't allow 10k connections on a server with just 1GB of ram. However, you might want to look at couchdb which might have better luck in this area. –  Xeoncross Apr 8 '11 at 15:45
@Xeoncross can you back that up with a test / benchmark / code / quote from reputable source. node.js was designed for eventedIO and eventedIO is the solution to the C10K problem. I'd hope that a connection takes up far less then 2mb. Preferably nothing when said connection is idle. –  Raynos Apr 8 '11 at 15:52

The standard advice still applies here:

Use whatever you are most comfortable with.

Your goal is not to scale past 10,000 simultaneous users, your goal is to get 10,000 users. In the beginning, you will have only one. Then two, three and so on. As you grow, you can start to worry about performance and scaling.

By the time you have to worry about 10,000 concurrent users, your site will be making enough money that you can run on more than just a VPS with 1GB of RAM. If you can't monetize 10,000 simultaneous users enough to afford a decent host, then you're doing something wrong.

share|improve this answer
Yay for a more progressive approach to scaling. –  spender Apr 5 '11 at 13:28
@vartec: Getting started is harder than scaling. Get something to work, prove the concept, refine the use cases, correct the data model. Then (and only then) consider scalability. –  S.Lott Apr 5 '11 at 15:40
@vartec: It's largely impossible to foresee the future bottleneck from a bad decision taken today. We don't know what the real usage is until real user are really using it. We don't know the real database until there's a real data model with real data and real users. I submit that a rewrite is inevitable because we can't know the future usage given a vague statement of the current wishes. –  S.Lott Apr 5 '11 at 15:55
You have completely misunderstood my question. My question is not a business question, but a technical. Your answer is offending and does not answer the question What web frameworks scales well? –  Jonas Apr 8 '11 at 3:57
@Dean: what makes you think he's not already approaching those 10k users ;) ? –  Matthieu M. Apr 8 '11 at 18:23

Tornado was built exactly for that purpose in mind.

It's been tested to perform at 8K request/second on 2.4GHz 4-core Opteron. On low-end VPS you probably will get less, but YMMV.

share|improve this answer

I think you're perfectly reasonable to expect to be able to do this, after all, when clients are connected for comet or websockets, it's likely that each one will make less than one request per second (depending on what you are using the channel for of course). This means that you aren't looking for a framework that can handle 10,000 requests per second, you are looking for a framework that can handle 10,000 requests at the same time. This distinction is often missed.

Most frameworks operate under the one-thread-per-request model, where in order to complete a request the thread will perform blocking requests to other resources and this simply won't float in your case. With each thread given it's own stack (that on many OSs is a fixed size, often 8MB), it's not viable to have 10,000 threads running simultaneously.

Another model is to have a small pool of threads that are used to handle events via callbacks. And it's this event-driven model that I'd recommend for your project. Recently, node.js has become the major player in event-driven web application design. You should also note that the server software that you use should also be event-driven, so lighttpd, nginx, cherokee are good matches there.

share|improve this answer

You might try some of the Erlang frameworks such as Chicago Boss or the others. I don't have performance numbers but Erlang is well know for its ability to scale.

share|improve this answer
Have a look at Yaws (Erlang web server): yaws.hyber.org –  Torbjørn May 27 '12 at 21:34
Yea I have ;) In fact I wrote a book on yaws shop.oreilly.com/product/0636920021452.do –  Zachary K May 28 '12 at 4:15
Ha, that's funny! Anyway, the comment really wasn't meant for you, but as an addition to you answer. –  Torbjørn May 29 '12 at 5:30
Not a problem. I am a big fan of yaws and am working on 2-3 projects with it right now –  Zachary K May 29 '12 at 6:00

10 thouthands open connections isn't that much, most of those should sit idly and only use a thread when there is an activity. Jetty has good support for such scenario, look for "Jetty Continuations".

http://www.kegel.com/c10k.html might have useful links to other servers/frameworks.

I'd also recommend looking at http://www.tntnet.org/ - this is the fastest web framework I've found and although there's no websocket support I'm aware of, it should be possible to use the usual pull model via keep-alive connections to update the clients.

share|improve this answer

With 10.000 users of 114kbps gprs mobile, you could need a 1Gbps connection. Now put 10.000 users of 3G mobile, (A,S)DSL, T1, etc... you will need much more band.

10.000 concurrent users are not numbers for a standalone, 1G/ram, server.


websockets? are you talking about web? serve 10.000 random static/dynamic files and maybe 10.000 * N, database querys/second? with a single machine?

Come on... there is not framework for that.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.