与Heroku上的独角兽瘦身 [英] Thin vs Unicorn on Heroku

查看:162
本文介绍了与Heroku上的独角兽瘦身的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

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



为什么Heroku选择Thin作为它们的默认服务器(用于雪松)?他们是聪明的人,所以我相信他们有一个理由。

贝娄建议用4名麒麟工人代替Thin,这对我来说非常合适。
Heroku上的4名Unicron工作人员

解决方案

Thin很容易配置 - 不是最优化的,但它只适用于Heroku环境。

独角兽可以更高效,但需要配置:有多少工人?预加载应用程序?你选择了什么?



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



预加载错误 - 这会让您的应用程序启动速度变慢,但是当Unicorn重新启动工作人员时,这对于网络连接(memcache,postgres,mongo等)是'更安全的'。 b

 preload true  - 这样更好,但是您需要在前后的fork代码中正确处理服务器重新连接。



Thin has这些问题都不是现成的,但你只能得到执行过程。



总结:真正很难配置Unicorn开箱即用(或在所有),而Thin可以让人们以更少的支持请求运行。


Just wanted to get people's opinions on using Unicorn vs Thin as a rails server. Most of the articles/benchmarks I found online seem very incomplete, so it would nice to have a centralized place to discuss it.

Unicron is a multi-processes server, while thin is an event based/non-blocking server. Event-based servers are great... if your code is asynchronous/non-blocking - vanilla rails is blocking. So unless you use non-blocking rails libraries, I really don't see the advantage of using Thin. Even worse, in a non-blocking server, if your i/o loop is blocking you're going to block the entire loop and not be able to handle any more requests until the blocking call returns. Blocking libraries are going to slow thin down!

Why did Heroku choose Thin as their default server (for cedar)? They are smart guys, so I'm sure they had a reason.

Bellow is a link that suggests replacing Thin with 4 Unicorn workers - this makes perfect sense to me. 4 Unicron workers on Heroku

解决方案

Thin is easy to configure - not optimal, but it just works in the Heroku environment.

Unicorn can be more efficient, but it needs to be configured: How many workers? Preload App? What do you pick?

I have released Unicorn Heroku apps with workers set to 3, 5 and 8 - just based on how big each app is - how much code, how much memory is used and how much traffic you get all go into picking this number, and you need to monitor over time to make sure you got the number right, and your app isn't running out of memory.

Preload false - this will make your app start slower, but when Unicorn restarts a worker, this is 'safer' with network connections (memcache, postgres, mongo etc)

Preload true - this is better, but you need to handle server re-connections correctly in the pre and post fork code.

Thin has none of these issues out of the box, but you only get process of execution.

Summary: It's really hard to configure Unicorn out of the box to work well (or at all) for everyone, whereas Thin can just work to get people running with fewer support requests.

这篇关于与Heroku上的独角兽瘦身的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆