NGINX and Unicorn
So, we have all been reading about the wonders of new stuff to replace our old stuff. Well at least we have if we follow what is going on in the Ruby world even a little bit. Specifically there has been a lot of hub-bub and controversy about NGINX over Apache and Unicorn over Mongrel with increasing frequency in the past year or a little longer.
At first the news was pretty lopsided. NGINIX is WAY faster than Apache and Unicorn is WAY better than Mongrel. Lately there has been a lot of blowback along the lines of Hmmmm, not really Apache/Passenger is fine and works great and has a BETTER scaling model. Granted a lot of that blowback has been generated by Passenger developers along with vague references to the next version but still… It was time to find out for myself. Up goes a bunch of test instances on both EC2 and Rackspace for some playing.
Bottom Line and Disclaimers
- I am not running either NGINX or Unicorn in production
- All of my upfront conclusions are based on really small server instnaces
- What I am looking at and care about may be way different than you care about.
Okay, with that out of the way I can say that SSL processing in NGINX is way more better (read efficient) than it is on Apache. I cannot see how this could be a whole lot different for anybody unless they are doing somthing special with Apache and SSL termination, in which case you could do the same thing with NGINX. For me, I always terminate SSL in the webserver. Historically this has been far easier and less costly to scale than more specialized solutions that get very old very quick.
NGINX seems to use a lot less memory than Apache for the same connection load when nnly proxying and serving static content. Of course this could be way different if Apache or NGINX are doing way different jobs for you than the simple job I tested and normally use. This includes any heavy module use of any kind. Look before you leap. An example could be as simple as Apache having a way better rewrite module than NGINX – I have no idea… yet.
Bottom line. On a really small server instance I can proxy to almost as many app servers as I can imagine – amazing.
On to Unicorn. Unicorn is going to make my life a lot easier or at the very least, my servers a lot less complicated. With most of my experience over doing it with the queing / buffering at too many layers is a recipie for problems. Especially where there is no need for it. Of course you want to do it if whatever is on the other front-end is somehow the constraint and cannot stand to be held up for even a moment but if that thing (like a multi-threaded, multi-process, multi-connection webserver) is already doing that job quing requests is useless. It doesn’t make stuff go faster, or increase capacity. In every app I have ever seen, no matter what the underlying tech, doing this just exacerbates the pain when you run out of juice at the end of the line or obfuscates intermittent issues.
Having said that I am all for Unicorn’s request distribution mechanism. Screw the aledged thundering herd issue. You have to be an idiot if you have to scale that big and can’t avoid that with like more than one Unicorn, on maybe more than one socket. At the end of the day I can get rid of some of the sanity checking and automated bullshit clearing stuff that is running on my servers. Unicorn has a lot of features built in that make deployment/managemet pretty simple without a bunch of dispariate tools wired together at home. I’ll take that anyday. If I need some monitoring and control on top of that I will probably add BluePill but I am definitely rethinking my current overly complicated mess when I deploy Unicorn in production.
Oh you want some numbers? Okay but that will have to wait a tiny bit. I plan on doing some more formal analysis on both Rackspace and EC2 this week and over the weekend.
RB
:wq