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