Comments on: Ruby EventMachine - The Speed Demon

By: Concurrency is a Myth in Ruby - igvita.com

Concurrency is a Myth in Ruby - igvita.com — Thu, 13 Nov 2008 17:16:39 +0000

[...] is powered by a cluster of app servers (Mongrel, Ebb, Thin), and alternative strategies like EventMachine, and Revactor (equivalents of Twisted in Python) are gaining ground as a simple way to defer and [...]

By: Asynchronous DB: DBSlayer & HTTP - igvita.com

Asynchronous DB: DBSlayer & HTTP - igvita.com — Mon, 11 Aug 2008 16:12:04 +0000

[...] to easily turn any HTTP request into a non-blocking request! Borrowing some sample code from my previous post on Ruby EventMachine, we have an easy Ruby web-server (port 8082) which makes an asynchronous DB call to fetch the [...]

By: Ilya Grigorik

Ilya Grigorik — Mon, 16 Jun 2008 00:37:12 +0000

Jens, that’s a great point. As odd as it sounds: it’s so refreshing to work in a shared nothing state of mind!

By: Jens Alfke

Jens Alfke — Tue, 10 Jun 2008 14:49:36 +0000

This all sounds very familiar to me, as it’s the way the Mac OS X frameworks (CFNetwork and Cocoa) operate. Nice to see this approach being used elsewhere!

One other advantage you didn’t point out is that, by avoiding multithreading where possible, you can leave your code simpler and easier to read (and debug!) since it doesn’t have to deal with deadlocks or race conditions. I’ve written lots of networked Cocoa code and almost never had to deal with thread synchronization or locking, thank god.

By: Ilya Grigorik

Ilya Grigorik — Fri, 06 Jun 2008 12:13:41 +0000

Jan, good point, here are the results:

Concurrency Level: 20
Time taken for tests: 4.61886 seconds
Complete requests: 40

By: Jan

Jan — Fri, 30 May 2008 02:56:15 +0000

I think you should post the result of

ab -c 20 -n 40 “http://127.0.0.1:8081/”

for comparison (let threaded version run on 8081)

By: This Week in Ruby (May 29, 2008) | Zen and the Art of Programming

This Week in Ruby (May 29, 2008) | Zen and the Art of Programming — Thu, 29 May 2008 23:56:38 +0000

[...] do so. Other must-read tutorials and articles were Ruby && DTrace! (really neat results), Ruby EventMachine – The Speed Demon by one of my favorite Ruby bloggers, and Will’s Guide to Mashing-up Remote Databases using [...]

By: Ilya Grigorik

Ilya Grigorik — Thu, 29 May 2008 17:11:45 +0000

Patrick, I think the implementation depends on the underlying kernel. I would hope that most modern systems would default to per-page model you’ve described, but as we all know, assumptions are dangerous. In either case, fork is expensive (but has its benefits against memory leaks, security, etc.), so if you can use a threading/evented server.. you should.

Harish, yep, that’s certainly the idea behind any remote worker pattern. BackgrounDRB specifically allows you to delegate a job to remote server, plus gives you the ability to memoize the results, check status, etc.

In general, your ability to make a synchronous call asynchoronous (aka, delegate it) seems to be directly correlated with your ability to scale your application. ;)

By: Harish Mallipeddi

Harish Mallipeddi — Thu, 29 May 2008 15:17:00 +0000

@Ilya, I guess you can do that but in the end you’re just delegating the CPU-intensive task to someone else so you can be event-driven and single-threaded. I’m not much of a Ruby guy myself but is this how Backgroundrb works?

By: Patrick Dubroy

Patrick Dubroy — Thu, 29 May 2008 14:17:22 +0000

@Ilya: But copy-on-write is on a per-page basis, right? So there’s not an up-front copy of the entire address space, it happens 4k at a time. And hopefully subsequent writes will tend to be on pages that have already been copies, rather than a new page each time.

I could be wrong, but I would think that in something like a web server, which doesn’t have to do a lot of writing to its heap variables, the context switch overhead would be the problem, not the memory copy.