kirsan_vlz Sep 16 2011 at 12:41

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

4 min

94K

Website development*

Comments 23

homm Sep 16 2011 at 12:59

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

kirsan_vlz Sep 16 2011 at 14:51

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

homm Sep 16 2011 at 15:21

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

kirsan_vlz Sep 16 2011 at 15:29

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

mr_avi Sep 16 2011 at 15:41

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

ukko Sep 18 2011 at 12:11

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

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

kirsan_vlz Sep 18 2011 at 12:13

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

ukko Sep 18 2011 at 13:56

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

kokoc Sep 16 2011 at 13:23

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

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

kirsan_vlz Sep 16 2011 at 14:53

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

pro100tak Sep 16 2011 at 13:55

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

kirsan_vlz Sep 16 2011 at 14:55

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

Stamm Sep 16 2011 at 14:26

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

kirsan_vlz Sep 16 2011 at 14:49

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

Stamm Sep 16 2011 at 23:51

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

pro100tak Sep 16 2011 at 15:28

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

Vidog Sep 16 2011 at 23:22

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

Vidog Sep 16 2011 at 23:23

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

red_pilot Sep 16 2011 at 23:40

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

Vidog Sep 16 2011 at 23:47

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

Stamm Sep 16 2011 at 23:50

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

Vidog Sep 17 2011 at 00:00

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

Nevkontakte Sep 17 2011 at 06:06

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

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