Не холивара ради, но почему некоторые тут уверенно выбирают unicorn,
когда есть passenger? :)
Если речь не идет про использование нескольких версий руби на одном
сервере, то использование passenger3 в виде модуля nginx со всех
сторон удобнее. И, вообще, вся конструкция тупо проще (нет всяких
bundle exec, monit/bluepill и прочего).
Я использовал unicorn когда passenger был еще 2, а теперь счастлив с
passenger3.
Может я чего-то не знаю? :)
Почему вы используете unicorn?
--
--
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы "RubyOnRails to russian" на группах Google.
FAQ группы находится по адресу: http://ru.wikibooks.org/wiki/RubyFAQ
Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
ror...@googlegroups.com
Чтобы отменить подписку на эту группу, отправьте сообщение по адресу: ror2ru-un...@googlegroups.com
Дополнительные варианты находятся на странице группы http://groups.google.com/group/ror2ru?hl=ru
2011/4/14 zynaps <zyn...@gmail.com>:
--
WBR, Anton
Привет.
Ну например, passenger всё ещё не позволяет задать для каждого
приложения отдельно максимальное кол-во инстансов. В итоге,
малонагруженное приложение забирает себе столько же инстансов (и
памяти), сколько и сильнонагруженное.
2011/4/15 Aleksandr Furmanov <aleksandr...@gmail.com>:
--
Alex Sergeyev
On 15 апр, 11:36, Alex Sergeyev <alex.serge...@gmail.com> wrote:
> Кто-нибудь в итоге ришил проблему, когда пассажир начинает требовать
> прописывание в require всего что используется? Я недавно наткнулся и ,
> в итоге тоже забил и перешел на unicorn.
>
> 2011/4/15 Aleksandr Furmanov <aleksandr.furma...@gmail.com>:
>
>
>
>
>
>
>
>
>
> > У меня такая же точно история. Быстрее было перейти на уникорн чем
> > разбираться чего там не так с пассажиром.
> > On Apr 14, 2011, at 6:51 AM, Akzhan Abdulin wrote:
>
> > Я использовал Passenger, когда он был версии 2, и был несчастен :)
> > Потом перешел на unicorn и стал счастливее :)
> > Из запомнившегося - частые ошибки вида
> > E_PIPE. http://groups.google.com/group/phusion-passenger/browse_thread/thread...
2011/4/14 Anton Ageev <ant...@gmail.com>:
Да, вопрос только в том, почему до перехода на бандлер это все
работало, а так же работало на всем что я еще пробовал (thin, unicorn,
webrick)
Я не спорю, возможно нужно писать руками require для всего, но вроде
как config.gem и затем bundler и используется для того, чтобы этого не
делать.
Мне кажется, наоборот, что в пассажире слишком много всякой магии,
которая иногда перестает работать.
Выдержка из документации по passenger_max_pool_size:
...
This option may only occur once, in the http configuration bock.
...
Это так снаружи кажется что проще. На самом деле passenger запускает
еще большую пачку разнообразных процессов нежели нужно для связки
nginx+unicorn.
Там присутствует и свой http proxy, который делает forward запросов
от apache/nginx к воркерам (которые слушают на 127.0.0.1), и свой
watchdog, который выполняет функции daemontools/runit, свой
application spawner - аналог unicorn master process и еще framework
spawner в случае smart spawn method, плюс ко всему некие helper
agent и logging agent.
Большая часть этих процессов динамически стартует и останавливается
в зависимости от нагрузки и таймаутов, что создает проблему номер
один - при наплыве трафика после периода простоя нужно запускать
новых воркеров, что для rails есть достаточно тяжелая операция. Ее
решают путем использования хитрых методов создания воркеров (smart и
smart-lv2 spawn methods), который используют вышеупомянутые
application/framework spawner'ы для fork'а воркеров что позволяет
сократить время старта воркера и, в случае использования REE,
потребление памяти за счет CoW. В unicorn все воркеры запускаются
при старте, при этом присутствует опция preload_app которая
аналогична smart spawn и позволяет экономить память в случае REE.
Хитрые способы создания воркеров создают проблему номер два - file
descriptor sharing между процессами и в случае использования
smart-lv2 spawn method - проблемы с code load order. В unicorn из
этих проблем присутствует только sharing FD в случае если включен
preload_app.
Проблема номер три - в отличии от unicorn и несмотря на наличие в
passenger отдельного watchdog процесса, зависший в вечном цикле
воркер никак не отслеживается и будет висеть до скончания века. Так
же нет классической апачевской опции ограничить количество requests
per worker для борьбы с memory leaks (но этого нет и в unicorn).
Проблема номер четыре - для разбрасывания запросов между воркерами
passenger использует очереди - либо индивидуальные, per worker, либо
одну глобальную, в зависимости от настроек. В случае индивидуальных
очередей возникает проблема что если какой-то воркер задумался,
обрабатывая долгий запрос, то все запросы уже попавшие в его очередь
будут висеть, даже если остальные воркеры свободны. Эту проблему
решает использование глобальной очереди, но она имеет свойство
залипать на FreeBSD. В unicorn передача запросов делается через
обычный сокет и проблемы приоритезации лежат целиком на ядре.
Общее впечатление - у passenger'а ниже порог вхождения и запустить
rails приложение под ним первый раз намного проще. При этом есть
смысл использовать его в ситуации когда один сервер обслуживает
несколько слабонагруженных приложений с спорадическими всплесками
трафика, с целью экономии ресурсов.
Для более же серьезных приложений, когда нагрузка более менее
постоянная и нужно не выжимать максимум из минимума, а наоборот, при
экстремальной нагрузке обеспечить graceful degradation сервиса, то
здесь nginx+unicorn мне видится более простой, более прозрачной и
более управляемой конструкцией.
>
> Я использовал unicorn когда passenger был еще 2, а теперь счастлив с
> passenger3.
>
> Может я чего-то не знаю? :)
>
> Почему вы используете unicorn?
--
Alex L. Demidov (ALD9-RIPE).
http://alexeydemidov.com/
Freelance Consulting.
В юникорне есть. Я не помню, есть ли это в passenger
[1] http://blog.phusion.nl/2010/06/18/the-road-to-passenger-3-technology-preview-2-stability-robustness-availability-self-healing/comment-page-1/#comment-22181
[2] http://groups.google.com/group/phusion-passenger/browse_thread/thread/23ef0cf314115609
[3] http://groups.google.com/group/phusion-passenger/browse_thread/thread/b99589023f886464/9f2d5ff319782b1e
[4] http://groups.google.com/group/phusion-passenger/browse_thread/thread/efc278478ba4d299/364897fecb6d192a
On Sun, Apr 17, 2011 at 11:28:11PM +0200, a.ognevsky wrote:
> Во втором точно не было, я было думал, что все с него на единорога
> именно поэтому и убегают. Как показал этот тред, я ошибался.
>
> --
> Andrey Ognevsky
>
> On Sunday, April 17, 2011 at 11:24 PM, Max Lapshin wrote:
> > 2011/4/18 Alexander Simonov <asim...@gmail.com>:
> > > так и в уникорне это есть.
> > > при деплое делаем релоад и запускается новый мастер, как при бинари апдейте nginx.
> >
> >
> > В юникорне есть. Я не помню, есть ли это в passenger
> >
--
Виноват, пропустил что такая опция есть для Passenger Apache. В
документации на nginx Passenger такой опции или чего-то подобного я
не нашел.
> 2011/4/17 Alex L. Demidov <alexey...@gmail.com>
>
> > Так же нет классической апачевской опции ограничить количество
> > requests per worker для борьбы с memory leaks
> >
--
Ну да. Предположим, тебе нужно 4 инстанса на первое приложение, и 1
инстанс на второе. Делаешь max_pool_size = 5, а в блоках server
устанавшиваешь min_instances в 4 и 1, соответственно.
> ...
>
>> 2011/4/14 Anton Ageev <ant...@gmail.com>:
>>> Ну например, passenger всё ещё не позволяет задать для каждого
>>> приложения отдельно максимальное кол-во инстансов. В итоге,
>>> малонагруженное приложение забирает себе столько же инстансов (и
>>> памяти), сколько и сильнонагруженное.
>>>
>>> 2011/4/14 zynaps <zyn...@gmail.com>:
>>>> Привет.
>>>>
>>>> Не холивара ради, но почему некоторые тут уверенно выбирают unicorn,
>>>> когда есть passenger? :)
>>>>
>>>> Если речь не идет про использование нескольких версий руби на одном
>>>> сервере, то использование passenger3 в виде модуля nginx со всех
>>>> сторон удобнее. И, вообще, вся конструкция тупо проще (нет всяких
>>>> bundle exec, monit/bluepill и прочего).
>>>>
>>>> Я использовал unicorn когда passenger был еще 2, а теперь счастлив с
>>>> passenger3.
>>>>
>>>> Может я чего-то не знаю? :)
>>>>
>>>> Почему вы используете unicorn?
>
> --
> WBR, Anton
>
On Apr 18, 11:11 am, "Alex L. Demidov" <alexeydemi...@gmail.com>
wrote:
> В Passenger 3 заявлена возможность пережить apachectl restart с zero
> downtime, но по словам Phusion CTO [1] это только для ситуации когда
> нужно поменять конфиг apache. Для деплоя приложения они планируют
> т.н. Rolling applications restart который будет доступен в платной
> Premium версии Phusion Passenger [2], [3], [4].
>
> [1]http://blog.phusion.nl/2010/06/18/the-road-to-passenger-3-technology-...
> [2]http://groups.google.com/group/phusion-passenger/browse_thread/thread...
> [3]http://groups.google.com/group/phusion-passenger/browse_thread/thread...
> [4]http://groups.google.com/group/phusion-passenger/browse_thread/thread...
>
> On Sun, Apr 17, 2011 at 11:28:11PM +0200, a.ognevsky wrote:
> > Во втором точно не было, я было думал, что все с него на единорога
> > именно поэтому и убегают. Как показал этот тред, я ошибался.
>
> > --
> > Andrey Ognevsky
>
> > On Sunday, April 17, 2011 at 11:24 PM, Max Lapshin wrote:
> > > 2011/4/18 Alexander Simonov <asimo...@gmail.com>:
Здесь есть один нюанс. Несмотря на ненулевые значения в
min_instances passenger все равно не запускает эти instance сразу
при старте, а ждет обращений к этим приложениям. Поэтому
рекомендуется совместно с min_instance использовать директиву
passenger_pre_start или в противном случае первый запрос к
приложению будет долго висеть ожидая spawn приложения passenger'ом.
Не работает если суммарная нагрузка больше чем может обработать одна
нода.
> --
> --
> Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы "RubyOnRails to russian" на группах Google.
> FAQ группы находится по адресу: http://ru.wikibooks.org/wiki/RubyFAQ
>
> Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
> ror...@googlegroups.com
> Чтобы отменить подписку на эту группу, отправьте сообщение по адресу: ror2ru-un...@googlegroups.com
> Дополнительные варианты находятся на странице группы http://groups.google.com/group/ror2ru?hl=ru
--
В связи с этим не очень понятно почему тут выше решили порог входа при
использовании passenger ниже чем unicorn.
On 19 апр, 20:37, "a.ognevsky" <a.ognev...@gmail.com> wrote:
> Я озвучу про порог входа. Мне очевидно, что для установки пассажира (и nginx'a) нужно написать:
> gem install passenger
> install_passenger_nginx_module, он автоматом поставит nginx, настроит его для работы и, кажется, даже запустит. Мне останется прописать туда свое приложение -- и вперед. И уже потоооом, когдааа-нибудь, мне наверняка нужно будет исправить настройки, но при этом приложение будет работать.