Eug*_*eMi 34 ruby-on-rails heroku thin unicorn
只是想让人们对使用Unicorn vs Thin作为rails服务器的意见.我在网上发现的大多数文章/基准看起来都很不完整,所以有一个集中的地方讨论它会很好.
Unicron是一个多进程服务器,而thin是基于事件/非阻塞的服务器.基于事件的服务器非常棒......如果您的代码是异步/非阻塞的,那么vanilla rails就会阻塞.因此,除非您使用非阻塞的rails库,否则我真的看不到使用Thin的优势.更糟糕的是,在非阻塞服务器中,如果您的I/O循环阻塞,您将阻止整个循环,并且在阻塞调用返回之前无法处理任何更多请求.阻止库会减慢速度!
为什么Heroku选择Thin作为他们的默认服务器(雪松)？他们是聪明人,所以我相信他们有理由.
贝娄是一个链接,建议用4名Unicorn工人取代Thin - 这对我来说非常有意义. Heroku上的4名Unicron工作人员
Tom*_*kes 24
Thin很容易配置 - 不是最佳的,但它只适用于Heroku环境.
Unicorn可以更高效,但需要配置:有多少工人？预加载应用程序？你选择什么？
我已经发布了Unicorn Heroku应用程序,工作人员设置为3,5和8 - 只是根据每个应用程序的大小 - 代码多少,使用了多少内存以及你获得的流量都选择了这个数字,你需要随着时间的推移监控,以确保你的号码正确,你的应用程序没有内存不足.
预加载错误 - 这将使您的应用程序启动速度变慢,但是当Unicorn重新启动工作程序时,这对于网络连接(memcache,postgres,mongo等)来说"更安全"
Preload true - 这是更好的,但您需要在前后代码中正确处理服务器重新连接.
Thin没有开箱即用的这些问题,但您只能获得执行过程.
简介:配置开箱即用的Unicorn非常难以为所有人提供良好的工作(或者根本不用),而Thin可以帮助人们以更少的支持请求运行.
Jav*_*diz 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缓冲请求和响应,从而保护您的应用程序免受慢速客户端(例如移动网络上的移动设备)和提高性能.
带外垃圾收集 - Ruby的垃圾收集器很慢,但为什么在响应时间长的情况下打扰访问者？通过在正常的请求 - 响应周期之外运行垃圾收集来解决此问题!这个概念首先由Unicorn引入,经过改进:Phusion Passenger确保同时只有一个请求运行带外垃圾收集,从而消除了Unicorn带外垃圾收集的所有问题.
JRuby支持 - Unicorn是比Thin更好的选择,但它不支持JRuby.Phusion Passenger的确如此.
希望这可以帮助.
Heroku不使用智能路由 - 无论动态是否繁忙,它都会随机将作业分配给动态.因此,如果您的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堆栈提供的额外并发功能,除非他们转移到并发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
哎呀.
| 归档时间： |
|
| 查看次数： |
13163 次 |
| 最近记录： |