Классно, только задумался о том, как гуглить что-то подобное :)
А как у него с требованиями (память, процессор)? «В режиме реального времени и с минимальной нагрузкой для сервера» хорошо звучит, но хоть немножко цифр можно?
Извените а на какой операционке Вы тестировали «сотни тысяч долгоживущих открытых HTTP», помнится мне статья яндекса как они точили FreeBSD чтобы она могла открыть 150т. соединений, им пришлось ядро патчить. На обычном линуксе я уверен тоже не выйдет такого количества, про Вин вообще врядле стоит даже заикатся?
Мне просто интересно Вы себе представляете что такое для операционки 100т. открытых сокетов?
Это я видел. А не пытались ли Вы передавать целиком ХТМЛ страницы? Будет ли выигрыш в производительности? А добавив flash прослойку можно использовать gzip :)
Картинки тоже можно тогда гонять через постоянное соединение, используя base64.
И тогда получится что-то вроде гугловского SPDY ;)
Целиком HTML-страницу будет, во-первых, слишком затратно по трафику, а во-вторых, все формы ведь будут сбрасываться. Нет, лучше страницу обновлять по кусочкам.
Стоп, стоп. На демо-страницы входящие сообщения принимает не Realplexor, а PHP-скрипт обычным аяксом. И уже этот PHP-скрипт отправляет данные в Realplexor.
Попутал немножко с терминами.
Скажем так — хотелось бы, условно не закрывающееся соединение сервер-клиент.
Возможно ли реализовать такое хотя бы для ИЕ7+, ФФ2+?
Ну кроме Long Polling, есть еще Streamin (как раз когда соединение не нужно никогда закрывать). Но только Streaming не работает в IE. Streaming в Realplexor-е в будущем обязательно добавится (правда, для других, небраузерных, целей).
можно через IFRame — мы так сделали — iframe коннект на 5 минут, отдается отдельным скриптом через nginx. перезапускается каждые 5 минут, а так все сообщения сразу гонит клиенту.
Я вообще отредактировал страничку (поставил «Повторить» на 5000 раз) и начал интенсивно нажимать «Отправить». В итоге всё жутко тормозит и выдаёт ошибки аля «Error: Identifier must be alphanumeric, „Привет тому кто сказал привет“ given».
Автор что-то перепутал с описанием производительности в статье.
на сколько я понял этот сервер позволяет подключаться клиентам (JS) к каналам и принимать посылать сообщения
может ли PHP подключаться к каналам для приёма и отправки сообщений или же только для отправки?
Он позволяет подключаться со стороны JS — на чтение, со стороны PHP — на запись (и на считывание диагностики).
Для приема PHP может подключиться, прикинувшись браузером разве что. Но зачем это? Лучше отправку из браузера на сервер делать обычным аяксом, обычным скриптом.
как это зачем?
для быстрого обмена конечно же :)
да и вообще уточнить не мешало-штука то интересная ;)
P.S.
с JS на запись это я как то не разобрался, да :)
В libevent, если обрыв соединения проскочил в промежуток между добавлением события и началом его обработки, в первой же строчке perl-обработчика возникает SIGPIPE, который рушил скрипт и заставлял Realplexor перезапуститься. Я сейчас поставил заплатку на это (просто игнорируется сигнал, т.к. дальше по коду нужные проверки имеются).
Не страшЁн нам огонь при пожаре,
А страшна паникА при пожаре.
При пожаре гибнУт единицы,
При панИке же — сотни гибнУт.
В том смысле, что проблемы не страшны, страшно, когда они не исправляются. А исправляться они будут, т.к. проект активно используется (и будет использоваться еще кучей людей в OpenSource-community, я подозреваю).
Отличная работа. Насколько, ориентировочно, это приложение стабильно?
Т.е. имеет ли смысл сейчас перестраиваться под него в разрабатываемом проекте?
Сейчас, используется нечто похожее, только с использованием memcacheq, но решение с отдельным демоном мне нравится больше, тем более, что у вас уже все реализовано и на стороне php и на стороне клиента.
Ну, мы его в Рутвите используем. Насколько стабильно — это только время может показать. Главное, что у него всегда будет активная поддержка, а изменения в код вносить очень легко, благодаря тому, что код на Perl и покрыт автотестами.
Есть один вопрос — а как включить режим работы с теми самыми долгоживущими соединениями?
Мой httpfox плагин показывает просто пачку обычных HTTP запросов (в ответ получая JSON).
А только что вообще словил кучу 502 Bad Gateway от nginx'а.
Где тут долгоживущие соединения? :(
Да, я как бы понял и видел :) но при сборке валится.
Result: FAIL
Failed 2/36 test programs. 0/283 subtests failed.
make: *** [test_dynamic] Error 255
VPARSEVAL/Event-Lib-1.03.tar.gz
/usr/bin/make test — NOT OK
//hint// to see the cpan-testers results for installing this module, try:
reports VPARSEVAL/Event-Lib-1.03.tar.gz
Running make install
make test had returned bad status, won't install without force
Failed during this command:
VPARSEVAL/Event-Lib-1.03.tar.gz: make_test NO
1.) Сколько потоков\файберов использует ваш сервер?
2.) Возможно ли решение проблемы лимита 2 соединений без сабдомена?
3.) Поддерживаться ли все браузеры?
Несколько замечаний.
Количество открытых хендлов лимитировано ОС, а это вроде далеко не сотни тысяч. Далее стандарт TCP en.wikipedia.org/wiki/Transmission_Control_Protocol
предполагает 16 бит на порт это (0-65535), каждое клиентское подключение заберет 1 порт.
1. Вообще-то, один. Это же событийно-ориентированный сервер.
2. Кажется, нет.
3. Ну все — вряд ли (IE 2.0 или Lynx вряд ли поддерживаются). Но основные, до которых мы смогли дотянуться, — поддерживаются, конечно.
По поводу числа сокетов — ulimit -n 1048576 и несколько listen-сокетов вместо одного (например, на разных IP-адресах) дают до миллиона соединений. Это не проблема.
Вы не могли бы после реального тестирования опубликовать результаты, очень интересно на таких нагрузках. CPU, Память, параметры IО, результаты top.
>> Вообще-то, один. Это же событийно-ориентированный сервер.
Ммм, асинхронный IO это хорошо, но на моей практике например бродкаст рассылка по > n тысяч соединений уже занимает существенное время.
Пробую на работе — не работает. Видимо есть завязки на конкретные порты, значит для корпоративных пользователей будет не доступно. Жаль. Вечером попробую дома.
Правда, в силу того, что просмотров — несколько штук в секунду, это скорее демонстрация ситуации, когда Long Polling не особенно эффективен — ведь после приема данных «длинное» соединение снова переустанавливается, и это происходит несколько раз в секунду. Тут скорее Streaming нужен, но в IE с ним беда. (Ну или flash-решение.)
а зачем скрывать? пусть пишет, это как то не особо и важно. да, есть такая проблема с лоадингом, но ее по-моему, никак принципиально не решить. Подождем веб-сокетов из html5 :)
вот именно, что в каждый отдельный идут с такой частотой. К сожалению, проект по NDA, потому не могу раскрывать подробностей. Но это именно частота прихода обновлений каждому клиенту — конечно есть больше, есть меньше, но тех, которых меньше, их меньше :) Подошло бы то, что делает Lightstreamer, но дорого + не вписывается в инфраструктуру никак :(
Спасает то, что потолок клиентов параллельно висящих небольшой — до десятка тысяч.
Я прекрасно знаю, что это такое. То есть, устанавливать в среднем каждую секунду новое соединение? Пока прекрасно живет вариант с IFrame, который 5 минут получает данные, потом переоткрывается.
> Я прекрасно знаю, что это такое. То есть, устанавливать в среднем каждую секунду новое соединение?
Long Polling устанавливает соединение не каждую секунду, а раз в 5 минут (к примеру). Либо я Вас не понял, и Вы говорите о чем-то другом, либо же Вы так и не прочитали статью в Википедии.
1. Установили соединение.
2. Получили пакет данных.
3. Закрыли соединение, открыли новое (п. 1)
Так? Если у меня пакеты данных поступают раз в секунду, значит соединение будет закрываться и открываться чтобы получить новый пакет каждую секунду. Вы говорите о случае, когда соединеие открылось, далее ждет (до максимум указанного вами 5 минут), и потом переоткрывается. Если данные пришли раньше, соединеие будет сброшено после них. В случае IFrame — пакеты идут на всем протяжении работы срипта, то есть он живет полюбому 5 минут и за это время коннект постоянен.
Различия ведь только в протоколе передачи данных? Все одно используется Javascript скрипт для соединения. Так какая раница, как он уже передает данные? Ведь принцип и плюсы одни и те же.
Задачи как я понял тоже совпадают, так зачем платить больше?
dklab — это имя, которое известно многим! респект :)
Одно мне не очень понятно, чего же это так остальной народ скачет услышав слово comet?
Ведь по сути вещь тривиальная, если понять, что нужно сделать.
Достаточно эффективная, многопоточная реализация в виде Java сервлета занимает страницы полторы кода, и работает весьма шустро, так как тормозить-то там в общем нечему.
На сотни тысяч коннектов я, правда не замахивался — нужна была только пара тысяч. Решение «влоб» заработало сразу и без тормозов, так что дальше и я не разбирался.
ну может потому что ваша реализация — закрытая внутреняя, а здесь готовое решение? Я тоже думал про сервлет и т.п., но сейчас все же склоняюсь к иному решению…
P.S. Хотя особенно понравились Servlet 3.0 там асинхронность вкусная!
Готовое открытое решение я приводил — CometD, есть решения от Sun, IBM, Resin, IceSoft. Но если приложение на Java, то можно использовать Atmosphere и извлечь большую выгоду от тесной интеграции со своим приложением при простоте и надежности реализации.
P.S. Если использовать современные сервлет контейнеры, такие как Jetty, Glassfish, Tomcat6, то асинхронность будет из коробки, без необходимости интеграции с nginx и т.п.
вопрос, который меня всегда смущал — вот есть у меня веб-приложение. есть данные. Как мне отправить эти данные тому же кометд или сервлету на атмосфере, чтобы он передал их клиентам? Как совместить с другой инфраструктурой? Ни один из этих продуктов апи не предоставляет сразу
Дело не в сотнях тысячах соединений и даже не в сложности самой реализации comet-like протокола. Главная сложность — организация мультиподписки, мультиотправки, очередей, доставки с гарантией, удобного конфигурирования и запуска и т.д., а также — чтобы это все не глючило и было удобным в поддержке. Чистая алгоритмика. Самого кода работы с соединениями (общение с libevent) в Realplexor-е совсем немного — всего около сотни строчек.
Кстати, по поводу глюков. Не знаю сталкивались ли вы с такой штукой, но мне пришлось поковыряться достаточно долго, поэтому теперь рассказываю всем :)
Если мы сделали ajax запрос, который заблокировался на некоторое время на сервере,
но это время пользователь нажал F5, то старый запрос через некоторое время получит следующее сообщение от сервера и успешно доставит его в никуда.
Это, видимо, как раз на тему гарантированной доставки.
На сайте не нашел как связаться с разработчиками, потому пишу здесь.
Если ваш проект не прекратит спамить пользователей Рамблера приглашениями без возможности отписки и удаления аккаунта с rutvit.ru, Рамблер вас закроет.
Считайте это официальным предупреждением.
Вторых «Профессионалов» Рунету не надо.
— Андрей Шетухин,
руководитель группы разработки
почтовой системы,
Rambler.ru
Спасибо, что Вы нашли время поднять этот вопрос на Хабре. Мы с
удовольствем хотели бы пообщаться о проблеме, которая существует с
почтой Рамблера. Постараюсь ответить на Ваши вопросы по существу.
1. «На сайте не нашел как связаться с разработчиками»
На каждой странице нашего сайта имеется всего одна служебная строка с
«Написать нам» (там же, где Помощь, О Проекте, и т.д.). Мы стараемся
отвечать не только на каждый запрос пользователя, но и делать это в
режиме реального времени.
2. «без возможности отписки»
В каждом уведомлении, уходящем c РуТвита, имеется возможность нажать
всего раз всего на одну ссылку (даже настройки менять не надо) и этим
действием либо отписаться от получения всех уведомлений с РуТвита,
либо отписаться только от уведомления данного типа. Нам неизвестно ни
об одном случае сбоя в системе, когда пользователь отписался и получил
от нас письмо.
3. «удаления аккаунта с rutvit.ru
Мы удаляем аккаунт пользователя по первой просьбе. С момента запуска
проекта мы получили менее десяти просьб об удалении аккаунтов, и все
они были удовлетворены. Нам неизвестно ни об одном случае сбоя в
системе, когда мы удалили пользователя, а он продолжал получать от нас
уведомления.
4. „спамить пользователей Рамблера приглашениями“
Наш пользователь сам инициирует приглашение. Приглашение высылается
только один раз и только по инициативе пользователя. Приглашающий
пользователь может пропустить этот шаг в процессе регистрации и не
высылать ни одного приглашения своим друзьям. РуТвит не высылает
повторных приглашений, в отличие от некоторых хорошо известных
ресурсов Рунета.
Вы, как руководитель почты, должны знать, что наши приглашения и
уведомления не попадают под определение спама потому что они не
являются „повторяющейся массовой рассылкой роботом без возможности
отписаться и удалить свой аккаунт.“
— письмо-приглашение высылается один раз по инициативе пользователя и
только по адресу его друга
— письмо-уведомление всегда содержит ссылку, нажатие на которую
позволяет отписаться от этого типа уведомления или всех уведомлений
— аккаунт удаляется раз и навсегда по просьбе пользователя
5. „Рамблер вас закроет“
Такой подход неконстуктвен. Чего вы добились тем, что Вконтакте уже
отказался от использования почты при регистрации? Я предполагаю, что
Вами движет желание в первую очередь помочь пользователям почты
Рамблера. По крайней мере так было, когда разработкой почты руководил
Капранов, и именно поэтому почта Рамблера была тогда самой удобной для
пользователей Рунета.
Я хотел бы предложить конструктивный диалог, так как какая-то проблема
с рассылкой приглашений или уведомлений, видимо, все же существует,
если на нее тратится внимание руководства Рамблера. Мне кажется, что
проблема в отсутствии стандарта в Рунете, который бы решал проблему
приглашений и уведомлений одним прозрачным, всем понятным способом.
Почему бы Вам не задать тон и разработать такой „Золотой стандарт
почты Рамблера“ для всех социальных сайтов Рунета? Мы будем первыми,
кто его внедрит. Если он действительно будет соблюдать интересы всех
заинтересованных лиц, его внедрят и остальные сайты Рунета, а Рамблер
займет лидерскую позицию по вопросу вместо позиции „не пущать“.
6. Нами, кроме желания развивать наш проект, также движет желание
помочь нашим пользователям
а) быстро находить своих друзей, которые уже пользуются РуТвитом
б) быстро приглашать своих друзей, которые еще не пользуются РуТвитом
Именно с этими целью мы предлагаем использовать книжку с адресами в
почте Рамблера.
Подчеркну, что проблема не нова, и она уже давно решена любой западной
почтой без необходимости предоставлять пароль РуТвиту.
В связи с этим у меня к Вам еще один встречный вопрос-предложение.
Если почта Рамблера действительно заботится о своих пользователях,
почему бы ей не реализовать открытый протокол OAuth. У нас это заняло
всего несколько дней. Дима Котеров писал о протоколе на Хабре. Готовы
помочь советом, если это необходимо.
Например, мы предлагаем то же самое пользователям Gmail.com, который
поддерживает OAuth. В результате пользователь Гмейла имеет возможность
разрешить заглянуть в свою записную книжку без предоставления пароля
от его почты. Доступ недвусмысленно разрешается владельцем почтового
аккаунта на Гмейле, а приглашения от пользователя Гмейла все равно
могут доставляться. Почему бы Вам не реализовать эту передовую
технологию в почте Рамблера и не предоставить ее через API?
Пользователи и социальные сайты были бы благодарны.
7. В заключение, хочу сказать, что я вполне допускаю, что у нас есть
недочеты и я готов работать над их исправлением. Но хотелось бы видеть
не огульное зачисление всех в „профессионалы“, а конкретные
предложения, что еще можно улучшить с нашей стороны. Ни одно
предложение не останется без внимания.
P.S. Нам уже пришла жалоба, что почта на Рамблере не работает. Жаль,
что Вы только предупреждаете, а кто-то ее уже перекрыл.
Я, рядовой пользователь Rambler, получил от вас спамерские письма. Я считаю подобное поведение неприемлемым и нарушающим основы нетикета. Пока вы не измените свою политику, почта от вас на Рамблер ходить не будет.
На мнение минусующих мне плевать, я забочусь не о вебдванольдебилах, а о пользователях Почты Рамблера.
Импортирование адресной книги в другие сервисы без согласия лиц, контакты которых перечислены в адресной книге — это сбор и распространение ичной информации без согласия владельца. Подобное не только аморально, но еще и недопустимо с точки зрения закона.
Ладно, я понимаю, что вам, Андрей Владимирович, привычнее врать и угрожать нам, вместо того, чтобы отвечать на наши вопросы.
Но зачем же вы стираете комментарии возмущённых пользователей почты Рамблера? Может быть, всё же ответите, например, вот этому:
phprus.livejournal.com/:
<<<Извините, что влажу в вашу дискуссию, но позвольте поинтересоваться,
на основании каких законов или правил вы решаете за меня кому и каким
образом предоставлять доступ к моей адресной книге находящейся в
рамблер-почте? А так-же на каком основании вы указываете мне как
распоряжаться адресной книгой находящейся на почтовых сервисах не
имеющих к рамблеру никакого отношения?
Кроме того почему некий сервис должен получать письменное разрешение
на использование данных которые вашей компании не принадлежат? (или я
что-то пропустил в вашем пользовательском соглашении и по нему все,
что я пересылаю через рамблер становится собственностью рамблера?) >>>
я — как владелец аккаунта рамблера — имею доступ к своей адресной книге. логично же? я могу её сохранять, удалять, распечатывать и вывешивать на автобусной остановке, гугл. доксах и где угодно ещё.
теперь я — как владелец аккаунта рамблера — разрешаю рутвиту доступ к своей адресной книге.
если рамблер считает, что рутвит должен спросить разрешения у всех людей из моей адресной книги, то непонятно, почему я имею туда доступ? ведь я, может быть, разрешения ни у кого не спросил?
> Сами — можете.
Расшифрую это «сами». Оно означает в данном случае следующее:
1. Открыть свой любимый почтовый клиент (например, TheBat или Thunderbird).
2. Скопировать в поле To список email из моей адресной книги.
3. Вставить в текст приглашения ссылку, кликнув на которую, можно стать моим читателем.
4. Нажать кнопку «Отправить».
В настоящий момент РуТвит выступает лишь в роли такого почтового клиента (1) и не более, при этом он упрощает пользователю вставку в поле To email-ов из его адресной книги (2), а также предоставляет автоматически сгенерированную ссылку (3) для приглашения стать моим читателем. Все действия происходят на виду: пользователю явно сообщается на странице выбора получателей (2), что нажатием на кнопку (4) он произведет отправку писем. Т.е. решение о том, отправлять приглашение по почте или нет, принимает пользователь, а не система. Кроме того, для защиты популярных и известных людей от волны однотипных приглашений стоит ограничение: уходит не более 1 приглашения за X месяцев, даже если приглашения высылаются различными людьми.
Если следовать вашей же интерпретации, то именно Рамблер нарушает тот
закон о персональных данных.
Например, Пупкин присылает емейл на мой ящик на Рамблере.
С точки зрения вашей логики, Пупкин не давал разрешения Рамблеру, но
при этом Рамблер, как третье лицо,
1) незаконно сохраняет емейл Пупкина
2) незаконно использует емейл Пупкина в целях уже не лично моих, а
своих — коммерческих
Андрей Владимирович, чепуха, действительно, получается, если следовать
вашей интерпретации закона о персональных данных. Рад, что у нас хоть
в одной точке появилось единое мнение.
Мануалы прочёл, ясности не прибавилось. Что же мне делать, если я хочу
один раз выслать личное приглашение моим друзьям из моей записной
книжки в Рамблере? Раз уж вы затеяли публичное обсуждение, пожалуйста,
дайте рекомендацию по сути.
Если я получив письмо, ничего с ним делать не буду, я получу тот же циклический поток говна, как от «professionaly.ru» или как там их? Или письмо будет только одно?
«Кроме того, для защиты популярных и известных людей от волны однотипных приглашений стоит ограничение: уходит не более 1 приглашения за X месяцев, даже если приглашения высылаются различными людьми» — habrahabr.ru/blogs/hi/79189/#comment_2332075
Обалденный вы подняли срач. Мало того, что публичный, так еще и оффтопиком. Так еще и продолжаете его, хотя вам явно указали, куда отправлять ваши претензии.
Надеюсь, вы, Андрей Шетухин, не долго проработаете в Рамблере и вообще в ИТ руководителем.
Андрей, комментируя одно из Ваших высказываний ниже.
В России, следуя букве ФЗ-152, адрес e-mail не является данными, относящимися к персональным.
Подобные данные являются (безумие!) защищаемыми как ID в Италии, чью модель несколько слепо пытаются копировать в России. С точки зрения юридической, это Ваше заявление является откровенным ляпом.
Чтобы оценить Вашу последовательность в применении антиспам-политики, уточняющий вопрос: не блокируете ли сейчас уведомления о добавлении в «друзья» сервисов Вконтакте, МойМир@ и т.п., которые идут по спам-базам (собранным червями) от одних и тех же «персоналий»? Это тоже пахнет злым умыслом со стороны создателей. ;)
Напомню, уведомления проекта МойМир@(знаете что), который по умолчанию спамил по всему адресбуку инвайтами (этот кейс наверняка знаком создателям Рутвита и Рамблер-Почте) и известен как до сих пор входящий в топ «легальных спамеров», не фильтровались Рамблер-Почтой год назад как спам.
О себе: К рутвиту никакого отношения не имею. Профессионалi.ru считаю плохим сервисом.
PS: Есть частный интерес — как восстановить доступ к адресам почты на sovsem.net, uzhe.net и т.п., купленных Рамблером многие годы назад и де-факто убитым? Форма восстановления не работает даже через Rambler ID — в нее просто не ввести адрес вида email@uzhe.net.
>В России, следуя букве ФЗ-152, адрес e-mail не является данными, относящимися к персональным.
В адресной книге может храниться не только адрес. Как правило, там хранится и некая персональная информация.
>Чтобы оценить Вашу последовательность в применении антиспам-политики, уточняющий вопрос: не блокируете ли сейчас уведомления о добавлении в «друзья» сервисов Вконтакте, МойМир@ и т.п., которые идут по спам-базам (собранным червями) от одних и тех же «персоналий»? Это тоже пахнет злым умыслом со стороны создателей. ;)
Если будет достаточное количество жалоб, мы зарубим и эти сервисы тоже.
>Напомню, уведомления проекта МойМир@(знаете что), который по умолчанию спамил по всему адресбуку инвайтами
Он спамил по своему адресбуку инвайтами. А не воровал чужой адресбук (например, с Рамблера) и не спамил сам через него. Конечно, спамить — нехорошо. Но спамить контакты еще и не твоего адресбука — это верх свинства.
>Есть частный интерес — как восстановить доступ к адресам почты на sovsem.net, uzhe.net и т.п., купленных Рамблером многие годы назад и де-факто убитым? Форма восстановления не работает даже через Rambler ID — в нее просто не ввести адрес вида email@uzhe.net.
А что мешает написать или позвонить в службу поддержки?
Спасибо за детальные ответы. Согласен насчет кражи address-book. Сегодня одному стартапу показал Ваш коммент — придержали прыть.
По багу «чужой почты» — служба поддержки зациклена на «используйте форму восстановления», в которой вылезает баг — сервисы uzhe.net не содержали «секретного слова», а при вводе Rambler ID ссылка на восстановление более недоступна.
onreadystatechange FAILS Error: Permission denied for <domain.com> to create wrapper for object of class UnnamedClass { } readystatechange
Это на Firefox 3.5.6/Win 7, на другом, запущенном на этой же машине, 3.6.b4, все отлично.
При этом, первые 2 — 3 сообщения он получает отлично, дальше вот валится.
* Dklab Realplexor 2009-12-26: v1.23
— [BUG] Empty identifier passed to IN line («identifier=») caused warnings.
— [SPD] Lower the number of useless debug lines and connection's name() calls.
— [BUG] Improved init script: more time to restart and better signal handling.
* Dklab Realplexor 2009-12-24: v1.22
— [BUG] SIGPIPE causes the script to restart on some unexpected client's disconnects.
Many speed improvements. To achieve maximum speed, try to set VERBOSITY to 0 or 1 in your configuration. Also get rid of «automatic» cursors: they use Math::BigFloat (still), and Math::BigFloat is very slow. Specify cursors manually in $rpl->send() API method.
* Dklab Realplexor 2010-01-30: v1.24
— [BUG] Avoid warnings in log on unexpected disconnect.
— [NEW] Refactoring and profiler support.
— [SPD] Do not create extra shell while calling ulimit.
— [NEW] Support for per-config log facility.
— [SPD] Profiler tool with IN line ignorance. Avoid BigFloat in events: 45% speedup. Apache ab patched utility.
— [SPD] Keep channels pre-sorted after addition. It speedups 60%, because we need less cursor comparisions.
— [SPD] STDOUT buffering in non-verbose mode. More verbosity levels. Logger speedup. Custom config for profiler script.
Current profiler map attached. :)
P.S.
This new version passes all auto-tests, but if you find a bug in it, please report it here.
* Dklab Realplexor 2010-02-27: v1.30
— [SPD] Use EV library (http://search.cpan.org/~mlehmann/EV-3.9/EV.pm)
instead of libevent. It is faster and has no memory leaks.
Дмитрий, подскажите, пожалуйста, в чем может быть проблема.
На фронте постоянно сыпется в консоль:
rpl.newfs.ru:83 Bounce detected (bounceCount = 31)
rpl.newfs.ru:83 Next query in 60000 ms
А сами ответы сервера пусты.
Пример работает тут: newfs.ru/sys/test/ подписывается на новые сообщения в чате (который еще работает на старом аяксе, но так же отправляет новые сообщения в канал bp2_chat).
Установил всё как описано. Серверные автотесты проходят успешно (против двух: не верный пользователь и не верный пароль).
Realplexor: производительный Comet-сервер с API для PHP и Javascript (realtime)