Thin benchmark (with and without threading)
Thin is natively not based on the thread per request philosophy. It relies on the highly efficient EventMachine for lightning fast I/O. Although many benchmarks show Thin as being one of the fastest web servers for Ruby out there (like this one, which is great), many still don’t trust its single-threaded philosophy. Hearing the masses, its creator (Marc-André Cournoyer) decided to implement an experimental feature using threads: Thin can create a pool with 20 threads on start and forward every request it receives to this pool.
Setup, test and configuration
I’m assuming you’ve read my posts regarding the machine used, the Thin’s version and its configuration. The proxy server is Nginx and it uses 4 Thin worker processes (with and without threading)
Let’s see how this great feature based on a old-fashioned principle stacks up at Escolinhas. The pages used are the same from my previous benchmark at “Proxy performance in a Thin cluster environment” as well as the test configurations regarding requests/concurrency.
Results
Conclusions
There is one obvious conclusion: Threaded thin actually performs worse that non-threaded thin, while using more memory. The only exception is on the “Light page” test, with 500 requests and 100 concurrent, where threaded Thin slightly wins over non-threaded Thin (by less than 400ms). Threading can have many brilliant applications, but its associated processing overhead is actually slowing Thin down.
If you’re using or considering using Thin, never mind its threading capability. It’s not worth it, when analyzing from a performance perspective.
