Использование Puma и Sidekiq в бэкэнд-приложении Rails

Да, вы, вероятно, хотите использовать Puma и Sidekiq. Здесь на самом деле есть две проблемы.

Параллелизм (как, кажется, вы уже знаете) — это количество веб-запросов, которые могут быть обработаны одновременно. Использование сервера приложений, такого как Puma или Unicorn, определенно поможет вам добиться лучшего параллелизма, чем сервер веб-кирпича по умолчанию.

Другая проблема заключается в том, сколько времени требуется вашему серверу для обработки веб-запроса.

Причина, по которой эти две вещи связаны, заключается в том, что количество запросов в секунду, которые может обработать ваше приложение, зависит как от среднего времени обработки каждого запроса, так и от количества рабочих процессов, принимающих запросы. Скажем, ваше среднее время отклика составляет 100 мс. Тогда один веб-воркер может обрабатывать 10 запросов в секунду. Если у вас 5 воркеров, то вы можете обрабатывать 50 запросов в секунду. Если ваше среднее время отклика составляет 500 мс, то вы можете обрабатывать 2 запроса в секунду с одним работником и 10 запросов в секунду с 5 работниками.

Время от времени взаимодействие с внешними API может быть медленным, а в худших случаях оно может быть очень ненадежным из-за неотвечающих серверов на удаленном конце, сбоев или замедлений сети. Sidekiq — отличный способ оградить ваше приложение (и ваших конечных пользователей) от возможности медленного отклика удаленного API. Представьте, что удаленный API по какой-то причине работает медленно и среднее время ответа от него замедлилось до 2 секунд на запрос. В этом случае вы сможете обрабатывать только 2,5 запроса в секунду с 5 работниками. При большем трафике ваши конечные пользователи могут начать долго ждать, прежде чем любая страница в вашем приложении сможет ответить, даже те, которые не делают удаленные вызовы API, потому что все ваши веб-работники могут ожидать медленного удаленного API. ответить. Поскольку трафик продолжает расти, ваши пользователи начнут получать тайм-ауты соединения.

Идея использования Sidekiq заключается в том, что вы отделяете время, затрачиваемое на ожидание внешнего API, от ваших веб-воркеров. В основном вы берете запрос данных от своего пользователя, передаете его Sidekiq, а затем немедленно возвращаете ответ пользователю, который в основном говорит: «мы обрабатываем ваш запрос». Затем Sidekiq может взять задание и сделать внешний запрос. После того, как у него есть данные, он может сохранить эти данные обратно в ваше приложение. Затем вы можете использовать веб-сокеты, чтобы отправить пользователю уведомление о том, что данные готовы. Или даже отправить им данные напрямую и соответствующим образом обновить страницу. (Вы также можете использовать опрос, чтобы страница постоянно спрашивала «она уже готова?», но это очень быстро становится очень неэффективным.)

Я надеюсь это имеет смысл. Дайте знать, если у вас появятся вопросы.

Sidekiq, как Resque и Delayed Job, предназначен для обеспечения асинхронной обработки заданий из очереди.

Если вам не нужно, чтобы задания ставились в очередь и запускались асинхронно, нет никакой существенной пользы (или вреда) от использования Sidekiq.

Если задачи должны выполняться синхронно (похоже, что вы могли бы — неясно, ждут ли клиенты данных или просто запрашивают запуск заданий), Sidekiq и его родственники, вероятно, не подходят для этой работы. При использовании Sidekiq или других решений нет гарантированного времени обработки; задания помещаются в конец стека, каким бы длинным это ни было, и не будут обрабатываться, пока не подойдет их очередь. Если клиенты ожидают данных, они могут истечь долго, прежде чем ваш рабочий пул когда-либо обработает их задания.