Post Tagged with: "Unicorn"

Following on from my recent attempts at benchmarking Ruby VMs, I decided to test all the server options available for the MRI (1.9.3p0) platform against each other. This is still just running the simple “Hello World” Sinatra app, that uses an erb template so there is more processing involved than simply outputting a string.

The Contenders:

• Thin 1.3.1, running in production
• Puma 0.9.3, running in production
• Mongrel 1.2.0.pre2, running in production
• Webrick 1.3.1, running in production
• Passenger 3.0.11 standalone, running in production
• Unicorn 4.1.1, 1 worker process, running in production

The results are as below for “ab -n 10000 -c 1”: (higher is better)

Additionally, we need to care about how long the slowest requests are taking, so I’ve taken the response times of the 98% percentile from the AB testing, and plotted these here: (lower is better)

I’m quite surprised by this, if I’m honest. Unicorn certainly has a great reputation, and this would illustrate how strongly it performs here. Thin also has a great reputation, and is the other standout performer on this test. However, I’m really surprised by how far behind Mongrel is – for a server which is so trusted and widely used, being under half of the Req/sec that Unicorn offers is astonishing. Thin and Unicorn also are hugely much better in their response times, with 98% of users having a response around 2ms, whereas WEBrick for example is very much worse – at well over 10ms. In a real world application, this is an essential measure of how performant the server will be, and how satisfied the users will be.

Running the tests with “-c 1”, doesn’t allow some of these servers a chance to shine, as many of these can drastically increase throughput by forking requests, or using evented systems. In part 2, we’ll look at increasing the concurrency of requests, and how this affects matters.

One of the cool things about Heroku is that it makes life really easy for those who use it – and for 99% of applications I love being able to simply forget about sysadmin tasks and just get on with writing code. Lots of people have started using Unicorn to serve apps on Heroku, which allows you to fork off worker processes to absolutely maximise the computational power of each Dyno. There have been some great articles on this, such as this one on using Unicorn and this one on using resque workers in-dyno. This certainly can give you a performance boost, but I’ve never been a massive fan of Unicorn, much preferring Thin. I’m not going to go into a full discussion of Thin vs Unicorn and the relative merits of each system, however normally the discussion is a Unicorn system with 3/4+ workers, vs a single instance of Thin per Read more…

Designing the Tags So far we have an application which allows us to create users, login, and create/destroy posts – which is really the core functionality of an application like this. The difference between the basic functionality and an application which can actually be used is in the details. Twitter allows you to denote that you are referring to a specific topic by using a “hashtag” – a #, followed by some alphanumeric characters. For example #bostonredsox or #1966. In order to do this, we need to store this data somewhere. This is where using a traditional schema-based DB causes us some problems, as we have to define our fields in advance – if we allow a post 1 tag, then this is not an issue – we can create a field for it in the database, but if we allow n number of tags, then we have a problem. Read more…