Webrick 作为生产服务器与瘦或独角兽？答案

【问题标题】：Webrick as production server vs. Thin or Unicorn?Webrick 作为生产服务器与瘦或独角兽？
【发布时间】：2012-06-07 05:58:50
【问题描述】：

您似乎理所当然地认为您不能将 Webrick 用作生产服务器，但我真的找不到任何地方提到原因。共识似乎是： “Webrick 适合开发，但 Thin 或 Unicorn 是生产的选择，时期。”

我确实查看了瘦服务器的主页，它谈到了请求/秒，但我不太了解图表，因为没有注释。

谁能告诉我为什么我应该使用 Thin 或 Unicorn 与 Webrick 相比？使用 Webrick 进行开发还有什么好处吗？我一直在使用 Webrick，因为它带有 rails，我认为它之所以默认应该是有原因的。

顺便说一句，我正在使用 Heroku。

【问题讨论】：

与 Mongrel 等其他人相比，它的速度很慢。
Ken，我真的没有问这个问题来辩论什么。我真的很想知道答案，因为我在任何地方都找不到真实的统计数据，而每个人都认为 Webrick 是劣等的。我不隶属于任何这些政党，你提到的辩论是我出于真正的好奇而提出的问题。我怎样才能改写这个问题，使它看起来不那样？
这是个好问题。
不应关闭此类问题。它们很有用而且很有帮助。所有自行任命的内容警察都应该退缩。
我通过谷歌搜索“为什么不在生产中使用 WEBrick？”找到了这个。因为这是我想要回答的问题。我并不是要在生产中使用 WEBrick，但我确实觉得每个人都说“因为它显然不是 For Production®”很烦人。这真的不是那么明显——如果是这样的话，人们在最终在 StackOverflow 上提问之前不会研究这个问题，正如@Vlad 所表明的那样。接受的答案是有帮助的；至少指出一些缺失的功能。切线地，坚持关闭一个问题，因为你认为它没有实际意义，而不提供你自己的答案是没有帮助的。

标签： ruby-on-rails production-environment thin webrick unicorn

【解决方案1】：

几个重要原因

它是用 Ruby 编写的（参见 http://github.com/ruby/ruby/tree/trunk/lib/webrick）
已编辑它没有生产网站通常需要的许多功能，例如多个工作人员（特别是预分叉、生命周期管理、异步处理等）、重定向、重写等李>

当我提到重定向/重写时，我指的是使用 Webrick，您必须在不同的层（Rack、Sinatra、Rails、自定义 Webrick 代码等）处理重写。这需要您启动额外的 ruby“处理程序”来执行您的重写代码。对于流量较低的站点，这可能很好，因为您可能已经预热的进程什么都不做。但是，对于更高流量的站点，对于前端服务器（Apache、Nginx 等）可以在不启动 Ruby* 的情况下处理的事情来说，这是服务器上的额外负载，而且速度可能会快几个数量级。

* 例如，如果您在负载均衡器后面运行，您可以将所有重写流量路由到没有安装 ruby 的服务器，并让您的主服务器只管理主要流量。这种重写流量可能是由于 SEO 的站点更改或类似原因。另一种情况是一个有多个组件的站点，可能一个部分是 Rails，另一个是 PHP，两者都需要重写（即重写旧的 PHP 路径到 Rails）

【讨论】：

无论您使用哪个服务器，都不能使用delayed_job 来处理Heroku 上的多个工作人员吗？
是的，delayed_job 与 Webrick 无关，除非您的作业使用 Webrick API（这确实是一种代码味道）。
我指的是 Ruby 堆栈之外的重定向。像 mod_rewrite 风格的重定向。从技术上讲，您可以在 Rack、Rails 或 Webrick 内部进行重定向（我可能错了），但这需要启动 ruby，这与 Apache 或 Nginx 相比相对较慢
@JimDeville - Unicorn 也是用 Ruby 编写的
github.com/defunkt/unicorn/tree/master/ext/unicorn_http Unicorn 的很大一部分是在 C 中

【解决方案2】：

它过去曾出现过一些安全问题，但似乎主要原因是与用于生产的服务器相比，它的速度确实很慢。

【讨论】：

你看过统计比较吗？我也听到人们这么说（而且可能是真的），但在网络上的任何地方都找不到真正的统计数据比较......
我认为没有人真正对 Webrick 进行基准测试，因为它不打算成为生产服务器。独角兽、瘦身或乘客得到很好的支持和更好的选择

【解决方案3】：

我真的不喜欢把简单的事情复杂化和过早的优化。 WEBrick 可用于生产，前提是它是一个流量较低的网站。大多数应用程序都是。

如果您的网站做一些需要时间的事情，例如发送电子邮件或生成 PDF 文件，you should make WEBrick multi-threaded。您想一次处理多个请求。

【讨论】：

【解决方案4】：

WEBrick 也无法处理更长的 URI，如果它们超过 2083 个字符，您将看到崩溃。 Thin 没有这些问题，这使得它更加出色 - 已经在开发中。

【讨论】：

根据我的经验，Webrick 也失去连接并自动关闭，我正在开发软件，当我在 Heroku PaaS 中选择 WeBRICK 时，自动关闭由高速自动关闭补偿on（通过 Heroku 的自动架构触发）

【解决方案5】：

webrick 在生产模式下运行的最大弱点是它是单线程、单进程的 Web 服务器，这意味着它一次只能服务一个 http 请求。

【讨论】：

它不是单线程的。或者它与任何现代脚本语言的实现方式相同（使用 GIL）。但是 webrick 中的数据库访问和 IO 是完全多线程的。