Я пытаюсь расширить сервер приложений для обработки более 20 000 запросов в минуту.
Когда я подвергаю стресс-тестированию запросы, большинство запросов легко обрабатываются на 20 000 оборотов в минуту и более.
Но запросы, которые должны выполнять внешний HTTP-запрос (например, вход в Facebook), переводят сервер в режим сканирования (3000 об / мин).
Я концептуально понимаю ограничения моей текущей среды - 3 сервера с балансировкой нагрузки с 4 рабочими-единорогами на каждый сервер могут обрабатывать только 12 запросов за раз, даже если все они ожидают HTTP-запросов.
Какие у меня есть варианты для улучшения масштабирования? Я хотел бы обрабатывать еще много подключений одновременно.
Возможные решения, как я понимаю:
Грубая сила: используйте больше рабочих единорогов (т. Е. Больше оперативной памяти) и больше серверов.
Переместите все операции блокировки в фоновые / рабочие процессы, чтобы освободить веб-процессы. Клиенты должны будут периодически опрашивать, чтобы узнать, когда их запрос будет выполнен.
Перейдите на Puma вместо Unicorn (и, возможно, на Rubinius из MRI), чтобы я мог использовать потоки вместо процессов, что может (??) улучшить использование памяти на каждое соединение и, следовательно, позволить увеличить количество рабочих.
По сути, я ищу: есть ли лучший способ увеличить количество заблокированных / поставленных в очередь запросов, которые может обработать один рабочий, чтобы я мог увеличить количество подключений на сервер?
Например, я слышал обсуждение использования Thin с EventMachine. Открывает ли это возможность Rails worker, который может отложить веб-запрос, над которым он сейчас работает (потому что он ожидает на внешнем сервере), а затем заберет другой запрос, пока он ожидает? Если да, то стоит ли стремиться к повышению производительности по сравнению с Unicorn и Puma? (Сильно ли это зависит от активности приложения во время выполнения?)
