Возможно ли на php написать многопотокового демона?
- Автор темы HelpFinder
- Дата начала
voodoo
Новичок
Alexandre, у меня оне на одном порту дружат с помощью socket forwarding
Antoxa, в теории так, на практике
1. когда я этим занимался nginx не было
2. выбирать можно когда пишешь один раз для себя, если же планируется распространять, то надо все-таки смотреть на что способны клиенты
3. с nginx-ом проблем хватает. вот например -- про сколько угодно процессов. Когда я ему говорил сделать два процесса, он при нагрузке у меня забывал про второй вирт. хост (первый работал).
Так что свой демон, занимающийся только _одним_ -- отдачей потока сообщений, ничем не хуже чем тот же демон за нгиксом (ну зачем при отправке хтмля от сервера к клиенту нужна доп. прослойка?)
Antoxa, в теории так, на практике
1. когда я этим занимался nginx не было
2. выбирать можно когда пишешь один раз для себя, если же планируется распространять, то надо все-таки смотреть на что способны клиенты
3. с nginx-ом проблем хватает. вот например -- про сколько угодно процессов. Когда я ему говорил сделать два процесса, он при нагрузке у меня забывал про второй вирт. хост (первый работал).
Так что свой демон, занимающийся только _одним_ -- отдачей потока сообщений, ничем не хуже чем тот же демон за нгиксом (ну зачем при отправке хтмля от сервера к клиенту нужна доп. прослойка?)
Лысый
Новичок
ИМХО
на ПХП писать демога так же удобно как и на любом другом языке.
но наверное ПХП интерпритатор врядли расчитан на поддержку подолгу висящих в памяти процессов.
одно дело когда в памяти всист сама прога, а другое дело когда ради такого демона в памяти парится процесс интерпритатора со всем сопутствующим скарбом.
на ПХП писать демога так же удобно как и на любом другом языке.
но наверное ПХП интерпритатор врядли расчитан на поддержку подолгу висящих в памяти процессов.
одно дело когда в памяти всист сама прога, а другое дело когда ради такого демона в памяти парится процесс интерпритатора со всем сопутствующим скарбом.
voodoo
Новичок
здесь только надо не забывать еще что между nginx и демоном будут те же х коннектов, т.е. теоретически конечно можно сделать и на одном, но это надо переписывать nginx чтобы он умел разбираться кому какое сообщение передавать.
И тут мне непонятно, чем send(ту клиентский_тцп_сокет) хуже чем send(ту nginx_unix_сокет), ведь send придется делать в любом случае (это к вопросу о том что каждый должен заниматься своим делом, демону этим делом придется заниматься в любой схеме);
но понятно что во втором варианте у нас лишние расходы в 2 постоянно открытых сокета на каждого подключенного клиента и расходы на доп. пересылку данных внутри системы, плюс расходы памяти в nginx на буферы, плюс еще возможные проблемы с кэшированием.
При этом можно сделать так, что демону общаться с клиентом в общем-то и не нужно, обработку входящего запроса можно отдать тому же апачу или nginx-у, они с этим, безусловно, лучше справятся (впрочем, чат-демону всего-то и надо что выцепить ид сессии из запроса, никакой более серьезной обработки не требуется). Но вот зачем они (апач и ко) нужны при отдаче -- непонятно. Передали клиентский сокет демону и можете заниматься своими делами.
AnToXa
prodigy-одаренный ребенок
voodoo
1. когда ты этим занимался?
nginx появился примерно в октябре 2004 года.
2. ага, на пхп + mysql способны, если им дают ssh и возможность собирать и запускать своих демонов, то нет никакой разницы, а ну да, апач если навязывают, но имхо когда дают демонов запускать, это уже либо dedicated либо virtual dedicated, там можно и апач заменить на свое. разве нет?
3. дело в том, что демон занимается не только отдачей потока сообщений, он также занимается: форматированием данных в html, хранением сообщений, общением с клиентом по протоколу HTTP (который в варианте даже 1.0 уже не сильно простой). ваш чат демон поддерживает chunked responses? pipelining? keep-alive? gzip/deflate? перекодировки (ведь не у всех клиентов utf ну и так далее) , а что демон делает, когда у него сообщений слишком много накапливается? еще и на диск их скидывает наверное? а сколько соединений ваш демон может обработать? а что насчет уязвимостей, даже в апаче их находят, наверняка ваш продукт используется не столь массово и не столь оттестирован.
-~{}~ 14.11.06 16:18:
voodoo
я предлагал схему: webserver -> php -> daemon.
webserver: взаимодействие с клиентами и пхп.
php: взаимодействие с демоном, форматирование всякого html.
демон: хранение сообщений, приваты, комнаты и прочее.
каждый занимается своим делом, система масштабируется, легко модифицируется(ага, давайте внутрь чат-демона запихнем шаблоны по которым надо html формировать), дебажится, мониторится, меньше писать и инструменты почти стандартные.
соединений больше, да, и что? вы померили performance?
вы все тут рассказываете в предположении, что нужна просто ураганная скорость, что не справится nginx с пхп и что вообще все плохо, раз уже начали считать дескрипторы, взаимодействие через lo (что есть по сути 2 сискола + буфер в ядре), плюс кешируете зачем-то страницы чата (я чего-то не понимаю наверное, но зачем?!).
1. когда ты этим занимался?
nginx появился примерно в октябре 2004 года.2. ага, на пхп + mysql способны, если им дают ssh и возможность собирать и запускать своих демонов, то нет никакой разницы, а ну да, апач если навязывают, но имхо когда дают демонов запускать, это уже либо dedicated либо virtual dedicated, там можно и апач заменить на свое. разве нет?
3. дело в том, что демон занимается не только отдачей потока сообщений, он также занимается: форматированием данных в html, хранением сообщений, общением с клиентом по протоколу HTTP (который в варианте даже 1.0 уже не сильно простой). ваш чат демон поддерживает chunked responses? pipelining? keep-alive? gzip/deflate? перекодировки (ведь не у всех клиентов utf
ну и так далее) , а что демон делает, когда у него сообщений слишком много накапливается? еще и на диск их скидывает наверное? а сколько соединений ваш демон может обработать? а что насчет уязвимостей, даже в апаче их находят, наверняка ваш продукт используется не столь массово и не столь оттестирован.-~{}~ 14.11.06 16:18:
voodoo
я предлагал схему: webserver -> php -> daemon.
webserver: взаимодействие с клиентами и пхп.
php: взаимодействие с демоном, форматирование всякого html.
демон: хранение сообщений, приваты, комнаты и прочее.
каждый занимается своим делом, система масштабируется, легко модифицируется(ага, давайте внутрь чат-демона запихнем шаблоны по которым надо html формировать), дебажится, мониторится, меньше писать и инструменты почти стандартные.
соединений больше, да, и что? вы померили performance?
вы все тут рассказываете в предположении, что нужна просто ураганная скорость, что не справится nginx с пхп и что вообще все плохо, раз уже начали считать дескрипторы, взаимодействие через lo (что есть по сути 2 сискола + буфер в ядре), плюс кешируете зачем-то страницы чата (я чего-то не понимаю наверное, но зачем?!).
voodoo
Новичок
AnToXa, занимался я этим активно до сентября 2004
кип-элайв демону явно не нужен, потому что работает только когда известен размер контента, что для чат-демона невозможно (непрерывный поток).
то же про гзип (разве можно гзипить кусками?) и остальное
Схема webserver->php->"что угодно" для отдачи непрерывного потока работает нормально (из опыта) до 150 коннектов. Масштабируемостью там и не пахнет, т.к. нам нужен один процесс с пхп для каждого подключенного клиента (висящего часами). Неважно, будет это чайлд апача или фастцги запрошенный nginx-ом.
Еще раз, я говорю про чат-демона для _непрерывной_ отдачи сообщений (и, мне кажется, остальные, в основном, тоже). Это, по-моему, ключевой пункт из-за чего у нас тут разногласия. Да и вообще это не по rfc, но работает, что для посетителей главное.
Страницы я не кэширую, это nginx буферизирует что ему отдают, что неприемлемо в такой схеме.
Соединений же наблюдаю каждый вечер в районе 1100 (ладно, приврал, там на сервере два чата и два демона, 600 и 500, впрочем основная нагрузка идет совсем от другого), так что рассказываю не в предположениях а по реальному опыту.
Продукт, конечно, не массовый, но если sourceforge не врет, то 180,892 скачиваний с момента старта (апрель 2002). И уязвимости были, куда-ж без этого.
кип-элайв демону явно не нужен, потому что работает только когда известен размер контента, что для чат-демона невозможно (непрерывный поток).
то же про гзип (разве можно гзипить кусками?) и остальное
Схема webserver->php->"что угодно" для отдачи непрерывного потока работает нормально (из опыта) до 150 коннектов. Масштабируемостью там и не пахнет, т.к. нам нужен один процесс с пхп для каждого подключенного клиента (висящего часами). Неважно, будет это чайлд апача или фастцги запрошенный nginx-ом.
Еще раз, я говорю про чат-демона для _непрерывной_ отдачи сообщений (и, мне кажется, остальные, в основном, тоже). Это, по-моему, ключевой пункт из-за чего у нас тут разногласия. Да и вообще это не по rfc, но работает, что для посетителей главное.
Страницы я не кэширую, это nginx буферизирует что ему отдают, что неприемлемо в такой схеме.
Соединений же наблюдаю каждый вечер в районе 1100 (ладно, приврал, там на сервере два чата и два демона, 600 и 500, впрочем основная нагрузка идет совсем от другого), так что рассказываю не в предположениях а по реальному опыту.
Продукт, конечно, не массовый, но если sourceforge не врет, то 180,892 скачиваний с момента старта (апрель 2002). И уязвимости были, куда-ж без этого.
AnToXa
prodigy-одаренный ребенок
гхм. непрерывная отдача - это типа соединение никогда не закрывается, но мы все же каким-то образом остаемся в рамках http? т.е. и браузеры сие поддерживают как я понимаю.
да, это не совсем то о чем я думал, тут вообще неприменим вебсервер, который реализует протокол http, потому что то чем вы там обменияваетесь - это не совсем http, или даже совсем не http.
правильно я понимаю, что контект отдается только со стороны сервера, а браузер думает что ему отдается просто "бесконечная" страница?
и в чем преимущества перед "нормальной" моделью запрос-ответ?
как при таком раскладе от проблемами с таймаутов соединений бороться?
тогда частично мои рассуждения не применимы, потому что бенефиты там исходят из того, что используются готовые отлаженые инструменты.
правда рассуждения на тему: каждый занимается своим делом все же применимы как ни крути, но пхп там не совсем в тему тогда конечно.
да, это не совсем то о чем я думал, тут вообще неприменим вебсервер, который реализует протокол http, потому что то чем вы там обменияваетесь - это не совсем http, или даже совсем не http.
правильно я понимаю, что контект отдается только со стороны сервера, а браузер думает что ему отдается просто "бесконечная" страница?
и в чем преимущества перед "нормальной" моделью запрос-ответ?
как при таком раскладе от проблемами с таймаутов соединений бороться?
тогда частично мои рассуждения не применимы, потому что бенефиты там исходят из того, что используются готовые отлаженые инструменты.
правда рассуждения на тему: каждый занимается своим делом все же применимы как ни крути, но пхп там не совсем в тему тогда конечно.
voodoo
Новичок
ну хттп же не обязывает отдать страницу за определенное время.
тут главное что браузеры научились рендерить страницу не ожидая полного ее скачивания (там есть нюансы, напр. таблицу ие может только целиком показать).
Так что, формально, все в рамках. но обычные вебсерверы такое не любят, это уж точно.
в общем да. только браузер про бесконечность не думает, наверное, просто ждет когда "сервер перестанет тормозить" и все догрузится (content-length ему-ж не передают)
1. фактически получаем аналог IRC, т.е. пользователи видят всё и быстро (при этом не нужны доп программы и модули типа jre)
2. нагрузка на сервер (ну при использовании демона, а не 600 одновременных пхп скриптов) меньше чем при релоаде (и "классическом" и "ajax"-овом)
у меня если клиенту ничего не шлется в течение некоторого времени, демон отправляет джаваскрипт-вызов функции (она все равно нужна у меня для апдейта "статуса", чтобы клиент видел что жизнь идет)
с этим-то вроде никто и не спорил
AmadMike
Новичок
Не AJaX, а использование таблиц типа MEMORY (HEAP) я думаю подымет perfomance.
А AJaX-ом можно избавить от бесконечной загрузки - подключаться через каждые 5 секунд и получать xml с новыми сообщениями или какой-нибудь false если сообщений нет. Получится что весь html-код и все остальное будет формировать php, а браузер через HttpRequest будет получать новые данные от демона и обрабатывать их, можно даже от фреймов избавиться в таком варианте.
Ну а если запускать для каждого соединения php-скрипт, который будет обращаться к демону, то зачем тогда вообще демон, только для хранения в памяти данных?