Как увеличить число одновременных соединений при использовании unicorn?

Question

[Антон Иванов]

Всем привет.

На сервере 4 гигабайта памяти.
worker_processes в настройках unicorn установлено в 10, с большими значениями иногда бывают падения, связанные с нехваткой памяти.
Допустим, что к приложению идут запросы, их может быть 50-200 в секунду. Время обработки одного запроса - порядка 500 миллисекунд.
Какие есть в таком случае варианты (кроме оптимизации приложения? :) )
а) использовать другой сервер, который не грузит на каждый воркер отдельный экземпляр приложения
б) использовать больше серверов
в) наверняка есть что-то еще, так как я работаю с руби относительно недавно.

Заранее спасибо.

Answer 1

[teet]

Можно поставить между клиентом и приложением nginx! Потом можно горизонтальное масштабирование.

Comments

[Антон Иванов]

Ну, nginx - это само собой, как и кеширование. В данном случае, запросы на запись, так что приложение работает в любом случае. Просто тот же php дает больше одновременных соединений. Знаю, что некорректно сравнивать, но все же :)

[teet]

Надо добавить асинхронности в приложение, очереди сообщений, логирование сделать отдельно.

[Антон Иванов]

Все это сделано :) иногда требуется синхронный ответ на запрос создания заказа. Значит остается горизонтальное масштабирование

Answer 2

[Viktor Vsk]

worker_processes должны устанавливаться в зависимости от количества ядер процессора (2 к 1, обычно), а не к памяти. В теории, даже если у вас 100 воркеров, в идеале, каждый из них должен загружать одно ядро на 100%

Вариантов увеличения RPS достаточно много, но кроме общих, которые, как вы указали, уже используете (кеширование, оптимизация), все остальные - полностью зависят от проекта и кода.

Вот неплохая статья о возможных вариантах:
merbist.com/2011/02/22/concurrency-in-ruby-explained

В принципе, вы можете попробовать и простые шаги, как вы написали: взять другой веб-сервер. Например, начать с puma. Она должна потреблять намного меньше памяти и работать в потоках. Хотя, большого увеличения RPS вы врядли заметите. После можно попробовать использовать, скажем, Rubinius (интерпретатор руби с реально многопоточностью) для Puma. А вдруг.

Thin здесь врядли поможет, но почему б не попробовать - дело нескольких минут.

P.S.
Надо заметить, что для серьезного приложения и 200 RPS 4GB - это, обычно, staging для разработки.

Answer 3

[kkrieger]

Если вам не нужно в реальном времени отвечать на запросы принимайте запрос и ложите в очередь, потом обрабатывайте.