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

似乎理所当然地认为不能使用 Webrick 作为生产服务器，但我实在找不到任何地方提到原因。人们的共识似乎是: "Webrick is ok for development, but Thin or Unicorn is the choice for production, period."

我确实查看了瘦服务器的主页，它谈到了请求/秒，但是由于没有注释，我并不真正理解这个图表。

有人能告诉我为什么我应该使用 Thin 或 Unicorn 而不是 Webrick 吗？另外，使用 Webrick 进行开发有什么好处吗？我一直在使用 Webrick，因为它提供了 Rails，我认为它的默认设置应该是有原因的。

I'm using Heroku by the way.

25218 次浏览
小开
最佳答案

有几个重要的原因

  1. 它是用 Ruby 编写的(参见 http://github.com/ruby/ruby/tree/trunk/lib/webrick)
  2. 已编辑 它没有很多生产网站通常需要的功能，比如多个 worker (特别是，pre-forking、生命周期管理、异步处理等)、重定向、重写等

当我提到重定向/重写时，我指的是这样一个事实: 使用 Webrick，您必须在不同的层(Rack、 Sinatra、 Rails、自定义 Webrick 代码等)处理重写。这需要您生成额外的 Ruby“处理程序”来执行重写代码。对于一个低流量站点，这可能是好的，因为您可能已经有预热过程什么都不做。然而，对于一个流量更高的站点来说，这是服务器上的额外负载，因为前端服务器(Apache、 Nginx 等)可以处理这些负载，而不需要运行 Ruby * ，而且可能数量级更快。

* 例如，如果您运行在负载平衡器之后，您可以将所有重写流量路由到没有安装 Ruby 的服务器，并让您的主服务器只管理主流量。这种重写流量可能是由于网站的搜索引擎优化改变，或类似的东西。另一种情况是有多个组件的站点，可能一个部分是 Rails，另一个部分是 PHP，两者都需要重写(即重写到 Rails 的旧 PHP 路径)

小开

它在过去有过一些安全问题，但似乎最大的原因是，它真的很慢相比，服务器是为生产打算。

小开

我真的不喜欢把简单的事情复杂化和过早的优化。WEBrick 可以在 制作中使用，只要它是一个相当低流量的网站。大多数申请都是。

如果你的网站做一些需要时间的事情，例如发送电子邮件或生成 PDF 文件，你应该让 WEBrick 多线程。您希望一次处理多个请求。

小开

WEBrick 也不能处理较长的 URI，如果它们超过2083个字符，你会看到崩溃。Thin 没有这些问题，这使得它更优越——它已经在开发中了。

小开

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


提交答案