Pull to refresh

Comments 11

А в сторону NodeJS & Socket.IO не смотрели? Там все намного проще, как по мне. Мы используем, а в качестве хранения данных и обработки каналов Redis с его pub/sub. Скрипт на ноде получился простейший, а на клиенте так вообще 2 строки — обычная подписка на событие, которое прозрачно проксируется на сервер с помощью Socket.IO
на момент реализации задачи у нас не было человека, который хоть раз бы работал с нодой или сокет.ио, а времени было довольно мало, поэтому задачу начали делать на риалплексоре, так как по нему у нас уже были готовые решения, но после запуска игры, наткнулись на фризы, и пришлось в минимальные сроки искать альтернативу.
Вот мы тоже так думали, если честно — все завелось за 2 дня. Потом во время тестированя было потрачено еще 2 на допил. Действительно не сложно. Вот так наш фронтэндер стал одной ногой на сторону бэкэнда =)
Я так понимаю, в сторону RabbitMQ тоже не смотрели?
А кто-нибудь пробовал это реализовать на сокетах? Это же в разы быстрее должно быть, и поддерживается мобильными устройствами (без использования браузера).
Никто не хочет помочь с простейшей реализацией приложения?
А чем именно dklab realplexor подвел и почему это ожидалось? Там есть C++-версия, которая работает даже под очень высокими нагрузками. И с задержками не должно было быть проблем…
Мы ставили перл. первый эксперимент был с очень высоким хайлоадом (порядко 600к-1кк уников в сутки), это было примерно пол года назад. основная проблема, которая возникала — если на канал А не приходят сообщения (не отправляются), а на каналы Б-Я сообщения отправляются довольно часто, то при отправке сообщения на канал А его доставка происходила от 5 до 30 секунд. В принципе, такое наблюдалось и раньше, при попытке поднять риалплексор, на ВПС, но тогда я грешил на убогий сервер.
В то же время, сообщения, на самые активные каналы доставляются практически моментально, то есть эти каналы не чувствуют задержек в основном, но вот неактивные очень страдают.
В нынешней ситуации, я полагаю, проблема была схожей, так как некоторые пользователи, да и сами пару раз натыкались на аналогии, ожидали сообщений с кометы по 5-15 секунд, но на этот раз, если сопоставлять ресурсы сервера и нагрузку на него, то это в сотни раз производительнее, чем было под хайлоадом. то есть, что я хочу сказать — на текущем железе, при мизерном онлайне, ситуация возникала та же, что и на более слабом железе, при более сильном хайлоаде.
то есть, либо мы не правильно настраиваем конфиги (хотя весь форум ваше перерыли), либо есть какая то бага с малоактивными каналами.
я был бы вам признателен, если бы вы смогли обьяснить, в чем может быть проблема, так как ваша библиотека довольно удобна и легка в использовании, но на текущий момент, к сожалению, мы не можем ее использовать, так как моментальность доставки сообщений очень важна.
Надо смотреть воспроизводимость конкретно в вашем случае. Каналы независимы, не должна загруженность одних каналов влиять на доставку в других. В вашем примере когда вы отправляете данные в канал A и метод отправки возвращает управление в вызывающий код, данные уже в памяти realplexor-а. Теперь любой клиент, подключившийся к А с правильным идентификатором, сразу же получит эти данные (т.к. они просто достанутся из памяти) — тем более вот вы говорите, что при запросе активных каналов ответ приходит сразу же, а значит, перегруженности очереди запросов нет. Т.е. если для одного канала запрос клиента отстреливается моментально, то и для любого другого канала запрос тоже будет моментально отстреливаться, если есть данные. И наоборот, если есть тормоза, то одинаково будут тормозить как активные, так и неактивные каналы.

Я думаю, вы просто где-то неверный изначальный курсор передавали, или еще что-то.
Only those users with full accounts are able to leave comments. Log in, please.