Реальное время с Rails

Question

Я ищу хороший способ для использования в режиме реального времени для моих пользователей в приложении Rails (пассажирский сервер Phusion). Каждый канал может быть различным в зависимости от пользователя, и я ожидаю, что каждый новый элемент будет выполняться каждые 20-60 секунд. Периодический запрос ajax не похож на лучший способ сделать это для меня.

Я слышал о комете, и я думал о том, что-то вроде этого: - Используя длинный опрос XMLHttpRequest ждать пинг с сервера - После того, как сервер отправляет запрос на пинг последние детали с AJAX - Запуск другого XMLHttpRequest

С этим что-то не так? Есть ли более простые и лучшие способы сделать это?

Спасибо, С.

Answer 1

С точки зрения веб-приложений (и расширения Rails приложений), в режиме реального времени это всего лишь иллюзия. Длительный опрос - очень близкое приближение. К сожалению, он не очень подходит для Rails. Тем более что Пассажир.

Для долгого опроса требуется постоянное открытое соединение для каждого пользователя, которое не масштабируется на серверах, которые не были предназначены для его обработки (например, Apache). К сожалению, на самом деле существует множество серверов, предназначенных для долгой масштабируемости, которые хорошо сочетаются с Rails. Вы можете попробовать сервер Shooting-Star, но я действительно не знаю, как его производительность сравнивается с Passenger для ваших стандартных запросов.

Мое личное мнение о длительном опросе - это решение, нуждающееся в решении проблемы.

Действительно вы должны задать себе следующие вопросы:

• эти обновления достаточно высокий приоритет, что они не могут ждать 40 секунд?
• Что произойдет, если обновления не будут получены немедленно?
• Могут ли мои пользователи так сосредоточиться на моем приложении, что ожидание 15 секунд повлияет на их опыт отрицательно?
• Какой процент внимания пользователя привлекает мое приложение при нормальном использовании?
• Сколько времени требуется, чтобы отвечать на обновления?
• Действительно ли действительно должно быть в режиме реального времени?

Некоторые из этих вопросов задают другие вопросы по-другому, но это необходимо с такими субъективными вопросами.

Я думаю, вы видите, что я получаю: Обновления в реальном времени очень приятные, но никогда не нужны. Если вы работаете над чем-то, что последствие неспособности реагировать на обновление в реальном времени - это конец света. Вы действительно не должны разрабатывать его как веб-приложение.

Если вы все еще имеете свои мысли о обновлениях в реальном времени, вы можете посмотреть на Juggernaut. Но это решение на основе Flash.

Answer 2

Friendfeed построил Tornado server в Python, который у них открыт.

Мы рассмотрели несколько вариантов XMPP, которые довольно сложно настроить, прежде чем переходить к nginx_http_push_module. Долговечные HTTP-запросы GET соединяются с этим, и приложение rails отталкивает запросы обратно на nginx. Nginx также проксирует динамические запросы в кластер mogrels. У нас есть запуск jQuery, который открывает соединение, а затем повторно открывает его на сервере, когда он получает сообщение, или когда есть ошибка. Таким образом, мы можем достичь почти реального времени обновлений в стиле Comet.

Этот blog post on the nginx module with a ruby example должен помочь вам приступить к работе (необходимо скомпилировать nginx). Сейчас мы разрабатываем это в разработке и планируем использовать его в производстве, если оно не окажется ненадежным, настолько хорошим.