This article is a stub. You can’t help, I’m going to make it a full-fledged blog post in the future. As for now — Unicorn ;) is Awesome
Unicorn’s killer features
…or simply advantages over other Rails application servers (Passenger, Mongrel etc.). This is a quite personal list of things that really made me go “wow” while and after tinkering with Unicorn and migrating three deployments (development, beta, production) of one application from Passenger to Unicorn.
So, here’re the things that make Unicorn awesome for me:
- no matter the amount of instances, application code is loaded from disk only once, by “master” Unicorn process (the one that just passes requests and manages workers), worker processes get the memory copy using fork()
- restarts of the application with zero downtime; simplifying things a bit, Unicorn basically serves old version of the application while the new one is loading and jumps to serving new one the moment it becomes available (it’s a bit more complex under the hood, but that’s what it looks like for the client)
- master process manages all the workers by himself, taking care of killing them, spawning new ones or changing the number of workers caused differenly (see below)
- whole management of Unicorn done via Unix signals
kill -HUP2 `cat /tmp/unicorn.pid` # to restart the application kill -QUIT `cat /tmp/unicorn.pid` # graceful termination (workers can finish processing)
and these are just two examples from the top of my head (ok, from Capistrano scripts I wrote today). - incrementing and decrementing amount of workers is also done by simply sending signals (respectively TTIN and TTOU)
- …and other stuff that Unicorn has and does because basically Unicorn is very Unix
More to come soon!