Heroku上的瘦身与独角兽

只是想获得人们对使用Unicorn和Thin作为Rails服务器的意见。我在网上找到的大多数文章/基准看起来都很不完整，所以最好有一个集中的地方来讨论它。Heroku上的瘦身与独角兽

Unicron是一个多进程服务器，thin是基于事件的/非阻塞服务器。基于事件的服务器非常好...如果你的代码是异步/非阻塞的 - 香草栏被阻塞。所以除非你使用非阻塞的rails库，否则我真的没有看到使用Thin的好处。更糟糕的是，在非阻塞服务器中，如果你的I/O循环阻塞了，你将阻塞整个循环，直到阻塞调用返回后才能处理更多的请求。阻止图书馆将减缓减少！

为什么Heroku选择Thin作为他们的默认服务器（雪松）？他们是聪明的人，所以我相信他们有一个理由。

贝娄是一个链接，建议用4个独角兽工人代替瘦 - 这对我来说非常合理。 4 Unicron workers on Heroku

来源

2012-12-21 EugeneMi

真的不能完全回答你的问题。有一件事我不会想到这一点，Unicorn非常适合在github上查看自述文件：https://github.com/defunkt/unicorn#readme –

薄易于配置 - 不是最佳的，但它只是在Heroku环境中工作。

独角兽可以更有效率，但它需要进行配置：有多少工人？预加载应用程序？你选什么？

我已经发布了Unicorn Heroku应用程序，其工作人员设置为3,5和8--只是基于每个应用程序的大小 - 多少代码，使用了多少内存以及您获取的所有流量都选择了这个数字，并且您需要随时监控以确保您获得了正确的号码，并且您的应用没有用完内存。

预紧假 - 这会让你的应用程序启动速度较慢，但是当独角兽重新启动工人，这与网络连接（内存缓存，Postgres的，蒙戈等）

预紧真正的“安全” - 这是更好的，但您需要在前后叉代码中正确处理服务器重新连接。

Thin没有任何开箱即用的问题，但您只能获得执行过程。

总结：开箱即用配置Unicorn非常适合所有人使用（或根本不需要），而Thin可以让工作人员以更少的支持请求运行。

来源

2012-12-25 01:00:08

预加载设置只会影响部署的加载时间 - 所以它不是一个巨大的应对。还有什么我应该留意的？ – EugeneMi

Preload false可以在应用程序部署过程中将您的应用程序推送超过Heroku排队请求的30秒。我遇到过这种情况，必须切换回Preload true - 然后您必须知道处理重新连接，例如， ActiveRecord，Memcache，MongoDB，Redis，NewRelic等等 –

你知道是否有围绕Unicorn修改全局变量的问题。我想知道不同的工作人员是否都在共享全局名称空间，或者他们是否保留了自己的全局变量。谢谢！ –

Heroku不使用智能路由 - 无论dyno是否繁忙，它都会随机分配作业给dynos。因此，如果您的dyno无法同时处理多个作业，即使您正在为许多免费的其他dynos付费，您也会得到延迟（可能是大量延迟）。 “这是正确的 - 如果你的应用程序需要与智能路由器80个DYNOS，它需要4,000随机路由器。” http://news.rapgenius.com/James-somers-herokus-ugly-secret-lyrics

Heroku上说，他们在这方面的工作，以及他们的计划是，使之更容易使用独角兽。他们基本上说：“糟糕，我们没有注意到这是几年的问题......现在我们看，这对Thin来说绝对是一个问题......所以我想你需要使用不同的程序而不是我们一直在推动这一切。“ http://news.rapgenius.com/Jesper-joergensen-routing-performance-update-lyrics

从Heroku的官方解释（上面第二个链接）： “Rails的，其实还不可靠支持的并发请求处理这让Rails开发者无法利用由雪松堆栈提供了额外的并发能力，除非他们转移到像Puma或Unicorn这样的并发Web服务器。

部署到Cedar with Thin的Rails应用程序可以相当快地结束请求排队问题。由于Cedar路由器不再代表应用进行任何排队，因此在dyno排队的请求必须等到单个Rails进程在队列中完成。许多客户都遇到了这个问题，我们未能采取行动，并为他们提供了一种更好的方法来在Cedar上部署Rails应用程序。“

另外值得关注的是，他们的性能工具（包括New Relic）尚未报告时间在测功机队列中度过的。 http://news.rapgenius.com/Lemon-money-trees-rap-genius-response-to-heroku-lyrics

哎呀。

来源

2013-11-13 22:41:03 ChrisPhoenix

感谢您阅读rapgenius的文章 - 非常令人失望地了解Heroku如此巨大的失败和歪曲。猜测带走的是：你最好把牛的Unicorn的多个进程并发到并发中，因为Heroku的动态级并发是一个假设。 – Yarin

这是运行像Torquebox这样的集群应用服务器的地方，可以真正获得一些好处。如果您的应用拥有高流量，请从Heroku下载并部署3个群集的Torquebox应用服务器。 Web和后台进程的智能负载平衡，滚动部署，集群化memcached和排队构建它。这是一个盒子里的堆叠。 – brightball

最近（仅在几个月前）的后面Phusion Passenger的乡亲Heroku的添加支持。当然，这是你应该尝试看看是否符合您的需求的替代品。

I即使使用1台动态测速仪，它的速度也很快，而响应时间的下降是显而易见的。简单的Passenger Ruby Heroku Demo托管在github上。

主要的好处，在Heroku索赔乘客是：

通过Nginx的静态资产加速 - 不要让你的Ruby应用服务静态资产，让Nginx的为你做它和卸载你的应用程序为真正重要的任务。 Nginx会做得更好。
多个工作进程 - 而不是在测功机上运行只有一个工人，乘客的Phusion上运行一个单一的赛道多工作，因此需要利用它的资源发挥到极致，给你更高的性价比。这种方法类似于Unicorn的方法。但与Unicorn不同，Phusion Passenger可根据当前流量动态调整工作进程的数量，从而在不需要时释放资源。
内存优化 - Phusion乘客使用内存比Thin和Unicorn少。它还支持写入时复制虚拟内存和代码预加载，从而使您的应用在Ruby 2.0上运行时使用更少的内存。
请求/响应缓冲 - 所包含的Nginx缓冲器的请求和响应，从而保护你对慢客户端应用程序（移动网络例如移动设备）和提高性能。
带外垃圾收集 - Ruby的垃圾收集器速度很慢，但是为什么您的访问者需要很长的响应时间呢？通过在正常的请求 - 响应循环之外运行垃圾回收来解决这个问题！ Unicorn首次推出的这个概念已经得到了改进：Phusion Passenger确保同时只有一个请求正在运行带外垃圾收集，从而消除了Unicorn的带外垃圾收集带来的所有问题。
JRuby支持 - Unicorn比Thin更好的选择，但它不支持JRuby。 Phusion Passenger的确如此。

希望这会有所帮助。

来源

2014-02-13 04:49:23

Heroku上的瘦身与独角兽

回答

相关问题