只是想获得人们对使用 Unicorn vs Thin 作为 Rails 服务器的意见。我在网上找到的大多数文章/基准似乎都很不完整，所以最好有一个集中的地方来讨论它。
Unicron 是多进程服务器，而 Thin 是基于事件/非阻塞的服务器。基于事件的服务器很棒......如果您的代码是异步/非阻塞的 - vanilla rails 是阻塞的。因此，除非您使用非阻塞 Rails 库，否则我真的看不到使用 Thin 的优势。更糟糕的是，在非阻塞服务器中，如果您的 i/o 循环阻塞，您将阻塞整个循环，并且在阻塞调用返回之前无法处理更多请求。阻塞库会变慢！
为什么 Heroku 选择 Thin 作为他们的默认服务器（对于 cedar）？他们是聪明人，所以我相信他们是有原因的。
Bellow 是一个链接，建议用 4 个 Unicorn 工人替换 Thin - 这对我来说非常有意义。 Heroku 上的 4 名 Unicron 工作人员
Thin 易于配置 - 不是最优的，但它只适用于 Heroku 环境。
独角兽可以更高效，但需要配置：多少工人？预加载应用程序？你选什么？
我已经发布了 Unicorn Heroku 应用程序，其中 worker 设置为 3、5 和 8 - 仅基于每个应用程序的大小 - 有多少代码、使用了多少内存以及你获得了多少流量来选择这个数字，你需要随着时间的推移进行监控，以确保您的号码正确，并且您的应用程序没有内存不足。
Preload false - 这将使您的应用程序启动速度变慢，但是当 Unicorn 重新启动工作人员时，这对于网络连接（memcache、postgres、mongo 等）来说“更安全”
Preload true - 这更好，但您需要在前叉代码和后叉代码中正确处理服务器重新连接。
Thin 没有开箱即用的这些问题，但您只能获得执行过程。
总结： 开箱即用地配置 Unicorn 以使其对所有人都有效（或完全）非常困难，而 Thin 可以通过更少的支持请求让人们运行。
最近（仅几个月前）Phusion Passenger背后的人增加了对 Heroku 的支持。绝对这是您应该尝试的替代方案，看看是否符合您的需求。
即使使用 1 dyno 也非常快，响应时间的下降是显而易见的。一个简单的Passenger Ruby Heroku Demo托管在github 上。
Heroku 上的乘客声称的主要好处是：
通过 Nginx 加速静态资产- 不要让您的 Ruby 应用程序提供静态资产，让 Nginx 为您做这件事，并为真正重要的任务卸载您的应用程序。Nginx 会做得更好。
多个工作进程- Phusion Passenger 不是在一个测功机上只运行一个工作程序，而是在一个测功机上运行多个工作程序，从而充分利用其资源并为您带来更多收益。这种方法类似于独角兽的。但与 Unicorn 不同的是，Phusion Passenger 会根据当前流量动态调整工作进程的数量，从而在不需要时释放资源。
内存优化- Phusion Passenger 使用的内存少于 Thin 和 Unicorn。它还支持与代码预加载相结合的写时复制虚拟内存，从而使您的应用程序在 Ruby 2.0 上运行时使用更少的内存。
请求/响应缓冲- 包含的 Nginx 缓冲请求和响应，从而保护您的应用免受慢速客户端（例如移动网络上的移动设备）的影响并提高性能。
带外垃圾收集- Ruby 的垃圾收集器很慢，但为什么要让访问者因响应时间长而烦恼呢？通过在正常的请求-响应周期之外运行垃圾收集来解决这个问题！这个概念最初是由 Unicorn 提出的，在此基础上进行了改进：Phusion Passenger 确保同时只有一个请求在运行带外垃圾收集，从而消除了 Unicorn 带外垃圾收集的所有问题。
JRuby 支持- Unicorn 是比 Thin 更好的选择，但它不支持 JRuby。Phusion 乘客可以。
希望这可以帮助。
Heroku 不使用智能路由 - 无论 dyno 是否忙，它都会随机分配作业给 dyno。因此，如果您的测功机不能同时处理多个工作，即使您为许多其他免费的测功机付费，您也会得到延迟（可能是巨大的延迟）。“没错——如果你的应用需要 80 个 dynos 和智能路由器，它需要 4,000 个随机路由器。” http://news.rapgenius.com/James-somers-herokus-ugly-secret-lyrics
Heroku 表示他们正在为此努力，他们的计划是让 Unicorn 的使用变得更容易。他们基本上说：“哎呀，几年来我们都没有注意到这是一个问题......现在我们看起来，这对 Thin 来说绝对是一个问题......所以我想你需要使用不同的程序而不是我们一直在推动的一个。” http://news.rapgenius.com/Jesper-joergensen-routing-performance-update-lyrics
来自 Heroku 的官方解释（上面的第二个链接）：“事实上，Rails 还不可靠地支持并发请求处理。这使得 Rails 开发人员无法利用 Cedar 堆栈提供的额外并发功能，除非他们迁移到并发 Web像 Puma 或 Unicorn 这样的服务器。
使用 Thin 部署到 Cedar 的 Rails 应用程序很快就会出现请求队列问题。因为 Cedar 路由器不再代表应用程序进行任何排队，所以在 dyno 排队的请求必须等到单个 Rails 进程通过队列。许多客户都遇到了这个问题，我们未能采取行动并为他们提供更好的方法来在 Cedar 上部署 Rails 应用程序。”
同样令人感兴趣的是，他们的性能工具，包括 New Relic，并没有报告在 dyno 队列中花费的时间。 http://news.rapgenius.com/Lemon-money-trees-rap-genius-response-to-heroku-lyrics
哎呀。