MiksIr
miksir@home:~$
http://phpclub.ru/talk/threads/Тонкий-принцип-работы-сокетов-php.79298/
Как раз для этих целей (обработка множества соединений в одном процессе) libevent и сделано.
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
кто-то делал PHP-демоны на базе libevent ?
- Автор темы полудух
- Дата начала
Как раз для этих целей (обработка множества соединений в одном процессе) libevent и сделано.
полудух
Итсист
вы говорите, что с libevent не нужны форки и можно каждый запрос "вешать" на минуту?
ссылка отличная, спасибо )
Absinthe
жожо
полудух
Итсист
по сути это выглядит, как 2 демона запустить на разные порты
так, значит раз у меня 1-разовая передача команд, а не подгрузка новых данных при постоянном подключении, значит буферы не нужны?
тогда, если с libevent и без буферов, то просто в onAccept() поюзать fread(), как вы там писали?
кстати, почему fread(), а не socket_read() ?
Последнее редактирование:
полудух
Итсист
глава IT в Alpari в 2014 году юзает declare(ticks=100);
ясно. понятно.
Absinthe
жожо
Там и другие способы есть. Я наиболее интересный озвучил.
полудух
Итсист
кстати, игровой сервер
Absinthe
жожо
Для тех игр, бекенды которых на PHP, проще все посчитать в обычных запросах. Обычная логика там.
полудух
Итсист
не, ксы всякие
полудух
Итсист
кстати, чё-то у меня эта обработка идёт последовательно, а не параллельно
т.е. многопоточность где? я думал тут речь про неё...
я повесил sleep(5) и он через 5 сек каждый запрос обрабатывает (в лог пишет)
т.е. получается, что без форков её не достичь?
Ни к какой многопоточности libevent отношения не имеет.
Его смысл исключительно для i/o bound приложений, то есть для тех случаев, когда с классическим "блокирующим" подходом 90% времени приложение будет находиться в ожидании поступления информации по сети - смысл в том, чтобы не ждать, а обрабатывать массу сетевых соединений параллельно и запускать соответствующий обработчик, как только откуда-то данные прилетели, и обработчики при этом должны быть легкие, иначе весь смысл теряется.
С cpu bound (вычисления) - только форки или ядерные треды.
Его смысл исключительно для i/o bound приложений, то есть для тех случаев, когда с классическим "блокирующим" подходом 90% времени приложение будет находиться в ожидании поступления информации по сети - смысл в том, чтобы не ждать, а обрабатывать массу сетевых соединений параллельно и запускать соответствующий обработчик, как только откуда-то данные прилетели, и обработчики при этом должны быть легкие, иначе весь смысл теряется.
С cpu bound (вычисления) - только форки или ядерные треды.
полудух
Итсист
так суть моего вопроса в чём, - а где же его параллельность то?
с одной стороны говоришь "никакой многопоточности", а с другой "параллельно обрабатывать и запускать"
т.е. libevent с одной стороны может сразу все подключения принять, а с другой он их все в очередь складывает...
я так понял, его параллелизм заканчивается на обработчике, в котором уже надо форки плодить
я делаю демона, который запускает именно долгие, тяжёлые команды с диска, получая команды извне
полудух
Итсист
строго говоря, мне просто не нравится концепция while(1){}
libevent как-то приятнее просто
полудух
Итсист
в данном случае libevent это "современный комп"
MiksIr
miksir@home:~$
C этой точки зрения нет никакой разницы между libevent и socket_accept
Оба варианта - бесконечный цикл.