История изменений
Исправление special-k, (текущая версия) :
Для начала проблема: при обработке запросов происходят блокировки на время работы сети, иначе говоря: «запросы обрабатываются медленно».
Решение:
а) использовать неблокирующую архитектуру
б) использовать несколько потоков/экземпляров приложений
Второй вариант порождает еще проблемы:
а)В mri нет настоящих потоков.
б)При большом количестве конкурирующих запросов, большее количество приложений не сильно помогает, а вот ресурсы пожирает вполне стабильно.
Т.о. для решения этой проблемы сервера стараются экономить ресурсы, форкать процессы и управлять ими.
thin использует eventmachine, что, вероятно, уменьшает количество блокировок при обработке запросов. Кроме того существует возможность занять весь поток, используя https://github.com/mperham/rack-fiber_pool/, это потребует определенных библиотек для работы с БД, http запросов и пр.
unicorn, использует fork и unix socket http://tomayko.com/writings/unicorn-is-unix https://blog.engineyard.com/2010/everything-you-need-to-know-about-unicorn считается плохо подходящим для «медленных» клиентов (очевидно он просто их не обрабатывает, разрывая соединение, убивая воркер и т.п.).
rainbow работает так же как и unicorn, но при этом умеет еще и другие «модели обеспечения конкуренции», в т.ч eventmachine.
puma использует ruby-threads вместо fork, благо в паре реализация они вполне реальные. С epool puma так же работает.
passanger, похоже, часть работы оставляет на apache/nginx, тоже умеет работать с epool.
Меня немного напрягает, что если принцип работы thin и unicorn понятен, то с остальными все не так очевидно. Но, думаю, каждый из них по-своему хорош. Хотя, лично я, в первую очередь за non-blocking, т.о. мне подходят все кроме unicorn. С другой стороны, почему бы не использовать unicorn там где все быстро и что-нибудь другое, где все медленно. Короче, серебренной пули нет.
Исходная версия special-k, :
Для начала проблема: при обработке запросов происходят блокировки на время работы сети, иначе говоря: «запросы обрабатываются медленно».
Решение:
а) использовать неблокирующую архитектуру
б) использовать несколько потоков/экземпляров приложений
Второй вариант порождает еще проблемы:
а)В mri нет настоящих потоков.
б)При большом количестве конкурирующих запросов, большее количество приложений не сильно помогает, а вот ресурсы пожирает вполне стабильно.
Т.о. для решения этой проблемы сервера стараются экономить ресурсы, форкать процессы и управлять ими.
thin использует eventmachine, что, вероятно, уменьшает количество блокировок при обработке запросов. Кроме того существует возможность занять весь поток, используя https://github.com/mperham/rack-fiber_pool/, это потребует определенных библиотек для работы с БД, http запросов и пр.
unicorn, использует fork и unix socket http://tomayko.com/writings/unicorn-is-unix https://blog.engineyard.com/2010/everything-you-need-to-know-about-unicorn считается плохо подходящим для «медленных» клиентов (очевидно он просто их не обрабатывает, разрывая соединение, убивая воркер и т.п.).
rainbow работает так же как и unicorn, но при этом умеет еще и другие «модели обеспечения конкуренции», в т.ч eventmachine.
puma использует ruby-threads вместо fork, благо в паре реализация они вполне реальные. С epool puma так же работает.
passanger, похоже, часть работы оставляет на apache/nginx, тоже умеет работать с epool.
Меня немного напрягает, что если принцип работы thin и unicorn понятен, то с остальными все не так очевидно. Но, думаю, каждый из них по-своему хорош. Хотя, лично я, в первую очередь за non-blocking, т.о. мне подходят все кроме unicorn. С другой стороны, почему бы не использовать unicorn там где все быстро и что-нибудь другое, где все медленно. Короче, серебренной пули нет.