Webrick作为生产服务器与Thin或Unicorn？

Question

似乎理所当然地认为你不能将Webrick用作生产服务器，但我无法真正找到任何提及原因的地方。共识似乎是： “Webrick可以用于开发，但是Thin或Unicorn是生产的选择，期限。”

我确实查找了瘦服务器的主页，它讨论了请求/秒，但由于没有注释，我不太了解该图。

与Webrick相比，谁能让我知道为什么我应该使用Thin或Unicorn？使用Webrick进行开发也有什么好处？我一直在使用Webrick，因为它带有rails，我认为它应该是默认的原因。

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

Answer 1

几个重要原因

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

过去它有一些安全问题，但似乎最重要的原因是它与用于生产的服务器相比真的很慢。

Answer 5

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