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:
- NeverBlock now supports Ruby1.8.
- NeverBlock support for Thin and Mongrel servers.
- 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 Support for Thin and Mongrel Servers
Users of Thin or Mongrel servers can now enjoy writing NeverBlock applications that utilize those servers. We are working on adding support to other servers like Flow.
Note: Mongrel support is currently broken. It will be fixed asap.
NeverBlock Now Supports Ruby on Rails
This is the main feature of this release. An end to end seamless support for the Ruby on Rails framework. Adding support for Rails is as easy as modifying a line in your database.yml and adding 2 lines to your environment.rb file. The first of which is:
NeverBlock for Rails currently supports the following configurations:
- Thin or Mongrel as an application server To enable NeverBlock for your server put the following line in the environment file you want to enable NeverBlock for. or
- PostgreSQL or MySQL as a database server To use the ActiveRecord NeverBlock adapter instead of the stock ones simply add a neverblock_ before the adapter name in database.yml or You can also specify the number of connections you want to spawn by adding: Note: It is preferrable if you have a separate environment for NeverBlock (e.g. neverblock_production) since NeverBlock does not degrade gracefuly (yet) if no server is present. This will cuase your script/console and rake tasks to not function properly. It is better if you have two environments looking at the same database.
You will need to install the required gems before you are able to use NeverBlock with Rails
- Download NeverBlock (zip|tar.gz), Mysqlplus (zip|tar.gz), EventMachine (zip|tar.gz)
- Uncompress and do the following for each
# build them gem using the .gemspec to obtain the .gem file gem build (respective file name).gemspec #install the gem file gem install (generated file name).gem
One more thing to note is that installing the mysqlplus gem might require having libmysql++-dev. If you're on a debian distribution you can do the following
apt-get install libmysql++-dev
Once the support is added your application will be able to serve requests concurrently by mutliplexing database operations.
We have tested the NeverBlock stack against the old Rails stack using the following configuration:
- Rails 2.1
- Thin 0.82
- Ruby 1.8.6
- MySQL 5.0
- A special build of EventMachine 0.12
The special EventMachine gem adds a few features to the plain EventMachine. The changes are being merged in the main branch now and should be available in the next EventMachine official release.
We have built a trivial Rails application that would run a slow request every x fast requests. Slow requests are simulated by running a "select sleep(1)" inside the action body while fast requests will issue a "select 1"
Workload was distrivbuted as follows:
1 - Moderate work load, one slow request for every 050 requests 2 - Heavy work load, one slow request for every 020 requests 3 - Very heavy work load, one slow request for every 010 requests
We tested a single NeverBlock::Thin instance against one, four and eight normal Thin instances. We used Apache Bench to benchmark each configuration with 1000 requests and a concurrency level of 200
Here are the results
Rails Performance (Thin Vs.NeverBlock::Thin)
The scaling characteristics under heavy load were benchmarked, we did so with 500 and 1000 concurrent requests.
Thin scaling
NeverBlock::Thin scaling
Memory consumption was recorded for the different configurations
Memory Consumption (Thin Vs. NeverBlock::Thin)
For other benchmarks using Ruby 1.9 and PostgreSQL check here
