unicycle



Concurrent Requests

Ratio 10 100 1000



1 To 100 Nonblocking 456.94 608.67 631.82

1 To 100 Blocking 384.82 524.39 532.26

Advantage 18.74% 16.07% 18.71%



1 To 50 Nonblocking 377.38 460.74 471.89

1 To 50 Blocking 266.63 337.49 339.01

Advantage 41.54% 36.52% 39.20%



1 To 20 Nonblocking 220.44 238.63 266.07

1 To 20 Blocking 142.6 159.7 141.92

Advantage 54.59% 49.42% 87.48%



1 To 10 Nonblocking 130.87 139.76 195.02

1 To 10 Blocking 78.68 84.84 81.07

Advantage 66.33% 64.73% 140.56%



1 To 5 Nonblocking 70.05 75.5 109.34

1 To 5 Blocking 41.48 42.13 41.77

Advantage 68.88% 79.21% 161.77%

In a previous post I talked about the problems that plauge the web based Ruby applications regarding processor and memory use. I proposed using non-blocking IO as a solution to this problem. In a follow up post I benchmarked nonblocking vs blocking performance using the async facilities in the Ruby Postgres driver in combination with Ruby Fibers. The results were very promising (up to 40% improvement) that I decided to take the benchmarking effort one step further. I monkey patched the ruby postgres driver to be fiber aware and was able to integrate it into sequel with little to no effort. Next I used themonorail server (the EventMachine HTTP server) in an eventmachine loop. I created a dumb controller which would query the db and render the results using the Object#to_json method.As was done with the evented db access benchmark, a long query ran every n short queries (n belongs to {5, 10, 20, 50, 100}). The running application accepted 2 urls. One ran db operations in normal mode and the other ran in nonblocking mode (every action invocation was wrapped in a fiber in the latter case)Here are the benchmark resultsFull resultsComparing the number of requests/second fulfilled by each combination of blocking mode and conncurrency level. The first had the possible values of [blocking, nonblocking] the second had the possible values of [5, 10, 20, 50, 100]Advantage GraphComparing the advantage gained for nonblocking over blocking mode for different long to short query ratios. Displaying the results for different levels of concurrencyAnd the full results in tabular formIn accordance with my expectations. The nonblocking mode outperforms the blocking mode as long as enough long queries come into the play. If all the db queries are very small then the blocking mode will triumph mainly due to the overhead of fibers. But nevertheless, once there is a even single long query for every 100 short queries the performance is swayed into the nonblocking mode favor. There are still a few optimizations to be done, mainly complete the integrations with the EventMachine which should theoritically enhance performance. The next step is to integrate this into some framework and build a real application using this approach. Since Sequel is working now having Ramaze or Merb running in non-blocking mode should be a fairly easy task. Sadly Rails is out of the picture for now as it does not support Ruby 1.9 yet.I reckon an application that does all its IO in an evented way will need much less processes per CPU core to make full use of it. Actually I am guessing that a single core can be maxed by a single process. If this is the case then I can live much happier if I can replace the 16 Thin processes running on my server with only 4. Couple that with the 30% memory savings we get from using RubyEE and we are talking about an amazing 82.5% memory foot print reduction without sacrificing performance.