Proxy performance in a Thin cluster environment
When scaling and using a proxy, it needs to be able to forward requests efficiently so the workers can to their job.
This benchmark will focus on proxy performance. The back-end will be constituted by 4 Thin servers waiting for the proxy to forward them requests. Their configuration is exactly the same, so their efficiency will be dependent on the proxy’s ability to efficiently forward the requests.
Setup
Three web servers will be acting as proxies in this analysis:
Four instances of Thin (version 1.2.5) will be doing the hard work in the background and responding to client requests.
Test
This benchmark uses three pages of the full-featured and consequently heavy web application Escolinhas. One of the test pages is relatively light and the other two are heavy, high-demand pages.
Apache’s ab was used to do the benchmarks, with different number of requests and concurrency:
- 50 requests, 1 concurrent
- 100 requests, 10 concurrent
- 500 requests, 50 concurrent
- 500 requests, 100 concurrent
- 2500 requests, 500 concurrent
A record was kept of 3 essential results:
- Number of requests per second processed
- Time taken for the tests
- Average memory consumption of all the processes involved (Apache/Nginx/Cherokee and all 4 Thin workers) using /proc/{pid}/status
Configuration
The important sections of the proxy servers’ configurations can be seen here:
Thin itself had a pretty standard configuration.
The Operating System - Gentoo Linux, as I’ve mentioned before - also needed some tunning. I increased the maximum opened files (no socket creation errors) and changed sysctl.conf a bit, so it could handle such high concurrency.
Results
Conclusions
A few conclusions can be drawn from the above table.
The first and the most important is Nginx+Thin’s memory usage. It’s quite low and impressively stable, whether it’s a light or a heavy page. This combination brings an impressive scalability potential. This benchmark only used 4 Thin processes as worker threads, but this setup could easily scale to 50 worker processes without running out of memory (on this setup, of course).
On low concurrency (50/1), Cherokee wins a couple of rounds and Apache wins the remaining, but the difference between all three is not really noticeable.
When concurrency rises (100/10, 500/50 and 500/100), Nginx seems to be a bit faster and, again, the lighter in memory usage.
Finally, when things get really heavy, the only setup able to complete the benchmark was Cherokee+Thin, although with quite poor results. It took it over 16 minutes to attend to 2500 clients, while being completely locked. Nginx+Thin completed a few requests but most of them resulted in errors, so it accounted as failed test. Apache also completed a few requests before becoming unresponsive, but much less than Nginx.
Final remarks
Nginx seems to be the choice here. It had a similar performance to the others, winning a considerable number of tests, but it has no really opponent when it comes to memory usage - that is where Nginx really shines.
What next? Let’s see how Passenger stacks again Nginx+Thin. And to make things more interesting, Nginx+Unicorn will also be thrown into my benchmark table, mainly because Twitter adopted it - it won’t certainly be bad when scaling.
