z8000

It would quite funny to replace the pins on the map with d*cks for those users showing off their wares.

It would quite funny to replace the pins on the map with d*cks for those users showing off their wares.

You should probably ask this on stackoverflow.com.

Oh, so that's what became of _why.

"Blogging Pro"? Right. My unborn child has a better grasp of basic grammar rules. What an annoying thing to read!

Isn't 1300 users per box extremely low for a load test?

I was going to say "We should hang out" but we would probably tear each other's eyes out.

Cherokee also tries to use HTTP 1.1 keepalive to upstream processes. NGiNX uses HTTP 1.0. I doubt this matters in most use cases however.

I thought of this idea the other day and got stuck on how to best push messages to hanging clients in a generic way instead of the simple requestNumber request-response correlation here. I ended up just making it app specific and either generating a unique client ID per hanging connection (a UUID) or using the username of the logged-in human using the hanging client.

Anyway, this is a nice architecture indeed.

However, as a pure proxy, I would think nginx would be more appropriate for its (albeit poor but swappable) load balancing, rate limiting (a 3rd-party module), caching (memcache, redis), and general volume of usage.

In fact, there's the beginnings of a nginx upstream based redis module that supports redis' GET that could be made to RPUSH and BLPOP the result.

FWIW, I'm the author of redis-node-client. It should be noted that Promises were removed in favor of continuations in the latest Node.js on Github and I've updated redis-node-client appropriately. Thus, the sample code in the article is outdated by 2 days or so.

Using LPOP in a polling loop to wait for the response is not that great of an idea. It would be better to use BLPOP or "blocking left pop" which blocks the client connection (think "long polling") until there's something in the given list to pop. It does not waste resources and the results are returned in much less than the worst case (e.g. 100ms here). I haven't added BLPOP to redis-node-client yet though but it should be simple to patch.

To scale this beyond a single frontend, popFromQueue could potentially put the response back via LPUSH when the queuedRes[requestNumber] is nil... "Oops, this wasn't for me, let me put that back." Or, it could/should use something more formal.

Why does the Ruby worker shell out to redis-cli instead of using Ezra's client library?

Finally, "The previous spike..." What does "spike" mean here?

I'm curious why haproxy is in the mix. There's a couple of better balancers for nginx if that's why.

    10. Late Night with David Letterman Theme

What?! I watch that show somewhat regularly and doubt that I would recognize it unnamed.

Wow. I was not expecting to read "paster" nor "mysql" in that presentation!