как реализовать низкочастотный браузер с низкой скоростью отправки сообщений

мы хотим ввести технологию push, и наш вариант использования выглядит следующим образом:

  • огромное количество одновременных клиентов (несколько 100.000)
  • низкая частота сообщений (~ 1 каждую минуту)
  • небольшие данные (‹500 байт/сообщение)
  • задержка менее 2 секунд

теперь у нас есть два конкурирующих решения:

  1. мы могли бы создать настоящий сервер-кластер websocket/longpolling (мы будем оценивать атмосферу, playframework и socket.io на узле или vert.x); это привело бы к тому, что несколько 100 000 сокетов были бы активны одновременно, почти все из них бездействовали бы (за исключением 25% IE, постоянно восстанавливающих длинное соединение с опросом);

  2. мы могли бы просто использовать статические файлы json за кэширующими веб-серверами (недействительными) в качестве конечной точки для классического опроса; это привело бы к нескольким 100 000 запросов в секунду от браузеров, почти на все из которых был бы получен ответ с кодом результата 304.

какое решение вы бы предложили? особенно по потреблению ресурсов: процессор, память, трафик, io?


websocket long-polling ajax-polling
person fujan    schedule 03.06.2013    source источник
comment
Не могу сказать, какой из них лучше с точки зрения ресурсов, но я бы выбрал первый. Я понял, что первое решение, использующее Vert.x (1.3.1), и наш результат стресс-теста был очень хорошим (после того, как я убедил свою компанию удалить apache как прокси-сервер для vert.x). Извините, это было сделано более 8 месяцев назад и не было запущено в производство, поэтому я не могу предоставить цифры — просто дайте шанс vert.x. ХТН   -  person Carlo Bertuccini    schedule 03.06.2013

Ответы (1)


arrow_upward
0
arrow_downward

мы использовали очень простой подход для этого:

браузеры периодически выполняют ajax-опросы к статическому файлу, который распространяется через akamai. поэтому у нас очень мало запросов, которые действительно поражают наш сервер. время кэширования файла установлено на 5 секунд, как и интервал опроса.

это не элегантно, это не в реальном времени, но это работает для нашего варианта использования.

person bennob    schedule 05.06.2013