Comments on: Asynchronous Database Access in Ruby

By: links for 2009-12-17 « Bloggitation

links for 2009-12-17 « Bloggitation — Fri, 18 Dec 2009 06:08:08 +0000

[...] Asynchronous Database Access in Ruby – igvita.com (tags: ruby database mysql eventmachine programming) [...]

By: links for 2008-09-24 « Brent Sordyl’s Blog

links for 2008-09-24 « Brent Sordyl’s Blog — Wed, 24 Sep 2008 14:01:11 +0000

[...] Asynchronous Database Access in Ruby Ruby alternative, keep an eye on Aman Gupta's recent project: em-mysql. An EventMachine wrapper around MySQLPlus, it is already showing very promising results: (tags: ruby rubyonrails performance mysql eventmachine) [...]

By: Ilya Grigorik

Ilya Grigorik — Mon, 08 Sep 2008 01:35:26 +0000

Gregg, oldmoe pretty much covered it. I wanted to simulate a web-server benchmark, hence I used EM to create a simple HTTP web-server. However, EM-MySQL also uses the same reactor loop to interface in async fashion with the DB. Hence, yes, the request to the DB is sent immediately.

Hope that clears it up - if not, keep asking!

By: Desire Mesh » Blog Archive » Asynchronous database access in Ruby

Desire Mesh » Blog Archive » Asynchronous database access in Ruby — Sun, 07 Sep 2008 16:02:59 +0000

[...] one commenter mentions in this post: “Looks like Asynchronous database access is the next big thing.” Well, it looks like [...]

By: oldmoe

oldmoe — Sat, 06 Sep 2008 16:59:05 +0000

@Gregg, EventMachine is serving a dual purpose here. It listens for connection requests on port 8083 and it also listens on the file descriptors of the mysql connections for readbility notifications. As you can see in the example, the query is given a callback block which will be run when you receive a notification from EM that there is data available for this connection. This callback handling is hidden by the EventedMySQL driver.

By: Gregg Pollack

Gregg Pollack — Sat, 06 Sep 2008 16:48:55 +0000

It’s not entirely clear to me what EventMachine adds to the mix here. Is it just acting as a network server? so you could send all database requests at it, and it takes care of running and returning the results?

You’re not using “proc” and allowing each request to hit the database as it comes in (which is the benefit of a non-blocking mysql driver). Or is that hidden behind EventedMysql? and it’s actually hitting the db immediately?

By: oldmoe

oldmoe — Sat, 06 Sep 2008 04:02:13 +0000

@Ilya, the Ruby 1.8 implementation is based on a Fiber emulator written by Aman Gupta. It implements fibers via Ruby green threads and so far I have seen only a small performance penalty. Complete thread safety is not even a requirement as fibers will not be preempted (within the thread that created them of course). Using the fiber pool limits the number of fibers (threads) and thus lessens the performance impact as well. Check here: http://www.espace.com.eg/neverblock/blog/2008/09/04/neverblock-instant-scaling-for-your-rails-apps/

By: Ilya Grigorik

Ilya Grigorik — Sat, 06 Sep 2008 02:34:33 +0000

Bastiaan, I believe the Ruby 1.8 implementation uses coroutines, which are extremely slow and inefficient in the current MRI - probably not something you’d want to use in practice.

By: Bastiaan Peters

Bastiaan Peters — Sat, 06 Sep 2008 00:21:34 +0000

I believe people here [http://www.espace.com.eg/neverblock/blog/2008/08/28/neverblock-mysql-support/] claim 1.8.x support for neverblock?

By: Stephen Paul Weber

Stephen Paul Weber — Fri, 05 Sep 2008 13:31:39 +0000

provide a great abstraction layer, which hides much of the database access logic and complexity

Hence why I don’t like it too much…