NeverBlock: Instant Scaling For Your Rails Apps

Today marks a milestone in the short history of NeverBlock. We have pushed a new release with lots of new features, mainly:

1. NeverBlock now supports Ruby1.8.
2. NeverBlock support for Thin and Mongrel servers.
3. NeverBlock now supports Ruby on Rails.

Let's iterate over the above points and explain them in more detail.

NeverBlock Now Supports Ruby 1.8

Utilizing Aman Gupta's Poor Man's Fibers we were able to add Ruby 1.8 support to NeverBlock. Thankfully this does not mean that applications written for NeverBlock now require full thread safety. Aman's implementation makes sure one thread is scheduled at a time. The fibers don't fight for CPU time so the solution is free of race conditions. The performance penalty is not very big and we were able to extract some very good figures during lab testing.

NeverBlock MySQL Support

We are pleased to announce the availability of a MySQL database driver for NeverBlock. This is the second database driver for NeverBlock after the PostgreSQL driver. We hope that with time, this family will grow.

Of course the driver does all that you expect from a decent NeverBlock driver. It can do IO operations concurrently and in a transparent manner, thanks to NeverBlock. An interesting side effect emerged during the development of this driver. We were required to update the current MySQL driver to be able to do async operations. Once those were done, we discovered that the basic foundation for threaded support was there. Hence we went forward and implemented it (with help from Ruby gurus like Aman Gupta and Roger Pack).

NeverBlock and ActiveRecord, Concurrent DB Access Without Threads

A new neverblock_postgresql activerecord adapter has been released. This new adapter makes it possible for applications using activerecord to utilize multiple connections to do queries in parallel in single threaded applications. This results in much higher performance and better CPU utilization.

What do I need to do?

If you were using the vanilla postgresql adapter you would’ve initialized the connection as follows:

Now, to use NeverBlock all you need to do is:

Note: you must have the pg, neverblock, neverblock-pg and the activerecord-neverblock-postgresql-adapter gems installed

This way the AR library will pick the gem and use neverblock_postgresql instead of the postgresql adapter

Fiber Pooling With NeverBlock

As mentioned in my earlier introduction about fibers I will be talking today about the fiber pooling features that are implemented as part of the NeverBlock library.

The fiber pool is implemented as the NeverBlock::Pool::FiberPool class. The interface is super easy, with only one public method spawn that is. Here’s an example

The spawn method take only one argument, which is a code block to be run as a fiber. The spawned fiber will resume immediately (that is, if the pool managed to find us a free fiber immediately).

An Introduction To Fibers

You know Thread, but have you heard of his red haired step child? Fiber? Fibers are a new and a note worthy addition to Ruby that appeared with 1.9. They are essentially code blocks that can be paused and resumed. They have to be forced to do so, unlike threads which are well mannered and just step aside when someone is in a hurry. Fibers are not a totally new ideas, they have been known for ages as Coroutines. But how does those fibers work? Let’s start by the canonical example:

The very first time we called resume, the fiber sprang to life and the loop started, then when it hit Fiber.yield it returned to the caller with the value to the right side of the Fiber.yield (i in this case which is equal to zero in the first iteration). When resume is called again, the fiber continues from where it stopped so the loop continues, i picks the value 1 and then yields it back. This continues till the fiber block is exhausted, at this point, calling resume on the fiber will raise an error.