Webrick as production server vs. Thin or Unicorn?

Question

It seems like it\'s taken for granted that you must not use Webrick as production server, but I can\'t really find anywhere mentioning why. The consensus seems to be: \"Webr

Answer 1

The greatest weakness of webrick when running in production mode is that it's single threaded, single process web server, meaning that it is capable of serving only one single http request at a time.

Answer 2

WEBrick also can't handle longer URI's, if they exceed 2083 chars you'll see a crash. Thin does not have these problems, which made it superior - already in development.

Answer 3

I don't really like complicating simple things and premature optimization. WEBrick can be used in production provided it's rather a low-traffic website. Most of the applications are.

If your site does something that takes time, e.g. sends e-mails or generates PDF files, you should make WEBrick multi-threaded. You want to handle multiple requests at a time.

Answer 4

It has had some security issues in the past, but it seems the big reason is that it's really slow compared to the servers that are intended for production.

Answer 5

A couple important reasons

1. it's written in Ruby (see http://github.com/ruby/ruby/tree/trunk/lib/webrick)
2. Edited it doesn't have many features that a production website usually needs, like multiple workers (in particular, pre-forking, life cycle management, asynchronous handling, etc), redirects, rewriting, etc

When I mention redirects/rewrites, I'm referring to the fact that using Webrick, you have to handle rewrites at a different layer (Rack, Sinatra, Rails, custom Webrick code, etc). This requires you to spin up extra ruby "handlers" to perform your rewrite code. For a low traffic site, this may be fine as you may have pre-warmed processes doing nothing already. However, for a higher traffic site, this is extra load on the server for something that the front end servers (Apache, Nginx, etc) can handle without spinning up Ruby*, and probably orders of magnitude faster.

* for example, if you are running behind a load balancer, you could route all rewrite traffic to a server that does not have ruby installed, and let your main servers only manage the primary traffic. This rewrite traffic may be due to site changes for SEO, or something similar. Another case would be a site that has multiple components, and maybe one section is Rails, another is PHP, and rewrites are needed for both (i.e. rewrite old PHP paths to Rails)