Iowa Performance
Here are a few simple performance tests that will give an idea of Iowa's performance. All tests were ran on a machine running Gentoo Linux with Ruby 1.8.1 and Apache 1.3.29. The machine has an 800Mhz Pentium III processor with 512Mb of RAM. The server was not completey inactive, as it also runs a full X windows desktop and had several applications, including Eclipse, running in the background. Each test was ran using ab2, with 100 requests and a concurrency of 1 (concurrency seems to matter very, very little with regard to measured Iowa performance). The content in all tests was an identical 4454 bytes of data. It was a page that incorporated three components and several dynamically generated sections of content. Tests were ran using a unix domain socket.
- Baseline test: Delivering the content as a static HTML file using Webrick
-
Time taken for tests: 1.864047 seconds Requests per second: 53.65 [#/sec] (mean) Time per request: 18.640 [ms] (mean) Transfer rate: 245.70 [Kbytes/sec] received - Iowa w/ mod_ruby handler
-
Time taken for tests: 2.801899 seconds Requests per second: 35.69 [#/sec] (mean) Time per request: 28.019 [ms] (mean) Transfer rate: 163.10 [Kbytes/sec] received - Iowa w/ FCGI proxy
-
Time taken for tests: 2.611732 seconds Requests per second: 38.29 [#/sec] (mean) Time per request: 26.117 [ms] (mean) Transfer rate: 174.98 [Kbytes/sec] received
In earlier tests the mod_ruby handler seemed to be performing 1-2 requests per second faster than the FCGI proxy. Those test were done using TCP socket communications, however. Current tests using Unix domain sockets show the FCGI proxy communications to be consistently 2-3 requests per second faster than the mod_ruby handler. Concurrency is largely irrelevant to performance. A few quick tests with the FCGI handler and concurrencies of 20, 40, and 100 showed speeds of around 36, 35, and 33 requests per second, respectively.
One limiting factor with Iowa performance relates to the way Ruby handles TCP socket connections. It seems that even when the BasicSocket.do_not_reverse_lookup property is set to true, that a hit to the DNS server occurs (gethostbyaddr call, I believe). So, if the DNS server is exhibiting poor performance, Iowa performance also suffers. If anyone knows of a way around this, I would love to hear about it.
In a future version of Iowa a multiprocess backend will be supported that will allow much greater performance scalability.
Iowa is also very good regarding memory consumption. A general statement on overall consumption is difficult to make, as total consumption will depend greatly on the number of sessions in the sessions and pages cached as well as on what other data structures the code for the pages is producing. The Iowa code itself, though, is very flat in its memory consumption.
As an example, the current enigo.com web site consumes about 8.5 megabytes of memory, as an Iowa process, when first started. In testing on a development machine, a benchmarking tool was used to run 1,000,000 hits against a single page. The memory memory usage remained completely flat. After the million hits, the process still sat at 8.5 megabytes in size. In real world use, with hits against all of the various areas of the site, the process size ends up growing to around 12 megabytes in size with all of the data that ends up in the caches, then it stabilizes and does not grow further, regardless of how long the process stays running.
