I happily announce the release of the first NeverBlock enabled activerecord adapter. The neverblock-postgresql-adapter. This is a beta release but I have been testing it for a while now with great results.
And while this is a big improvement it only requires you to replace the driver name in the connection to neverblock_postgresql instead of postgresql as described in the official neverblock blog
To make a long story short, this enables active record to issue queries in parallel, much like in a multi-threaded application. But this has several advantages over multi-threaded operations:
- Fibers are cheaper than threads so this solution is theoretically faster.
- NeverBlock does not require full thread safety, just avoid using globals and static variables for transient state.
- It integrates nicely in evented programs thus eliminating the performance drop which occurs with the introduction of threads in such environments
I have benchmarked this against the plain postgresql adapter using different workloads categorized as follows
Very Light : A single count statement
Light : A single count and a create
Moderate : 2 counts and a create wrapped in a transaction that rolls back
Heavy : 3 counts, a create and an update wrapped in a transaction that commits
Very Heavy : 3 counts, one conditional count (on a non-indexed field), a create and two updates all wrapped in a transaction that commits
(if you are wondering why these queries in particular, they were extracted from some other code)
All were issued 1000 times
The results came as follows:
As you can see, NeverBlock::AR is persistently faster than vanilla AR. It appears that such work loads generate linear increase for both AR and NeverBlock::AR as the NeverBlock advantage was almost the same
Another benchmark was performed to test the effect of increasing the connection count for NeverBlock::AR. We tested with 2, 4, 8, 16 and 32 connections.
The benchmark consisted of first running “select 1” 5000 times and then running “select sleep(10)” “select sleep(1)” 20 times for each configuration.
As you can probably guess, increasing connection count has very little effect if the queries are all very fast (you cannot beat “select 1”) but if the queries are all slow, you will be able to double the performance by simply doubling the connection count.
I hope this gives you a glimpse of what’s coming next. Watch this space
Oldmoe's blog 
Leave a reply to brandon Cancel reply