Pull to refresh

Comments 7

А вы с запасом аж 4 реалплексора взяли? потому что 400+ подключений по идее и один должен легко выдерживать.
ответил вам постом ниже (не туда кликнул)
Да, по паре причин.
Во-первых, Dklab Realplexor однопоточный и грузит одно ядро, следовательно CPU может стать узким местом. Таким образом тут мы расширили узкое место до 4 ядер.
Во-вторых. Собственно, потестировали схему равномерного случайного распределния раздатчиков. Вообще эти раздатчики можно разместить в разных дата-центрах, чтобы распределить нагрузку на каналы хостеров, и чтобы на пожарный случай иметь второй запасной сервер. Думаю, в марте мы так и поступим (разделим на два датацентра Клодо: Оверсан-Меркурий и KIAEHOUSE).
Спасибо, да я так и предполагал, но решил уточнить архитектуру. Верное решение.
Кстати, но можно было рассмотреть и создание собственного сервиса — на Node.JS подобный сервис (и нагрузки) будет достаточно одного ядра и с запасом (на моем тесте синтетическом, упирались в потолок CPU при 16К+ паралельных сокетов, если же что-то типа jsonp-лонгполлинг, что как раз делает реалплексор, то думаю потолок еще выше, при этом все клиенты постоянно получают данные). Впрочем, ваш выбор вполне адекватный и хороший.
Пробовал Realplexor использовать в своем проект — не понравилось. Очень сильно грузил процессор. Нашел на их форуме многочисленные сообщения о подобной проблеме, но все они были без ответа. Ну и подключение доп.библиотек не слишком радует. В итоге перешел на nginx_http_push_module ( goo.gl/g9Pgp — ссылка на статью на highload.com.ua )
Попробуйте c++-версию, в ней все проблемы решены. Она лежит в том зе репозитории. Формат конфигов и вообще работа с ней — идентична перловой.
Спасибо, буду иметь ввиду. Может быть, в будущем пригодится. Сейчас переходить уже смысла не вижу.
Sign up to leave a comment.

Articles