Путаница в выборе Faye или Rails 4 Actioncontroller:: Live

Я уже использовал Faye с Ruby On Rails, для меня это почти стоило 0, потому что я запускаю Faye на другом сервере, подключенном к моему Rails-приложению.

Однако я столкнулся с некоторыми проблемами, например, когда запрос слишком долго на сервере Rails, через некоторое время Faye Connection завершится с ошибкой и вызовет исключение.

Теперь, что я просматриваю в Actioncontroller:: Live, большинство реализаций использует Redis, который будет немного дорогостоящим для моего запуска, однако я понял, что не могу подписаться/опубликовать стиль с помощью Actioncontroller:: Живой.

Мой вопрос: должен ли я перейти к Actioncontroller:: Live или придерживаться Faye? Хотя это то, что я хочу выполнить:

Я знаю, что Faye использует Bayeux vs ActionController:: live использует SSE/HTTP. Должен ли я рассматривать все, что связано с Socket.IO? SockJS?

Ответы

Ответ 1

Вот некоторые замечания о том, почему я буду придерживаться Faye, что может приблизиться к ответу на этот вопрос:

Совместимость с браузером

Как вы читаете в соответствующем вопросе о стеке, Faye имеет лучшую совместимость с браузером.

Устойчивость

Rails:: Живая функциональность пока не очень стабильна. Там в настоящее время активная разработка на Rails SSE. Например, маловероятно, что вы не будете подвержены влиянию этой проблемы.

Threading and blocking vs асинхронная неблокирующая

Используете ли вы многопоточность в своем приложении? Если вы этого не сделаете, я определенно не буду вводить его только для Rails:: Live, поскольку он открывает возможность проблем, связанных с не-поточным gem и ограничениями выбора сервера.

Если у вас многопоточность, каждый клиент будет поддерживать поток открытым для вашего приложения. Если у вас закончились потоки, ваше приложение будет невосприимчивым/мертвым. Подумайте, сколько потоков вам нужно для удовлетворения пиковых времен, когда пользователи, открывающие несколько открыток браузера, открывают или даже DOS-атаки, когда кто-то открывает огромное количество простоя SSE/веб-соединений, чтобы достичь вашего максимума и отложить ваше приложение. Если вы устанавливаете большое количество максимальных потоков для поддержки многих незанятых подключений, вы открываете возможность иметь столько неиспользуемых потоков, которые могут иметь собственные проблемы. Нет SSE/websockets и кометы/длинных опросов гораздо безопаснее блокировать приложения. Насколько я понимаю, ваша установка запускает Faye отдельно. Сервер Faye запускает Ruby EventMachine или Node.js, которые являются асинхронными неблокирующими и не используют поток для каждого открытого соединения. Он может обрабатывать огромное количество параллельных соединений без проблем.

Мое мнение таково, что обычное блокирующее веб-приложение Rails с отдельным асинхронным неблокирующим сервером для подключений, которые остаются открытыми (для передачи сообщений и создания приложения в прямом эфире), является лучшим из обеих настроек. Это то, что у вас есть с Rails + Faye.

Обновление: Actioncable было объявлено в Railsconf 2015. Он работает без блокировки, как описано выше, но это интегрированное официальное решение Rails. Имея единую структуру с массивным сообществом, встроенный неблокирующий обработчик подключений для веб-сайтов, которые вы можете запускать и настраивать отдельно, в то время как все работает "из коробки", является большим преимуществом Rails.

Из Action Cable readme: Action Cable питается от комбинации EventMachine и потоков. Структурная сантехника, необходимая для обработки соединения, обрабатывается в цикле EventMachine, но фактический канал, заданный пользователем, обрабатывается в обычной рубиновой нити. Это означает, что вы можете использовать все свои обычные модели Rails без каких-либо проблем, если вы не совершили никаких грехов безопасности нитей.

Чтобы узнать больше, вы можете прочитать ActionCable и базовую архитектуру.