Why would I want to use unicorn or thin instead of WEBrick for development purposes?

Question

I've recently found that some people prefer using unicorn_rails instead of the default WEBrick as a web server for developing Rails applications.

I understand that if I wanted to use unicorn in production, it could make kind of sense to try it out in development, but since the configuration is different in production, is it even relevant?

Is there any real, tangible advantage that I would get from using thin or unicorn instead of WEBrick for developing a Rails application, such as speed or some additional features? Or is this just a matter of personal preference?

Ovid

Interesting question. I abandoned WEBrick in development because it constantly crashes when using the debugger in ruby 1.9.3. Using thin, things come up sooo much faster. I always assumed WEBrick was primitive and designed for development only. I'm very happy using thin for development, and unicorn gives me 1-second downtime on deployments. (I couldn't get unicorn to work with the RubyMine Debugger, no such problem with thin). – Haywoodhayyim

Thanks for not asking another one of those "What's the best..." questions that will be "closed as not constructive". This question is very helpful for a community like SO :) – Coelostat

Answer 1

It is important to develop as closely as possible to the production environment. It helps ensure that an application will work as expected when deployed into production, instead of stumbling upon bugs at runtime.

This issue is alleviated with the use of Continuous Testing on a Build server that replicates the production environment. Even though you are not actively developing on an identical environment, the Continuous Testing gives you coverage that the application is functioning in the expected way.

As to speed, the performance hit running a Rails app in development mode will negate any benefit the various web servers brings.

Bidding

Answer 2

In addition to the other answers giving a pretty good overview already, there is also a technical reason you might want to consider using unicorn over WEBrick:

WEBrick does not support subdomains. Support for HTTPS is rather hacky to implement.

So if you have an SaaS application using subdomains, or if you simply want to have admin/api/... subdomain, then WEBrick is not an option. There is POW for Mac OS X, but this won't work for Linux developers.

Antacid

+1 for mentioning POW. Makes life simple, if you're on a Mac. – Yearling

Answer 3

My personal experience is that Unicorn is much much faster then WEBrick when using a remote machine (ubuntu, 4 cores, 8G mem, connecting though VPN -> ssh) as your development environment (as I do) -- I see sub-1 second page load times with Unicorn, while WEBrick takes 3 to 5 second or more. I'm not sure why, it may have more to do with my network then anything else, but that is what I personally see.

I haven't used Thin for development, as I've read that it requires an additional gem to allow for class reloading in development mode (I can't personally validate the accuracy of that). Also, I am more familiar with Unicorn and use it in production.

Mackey

Which gem would one use with Unicorn to support for class reloading (when the class changes). That is my only reason for preferring Webrick. – Pru

Without doing some more research, I couldn't name a gem. However, you could use a watcher and the HUP signal with the proper config. See: unicorn.bogomips.org/SIGNALS.html. As I said, I typically use WEBrick for development to dynamically reload classes. – Mackey

Answer 4

My personal experience is that WEBrick is faster in my development environment than Unicorn and Thin (OS X) in a pretty big Rails app (lots of gems, routes etc). But you should measure it yourself, with your app in your machine to see (I tested using ab and using Chrome's developer tools).

However using the same server in production and development is a very good idea.

Crowning