C500k in Action at Urban Airship

I'm curious what kind of OS tuning was required for 500k concurrent connections. It's obvious that some ulimit tuning is necessary, but I'm wondering if any other hard limits beyond that were hit? Also, in case the original author is reading, you might find this interesting as well. It's an article on trying to reach 1MM concurrent connections with Erlang.<p><a href="http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-1" rel="nofollow">http://www.metabrew.com/article/a-million-user-comet-applica...</a>

Thanks for doing this, definitely very interested in the follow up posts. Having just finished working for a company that 'claim' to be experts in this area it is very interesting to see you guys wipe the floor with your connections/node ratio.

<p><pre><code> Jumping from 35,000 connections per node on an EC2 Small instance to over half a million on a single EC2 Large... </code></pre> You moved the goalpost. I think the conclusion would make a lot more sense if you compared apples to apples when it comes to your server... either test everything on a small or on a large.

Can someone clarify what a spike is? It doesn't appear to refer to just resource load...<p><i>"...we spent several hours fanning out that spike to include three versions"</i>

Why the difference when working with code written in Scala?<p>What does Scala do to make the number of connections 50% less?

I'd be particularly interested to know what the JVM spikes were doing with their respective connections. I'd love to profile some roughly-equivalent implementations using Erlang/Twisted/libevent/et al.<p>FOR SCIENCE

Interesting, but I wonder why they didn't take a look at Erlang - I mean this is pretty much what it was meant to do.

Someone mentioned this in the comments, but I'm curious about the outcome of the Node.js spike as well.

Does keeping a socket open affect the handset battery life much?