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: "Webrick is ok for development, but Thin or Unicorn is the choice for production, period."

I did look up Thin server's homepage and it talks about requests/second but I don't really understand the graph since there's no annotation.

Can anyone let me know why I should use Thin or Unicorn compared to Webrick? Also is there any benefit to using Webrick for development? I've been using Webrick since it comes with rails, and I think there should be a reason why it's default.

I'm using Heroku by the way.

Prescriptive

Its slow when compared to others like Mongrel. – Terrieterrier

Ken, I really did not ask this question to debate anything. I genuinely want to know the answer because I couldn't find real stats anywhere, when everyone is taking for granted Webrick is inferior. I am not affiliated with any of those parties and the debates you mentioned are questions I'm asking out of genuine curiosity. How can I rephrase the question so it doesn't look that way? – Prescriptive

I'm not sure you can. :-) The question isn't really a question - why you shouldn't use a tool designed for quick and easy setup for development as an actual production tool should be very clear, without the need for explanation. "Why can't I trust my credit card number to the secure site my friend invented for me to try?" - software designed strictly for development isn't supposed to be used in production; they're not tested for that use, aren't designed for that use, and shouldnt' be expected to work for that use. Elephants and airplanes don't compare, with or without stats. – Siglos

@KenWhite Either it's an open ended discussion question, or there's one very obvious answer. You can't have it both ways. – Extraction

@alnorth29: It's a discussion question (read the title of the question itself). It's also six months old, but thanks for your comment anyway. – Siglos

Questions like this should NOT be closed. They're useful and helpful. All self-appointed content police should back off. – Musca

I found this by googling "Why not use WEBrick in production?" because it's a question I want answered. I don't mean to use WEBrick in production, but I do find it annoying that everybody says, "Because it's not For Production®, obviously." It's really not that obvious—if it were, people wouldn't be researching the question before finally asking on StackOverflow, as @Prescriptive indicates he did. The accepted answer is helpful; at least points out some missing features. Tangentially, insisting that a question be closed because you think it's moot without providing your own answer is not helpful. – Reflector

Answer 1

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)

Thorncombe

Isn't it possible to use delayed_job to handle multiple workers on Heroku, regardless of which server you use? – Prescriptive

Yes, delayed_job is unrelated to Webrick, unless your jobs use Webrick APIs (which is honestly a code smell as it couples). – Thorncombe

I'm referring to redirects outside of the Ruby stack. Like mod_rewrite style redirects. Technically, you can redirect inside of Rack, or Rails, or, maybe even Webrick (I could be wrong), but that requires starting ruby, which is comparatively slow vs Apache or Nginx – Thorncombe

@JimDeville Your logic is flawed. 1.) Multiple workers doesn't always mean better. Asynchronous workers do though (AKA using Unicorn w/ Apache Event,) you should have elaborated that. 2.) You can redirect in Webrick via Rack, Sinatra or others, people do. You can rewrite via Rack, Sinatra or Rails or others, people do. On your last comment, it doesn't even make sense, you need to start Ruby regardless of using Apache or Nginx, how else can you serve a Ruby site? Gonna use Python to parse Ruby? Unless you use jRuby. I don't use Webrick in production, just sayin'. – Ornamented

@JordonBedwell 1) i never said multiple workers was better, only that it was often needed. 2) I edited it to be more clear. Hope that makes it clearer for you – Thorncombe

@JimDeville you can spin up multiple workers with Webrick, you just can't spin them up with a swift shot like you can with thin or unicorn, and it's not async as I mentioned before (but neither is Thin -- last I remember) /Most/ Ruby programmers design their applications for multi-spawning where the spawning is agnostic to the method of spawning. AKA storing sessions in Redis, Memcached, DB or other places. I also think it's flawed to have your balancer handling your application logic, as if it will reduce the overhead much since you stop processing to redirect. Read: Async. – Ornamented

@JimDeville - Unicorn is also written in Ruby – Mandola

github.com/defunkt/unicorn/tree/master/ext/unicorn_http a large portion of Unicorn is in C – Thorncombe

@JimDeville but in unicorn repo, what i saw is Ruby 76.9% Shell 10.5% Ragel 7.4% C 3.0% Is there something i am missing? – Picturize

Answer 2

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.

Stoner

Answer 3

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.

Bonus

Also Webrick lost connection and auto-turn off when by my experience, i'm developing software and when i choosed WeBRICK in Heroku PaaS, the auto-turn off are compensated by high speed of auto-turn on (fired through automatically architecture of Heroku) – Heartburning

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.

Jermaine

Have you seen a stat comparison? I also hear people saying that (and is probably true) but can't really find a real stat comparison anywhere on the web... – Prescriptive

I don't think anyone really benchmarks Webrick because it isn't intended to be a production server. Unicorn, Thin or Passenger are well supported and much better options – Thorncombe

Answer 5

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.

Dorweiler

It is not single threaded. Or it is in the same way as any modern script language is implemted (with a GIL). But database access and IO in webrick is fully multithreaded. – Appropriation