Ruby-on-rails Webrick 作为生产服务器与 Thin 还是 Unicorn？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/10859671/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Webrick as production server vs. Thin or Unicorn?
提问by Vlad
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."
似乎理所当然地认为您不能将 Webrick 用作生产服务器，但我真的找不到任何提及原因的地方。共识似乎是：“Webrick 适合开发，但 Thin 或 Unicorn 是生产的选择，时期。”
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.
谁能告诉我为什么与 Webrick 相比我应该使用 Thin 或 Unicorn？使用 Webrick 进行开发有什么好处吗？我一直在使用 Webrick，因为它带有 Rails，我认为它的默认设置应该是有原因的。
I'm using Heroku by the way.
顺便说一下，我正在使用 Heroku。
采纳答案by Jim Deville
A couple important reasons
几个重要的原因
- it's written in Ruby (see http://github.com/ruby/ruby/tree/trunk/lib/webrick)
- Editedit 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
- 它是用 Ruby 编写的（参见http://github.com/ruby/ruby/tree/trunk/lib/webrick）
- 编辑它没有生产网站通常需要的许多功能，例如多个工作人员（特别是预分叉，生命周期管理，异步处理等），重定向，重写等
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.
当我提到重定向/重写时，我指的是使用 Webrick，您必须在不同层（Rack、Sinatra、Rails、自定义 Webrick 代码等）处理重写。这需要您启动额外的 ruby“处理程序”来执行您的重写代码。对于低流量站点，这可能没问题，因为您可能已经预热了进程，什么都不做。但是，对于流量较高的站点，对于前端服务器（Apache、Nginx 等）无需启动 Ruby* 就可以处理的某些内容，这是服务器上的额外负载，而且速度可能快几个数量级。
* 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)
*例如，如果您在负载均衡器后面运行，您可以将所有重写流量路由到未安装 ruby 的服务器，并让您的主服务器仅管理主要流量。这种重写流量可能是由于 SEO 的站点更改或类似的原因。另一种情况是一个站点有多个组件，可能一个部分是 Rails，另一个是 PHP，并且两者都需要重写（即重写旧的 PHP 路径到 Rails）
回答by Michael Schmitz
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.
WEBrick 也无法处理更长的 URI，如果它们超过 2083 个字符，您将看到崩溃。Thin 没有这些问题，这使得它更胜一筹——已经在开发中。
回答by Nowaker
I don't really like complicating simple things and premature optimization. WEBrick can be used in productionprovided it's rather a low-traffic website. Most of the applications are.
我真的不喜欢把简单的事情复杂化和过早的优化。WEBrick 可以在生产中使用，前提是它是一个低流量的网站。大多数应用都是。
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.
如果您的站点做一些需要时间的事情，例如发送电子邮件或生成 PDF 文件，您应该使 WEBrick 多线程。您希望一次处理多个请求。
回答by Brett Henning
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.
它过去曾出现过一些安全问题，但似乎主要原因是与用于生产的服务器相比，它真的很慢。
回答by Artur Beljajev
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.
在生产模式下运行时，webrick 的最大弱点是它是单线程、单进程的 Web 服务器，这意味着它一次只能处理一个 http 请求。
