Простая реализация long polling механизма на PHP

[homm]

> В приведённом коде не учитывается одновременный доступ к памяти.
Т.е. приведенный код на самом деле нерабочий?

[kirsan_vlz]

Рабочий, но при больших нагрузках может возникнуть ситуация, что два клиента одновременно станут писать данные в память. Результат непредсказуем, но, скорее всего, событие в итоге потеряется.
Вообще. тут код приведён как иллюстрация к статье, а не готовое решение. Я его взял из тестового задания, которое недавно делал, для тех задач его хватило, на серьёзных приложениях понадобится немного дописать, о чём я предупредил.

[homm]

Стоп, под большие нагрузки такой бред никто ставить не будет — отдельный инстанс php на каждого клиента — это даже не для малых нагрузок. Речь о том, что оно рано или поздно рванет вообще без нагрузки.

[kirsan_vlz]

Ну большие — это такие, при которых вероятность возникновения двух событий в один момент времени хоть сколько-нибудь ощутима )
У меня чат крутился на этом коде неделю, проблем с поллингом не было, но и сидели там 5 человек.
Тут же статья не о том. что я сделал готовое универсальное решение, а в том, чтобы показать, что поллинг — это не так сложно, как многим кажется, и если приспичит, ничего сложного в написании такого механизма нет.

[mr_avi]

Тут еще момент потребления памяти и процессора каждым клиентов, ведь для каждого запроса подымается вся эта машина из вебсервера, пхп, и всего остального.

[ukko]

Поставьте туда семафоры, для этого надо дописать пять новых строчек.

Но так вы избежите одновременного доступа к памяти.

[kirsan_vlz]

Я про семафоры в статье писал.

[ukko]

Прошу прощения, действительно, не заметил.

[kokoc]

Есть предложение уменьшить вложеность конструкций в методе Polling::listen, потому что читаемость кода страшно падает. Сделать это можно добавив дополнительную точку выхода к первому условию и поменяв на обарное второе, чтобы получилось нечто подобное:

if ($shmid) {
    return $result;
}
while (time() < $endTime) {
    if ($storage['_updated'] < $lastQueryTime) {
        continue;
    }
     .......
    break;     
}

[kirsan_vlz]

Ну да, обычно так и делаю, тут пропустил, а потом внимание не обратил. Спасибо, что заметили.

[pro100tak]

Как же органично для этого подходит Node.JS!
Создаём сервер, но не отправляем конечный ответ, только заголовки для использования chunked-режима. Далее — делаем сокет-сервер, слушающий какой-либо порт и, при поступлении события в сокет (справится обычный fsockopen() в PHP) просто дописываем отбивку 1024 байт (для осла) + данные. Итого — не переустанавливается соединение и в ифрейм постоянно сыпятся данные.

[kirsan_vlz]

Да тут много чего более органично подойдёт. Ниже вот про realplexor справедливо заметили.
Но красивые решения требуют сторонний софт и node.js тут, увы, не исключение.

[Stamm]

Зачем свой велосипед, когда есть dklab_realplexor?

[kirsan_vlz]

Когда я задание получил, первым делом про реалплексор вспомнил, но в моём случае мне нельзя было использовать сторонний софт. Пришлось самому писать, впрочем это было интересно.
А вообще, тут цель статьи не дать готовое решение, а показать, как это работает. Многие почему-то считают, что это совсем сложно, хотя это не так.

[Stamm]

Соглачен, это принцип работы совсем простой. Да и работает довольно прозрачно, это я про realplexor.

[pro100tak]

Я работал и с реалплектором и с Нодой. Вердикт — реалплексор кажется (только кажется) надёжнее, но Нода быстрее. Тяжёлый траффик они держат одинаково, но в top нет процесса перла, отжирающего 15-20% 4-х ядерного процессора.
ИМХО — мой выбор — Node.JS

[Vidog]

лучше даже ape, имхо. прост в установке и «hello, world» с пулом примерно в 10 строк.

[Vidog]

прошу прощения, ссылка: www.ape-project.org/

[red_pilot]

Ape очень любит процессор и память, даже в режиме простоя.
На 2х процессорном сервере он ел 15% в простое.

[Vidog]

вы его, видимо, как-то неправильно настроили. Облако на selectel'е потребляет 230 мб оперативки и 0.03% (!) CPU в простое.
Установлены и работают: nginx, mongod, php-cgi, aped, memcached

[Stamm]

Я выбирал между ape и realplexor. Остановился на realplexor — он полностью готов к работе с php из коробки.

[Vidog]

А вообще, мне кажется, что такой код должен решаться не на уровне PHP точно…

[Nevkontakte]

Вообще, проблема начнется в тот момент, когда количество онлайнеров превысит количество воркеров веб-сервера или количество fastcgi процессов. При нынешних ценах на vps можно себе позволить пользоваться ими для реальных задач.

Ну а в качестве proof-of-concept такой пример прокатит, да.