Сокетный сервер на php

PHP*
Сколько одновременных постоянных tcp соединений может выдерживать сокетный сервер на php? Если, например, требуется 1000 одновременных соединений, стоит ли использовать php или выбрать другую технологию?

[EDIT]
Уточняю вопрос.
Есть стандартный интерпретатор php (берем с php.net), который будет работать, скажем, на каком-нибудь дистре линукса.
В php есть функции для работы с сокетами (в комментах уже указали ссылку). Итак, пишем на чистом php с использованием этих функций тривиальный эхо сервер (не мультикаст), но так, чтобы tcp соединения были постоянными. Почему/насколько это будет работать хуже, чем аналогичный эхо сервер, сделанный с помощью С++/Java/Python и т.д. Почему-то многие не рекомендуют использовать для этого php…
30 сентября 2010 в 17:46
2
DankoUA 17,1

отсортировано по дате по оценке
ответы (11)

+1
mayhem #
php какбы не совсем для этого, думаю…
0
DevMan #
ИМХО, тут вопрос скорее к реализации сервера, чем к языку.
я думаю такая производительность больше зависит от реализации интерпретатора php (низкий уровень), чем от реализации сервера (высокий уровень). DankoUA, 30 сентября 2010 в 21:09
Ошибаетесь — можно написать полную бездарность на компилируемом языке и конфетку на интерпретируемом.

Да и о какой «такая производительность» может идти речь когда о задаче неизвестно ничего, кроме «1000 одновременных соединений»?
DevMan, 30 сентября 2010 в 21:36
2DankoUA: Простите, про производительность ни слова вопроса нет — соединение может быть открыто сутками, но ни одного байта по нему не передастся. Тысяча таких соединений или миллион разницы практически нет (если не порождать новый процесс на каждое, конечно) VolCh, 30 сентября 2010 в 21:41
0
square #
Вот тут посмотрите — nanoweb.si.kz/?p=perf
0
schursin #
Когда-то интересовался этим вопросом. Про сами сокеты можно почитать тут: www.php.net/manual/en/ref.sockets.php, при желании в сети можно найти уже готовые классы серверов.

Но вывод моего изучения данного вопроса — проще, и по логике, и по ресурсам, и по производительности, забыть про PHP в данном отношении, и реализовать на Java/C/Perl или другом языка более близком Вам.
+2
VolCh #
0
DevMan #
Почему-то многие не рекомендуют использовать для этого php
Потому что:
— некоторые не умеют его готовить
— у некоторых бытует мнение, что PHP — моветон и изначально проигрышен (я его не разделяю)
— и т.п.

пишем на чистом php
И опять возвращаемся к моему первому коменту. Чистый PHP ничего не знает о 1000 коннектов — их надо чем-то обрабатывать (mod_php + Apache, или CGI/FastCGI + your_favorit_webserver, или демон). Так что производительность будет зависеть ни только от PHP (его вполне достаточно), а от всей связки в целом.
Немного сумбурно объяснил, но надеюсь, что мысль понятна.
Как это ничего не знает? socket_listen(), socket_accept() и т. п. как раз и сделаны для такой обработки без всякого промежуточного ПО (ну, кроме ОС, драйверов и т. п. :) ) Вопрос, насколько я понимаю, в том стоит ли их использовать, не лучше ли использовать те же системные вызовы из другого языка. VolCh, 30 сентября 2010 в 22:46
А то и значит. Программа действительно ни чего про это не знает. А вот интерпретатор может быть собран по разному и ЦП с ОЗУ будет потреблять в разных объемах. alekciy, 1 октября 2010 в 22:26
0
DevMan #
Блин, я пишу о том, что слушать сокеты и держать коннект лучше тем, что изначально для этого приспособлено и хорошо справляется с этой задачей, а обрабатывать соединение уже на PHP.
Есть, по-моему, разница между «ничего не знает» и «лучше» :) Вы сами провоцируете «мнение, что PHP — моветон и изначально проигрышен». А насчёт «изначально приспособлено» — чем сервер, написанный на Python или С лучше абсолютно такого же по логике и архитектуре, написанного на PHP? На С хоть скорость компилируемого в нативный код языка даст преимущество, а на python? VolCh, 1 октября 2010 в 08:27
Разумеется есть :) Я не всегда могу донести свою мысль, особенно, когда валяюсь в постели с температурой.
Честно, я люблю php, но не вижу необходимости писать на нём всё (сугубо личное мнение).
Для простого эхо сервера сгодится и на чистом PHP. Для более сложных задач могут быть тормоза, поскольку одномоментно PHP сможет обрабатывать только одно соединение, если не форкать (а при форке могут быть проблемы по памяти). Это всё проверено личным опытом, возможно, у вас получилось более удачно.
DevMan, 1 октября 2010 в 09:13
0
mayhem #
помнится, у пхп проблемы со сборкой мусора и утечками памяти, по этому использовать его для долгоиграющих приложений не особо хорошо
0
divanikus #
Я думаю что проблема в том, что пых не очень параллелится. В *nix можно конечно форкать, а вот под винду только сингл-процесс. Про нити вообще можно забыть. Я сервера на нем не писал, но демона-клиента делал. Нормально все с сетью работает в общем-то.
0
develop7 #
можно, но лучше пишите на чём-нибудь вроде Go, nodejs, erlang ипр.
0
seriyPS #
Не советую потому что:
* Нет тредов
* Нет неблокирующих сокетов (select/kqueue/epool)
т.е. для 1000 одновременных коннектов нужно иметь 1000 форков интерпретатора PHP. Можно использовать пулер вроде dklab.ru/lib/dklab_realplexor/ но это уже не то о чем вы спрашивали.

Если очень хочется — то как минимум использовать phpdaemon. Чисто на socket() трудно будет что то реальное сделать
>Нет неблокирующих сокетов (select/kqueue/epool)

Вроде как есть:
socket_set_nonblock — Sets nonblocking mode for file descriptor fd
socket_select — Runs the select() system call on the given arrays of sockets with a specified timeout
VolCh, 1 октября 2010 в 20:31
Уж ты-ж… Не замечал раньше! Ну это многое меняет))
Хотя отсутствие потоков накладывает некоторые ограничения
seriyPS, 2 октября 2010 в 15:57

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.