Да, вы, вероятно, хотите использовать Puma и Sidekiq. Здесь есть две проблемы.
Параллелизм (как вам кажется, вы уже знаете) - это количество веб-запросов, которые могут обрабатываться одновременно. Использование сервера приложений, такого как Puma или Unicorn, безусловно, поможет вам улучшить параллелизм, чем сервер веб-кирпича по умолчанию.
Другая проблема в игре - это время, в течение которого сервер обрабатывает веб-запрос.
Причина, по которой эти две вещи связаны, состоит в том, что количество или запросы в секунду, которые может обрабатывать ваше приложение, является функцией как среднего времени обработки для каждого запроса, так и количества рабочих процессов, принимающих запросы. Скажем, среднее время отклика составляет 100 мс. Затем один веб-рабочий может обрабатывать 10 запросов в секунду. Если у вас 5 работников, вы можете обрабатывать 50 запросов в секунду. Если ваше среднее время отклика составляет 500 мс, тогда вы можете обрабатывать 2 reqs/sec с одним рабочим и 10 reqs/sec с 5 рабочими.
Взаимодействие с внешними API-интерфейсами может быть медленным время от времени, и в худшем случае это может быть очень ненадежным с серверами, не реагирующими на удаленный сервер, или сбоями в сети или замедлением. Sidekiq - отличный способ изолировать ваше приложение (и ваших конечных пользователей) от возможности медленного ответа удаленного API. Представьте, что удаленный API работает по какой-то причине медленно и что среднее время отклика от него замедлилось до 2 секунд на запрос. В этом случае вы сможете обрабатывать только 2,5 рек/сек с 5 рабочими. Если больше трафика, чем у ваших конечных пользователей, может возникнуть долгое время ожидания до того, как любая страница вашего приложения сможет ответить, даже те, которые не делают удаленные вызовы API, потому что все ваши веб-сотрудники могут ожидать медленного удаленного API ответить. По мере увеличения трафика ваши пользователи начнут получать таймауты подключения.
Идея использования Sidekiq заключается в том, что вы отделяете время, потраченное на внешний API от ваших веб-работников. Вы в основном принимаете запрос данных от своего пользователя, передаете его в Sidekiq и сразу же возвращаете ответ пользователю, который в основном говорит «мы обрабатываем ваш запрос». Sidekiq может затем забрать работу и сделать внешний запрос. После того, как у него есть данные, он может сохранить эти данные обратно в ваше приложение. Затем вы можете использовать веб-сокеты, чтобы направить уведомление пользователю, что данные готовы. Или даже подталкивайте данные непосредственно к ним и соответствующим образом обновляйте страницу. (Вы также можете использовать опрос, чтобы страница постоянно запрашивала «еще готова?», Но это очень неэффективно очень быстро.)
Надеюсь, это имеет смысл. Дайте знать, если у вас появятся вопросы.
Большое спасибо, Джереми. Это имеет большой смысл. Мой процесс занимает от одного до двух монет, чтобы извлекать данные из внешних API. Меня беспокоит, что ресурсы моих работников заперты, ожидая данных от API. Помогает ли Sidekiq решить эту проблему? – AdamNYC
Да, Sidekiq поможет с этим. Последний длинный абзац моего ответа - это описание того, как это будет работать. –
Спасибо Джереми. Я получил эту часть. Мой вопрос: даже если мой Sidekiq создает несколько потоков и ждет ответов от внешних API, будут ли эти потоки хранить ресурсы (ЦП, ОЗУ) в течение нескольких минут в ожидании? Я предполагаю, что если мое приложение может работать асинхронно, то, ожидая ответа, мои ресурсы сервера могут использоваться для выполнения других запросов или для обработки данных, возвращаемых из более ранних запросов. – AdamNYC