Я использую Redis для моего проекта rails для подписки на каналы и публикации на тех каналах, когда происходит событие. На стороне клиента я регистрируюсь на EventSource, который соответствует этим каналам. Всякий раз, когда происходит событие для подписанного канала на сервере, сервер выполняет запись SSE, чтобы все зарегистрированные клиенты получали обновление.
Теперь соединение с сервером остается в живых для каждого клиента, который подписан на эти каналы, то есть серверный поток, выделенный этому клиенту, продолжает работать до тех пор, пока клиент не отключится. При таком подходе, если есть 1000 одновременных пользователей, подписанных на канал, у меня будет 1000 соединений TCP/IP.
Я использую Puma как веб-сервер, как это предлагается в этом учебнике. По умолчанию Puma задает 16 максимальных потоков. Я могу изменить этот предел на более высокий предел.
Возможно, я не знаю, сколько одновременных пользователей может быть одновременно в моем приложении и не знает, что такое max no. потоков, которые я могу указать в Puma. В худшем случае, если количество потоков, посвященных каждому параллельному пользователю, достигает максимального количества потоков, заданных для веб-сервера Puma, приложение замерзает для всех пользователей, пока один из параллельных пользователей не отключится.
Я был рад использовать Rails в прямом эфире, а сервер отправил события в моем проекте rails, но при таком подходе я рискую достичь предела максимальных потоков, указанных на моем веб-сервере, и, следовательно, приложение становится невосприимчивым для всех пользователей до тех пор, пока один из одновременное отсоединение пользователя.
Не уверен, что типичное максимальное количество потоков для Puma для большой параллельной базы пользователей.
Должны ли я рассматривать другие подходы - возможно, на основе ajax-опроса или Node.js, который использует управляемую событиями, неблокирующую модель ввода-вывода? Или просто запустите некоторые тесты, чтобы узнать, сколько может быть мое максимальное количество потоков?
