Комментарии 50
Но зачем?
троллейбус_из_хлеба.jpg
Такие штука на несколько порядков быстрее и стабильнее серверов, вроде Nginx. На просторах хабра были где-то статьи на эту тему с бенчмарками, найти правда не могу.
Минусы за то, что нет пруфов подозреваю? Ловите: https://habrahabr.ru/post/220393/
Любая стейтфулл реализация сервера на пыхе будет на порядок быстрее и стабильнее стейлесс серверов. И не из-за того, что пых якобы быстрее сишек, а из-за модели работы. Это очевидно каждому понимающему модель работы пыха в классическом варианте.
php-pm имеется ввиду вот это.
другое дело, что над php демоном все равно нужно ставить nginx)
другое дело, что над php демоном все равно нужно ставить nginx)
Это, мягко говоря, не правда: master процесс в nginx при старте форкает воркеров, которые в асинхронном режиме обрабатывают соединения (по одному воркеру на поток ядра проца).
В вашем же случае, мастер процесс будет обрабатывать соединения, и только потом форкать процессы.
При определенной нагрузке, ядро проца, на котором работает мастер процесс приложения, встанет колом по CPU из-за затраченного времени на переключения контекстов в ядре ос.
Стабильнее и быстрее? Ну-ну.
В вашем же случае, мастер процесс будет обрабатывать соединения, и только потом форкать процессы.
При определенной нагрузке, ядро проца, на котором работает мастер процесс приложения, встанет колом по CPU из-за затраченного времени на переключения контекстов в ядре ос.
Стабильнее и быстрее? Ну-ну.
Сколько перерезал, сколько душ я загубил.
Сколько PHP-серверов многопоточных я убил.
Сколько PHP-серверов многопоточных я убил.
Справедливости ради.
Случай из практики.
Обращается заказчик: Необходимо что-то сделать с php cервером который обрабатывает websocket-соединения.
Сервер кое-как обслуживает 5 подключений, а потом все встает колом внутри него.
Специфика протокола была такова, что клиенты генерировали очень много маленьких сообщений в единицу времени.
PHP-сервер был выкинут, и на его место за 2 часа работы водружено нормальное решение, которое справляется с поставленными задачами до сих пор.
Случай из практики.
Обращается заказчик: Необходимо что-то сделать с php cервером который обрабатывает websocket-соединения.
Сервер кое-как обслуживает 5 подключений, а потом все встает колом внутри него.
Специфика протокола была такова, что клиенты генерировали очень много маленьких сообщений в единицу времени.
PHP-сервер был выкинут, и на его место за 2 часа работы водружено нормальное решение, которое справляется с поставленными задачами до сих пор.
случай из практики — нужен был websocket сервер. сделали на Ratchet. жрет 15-30 мб, обслуживает сотню одновременных подключений.
случай из практики: жрет 70мб, обслуживает 10к соединений. :) кто больше?
и все же
>> 5 подключений, а потом все встает колом внутри него
очевидно что тут дело совсем не в php. понятно, что интерпретируемый язык со сборщиком мусора по определению не самый производительный. но не до такой степени.
>> 5 подключений, а потом все встает колом внутри него
очевидно что тут дело совсем не в php. понятно, что интерпретируемый язык со сборщиком мусора по определению не самый производительный. но не до такой степени.
Все зависит от задачи. PHP великолепен как генератор HTML.
Но делать для него сервера, которые смогли бы обслуживать 10к и больше соединений, я бы не стал.
Всему свой инструмент.
Но делать для него сервера, которые смогли бы обслуживать 10к и больше соединений, я бы не стал.
Всему свой инструмент.
У вас устаревший взгляд на PHP
Нет, скорее кто знает PHP пихает его везде где можно. Может быть достаточно попробовать другие инструменты? Может быть тогда вы измените свои взляды?
Может быть достаточно попробовать другие инструменты?
В случае с «Сервер кое-как обслуживает 5 подключений» было незнание одного инструмента, потому начали использовать тот, который знали лучше.
К PHP, как всегда, это отношения не имеет.
Нет, скорее кто знает PHP пихает его везде где можно. Может быть достаточно попробовать другие инструменты? Может быть тогда вы измените свои взляды?
По-моему, ровно то же самое можно сказать и тем, «кто знает другие инструменты». :)
Человеку свойственно в первую очередь пользоваться тем инструментом, которым он владеет лучше.
Согласен при условии что этот инструмент работает как надо в тех условиях, которые ему уготованы.
И это не просто свойственно, это повышает эффективность решения реальных задач. Грубо, на PHP я подниму относительной простой веб-сокет сервер за день, на Node.js — за три дня, на Go или C — за месяц. Примерно в той же пропорции будет и скорость решения возникающих проблем, от багфиксов до изменившихся требований. Естественно, пока их можно решить в рамках выбранного стека.
В конкретно данном случае лучше будет работать однопоточный асинхронный сервер
НЛО прилетело и опубликовало эту надпись здесь
Зачем?
Немного смущает только, что нужно дополнительно в PHP включать потоки.
На самом деле потоки в PHP могут пригодиться только в узкоспециализированных приложениях и, я думаю, если это действительно нужно, установить расширение не будет проблемой.
Я бы сказал немного иначе — во многих самостоятельных приложениях используют потоки, мьютесы, семафоры, а еще иногда события и блокировки. Именно из-за предметной области PHP в нем это в диковинку, а в любом другом языке потоки стандартное средство языка. И тут надо ответить себе на вопрос «Почему мне понадобились потоки?». Варианты ответа: 1. я не по назначению использую PHP 2. я не могу взять другой язык с потоками 3. автор реализации не предполагал написания самостоятельных приложений
Официальные расширения — стандартное средство языка. PHP — язык программирования общего назначения, у него нет предметной области.
1. Официальные расширения — стандартное средство языка
1.1. Открываю документацию и смотрю на список стандартных функций (built-in function) никаких упоминаний о потоках (в основном файлы и строки), а потоки относятся к _расширениям языка_ (PECL Extensions). При дальнейшем чтении становиться ясно, что механизмов расширений в PHP бывает несколько видов и каждое расширение нужно собрать и подключить… _но многие расширения_ уже включены в дистрибутив (но не подключены к языку — в случае с pthreads нужно это сделать самостоятельно). Следовательно это не стандартные средства языка, а расширенные с помощью расширений и нужно добиваться их появления:
Also note that many extensions are enabled by default and that the PHP manual…
Для примера берем потоки в Java и смотрим описание для пакета «java.lang» где находиться класс Thread:
Package «java.lang» provides classes that are fundamental to the design of the Java programming language.
Таким образом в Java потоки относятся к фундаментальному дизайну языка )
2. PHP — язык программирования общего назначения, у него нет предметной области.
2.1. Открываю страницу «Introducing — What is PHP?» и читаю
Although PHP's development is focused on server-side scripting,…
( дальше конечно написано, что если очень нужно, то можно писать и всякое остальное, но это же не «focused» и понятное дело не «common-way», а всякой забавы ради не целевое использование полимеров )
2.2. Открываю FAQ и читаю вопрос «What is PHP?»
PHP is an HTML-embedded scripting language. The goal of the language is to allow web developers to write dynamically generated pages quickly.
1.1. Открываю документацию и смотрю на список стандартных функций (built-in function) никаких упоминаний о потоках (в основном файлы и строки), а потоки относятся к _расширениям языка_ (PECL Extensions). При дальнейшем чтении становиться ясно, что механизмов расширений в PHP бывает несколько видов и каждое расширение нужно собрать и подключить… _но многие расширения_ уже включены в дистрибутив (но не подключены к языку — в случае с pthreads нужно это сделать самостоятельно). Следовательно это не стандартные средства языка, а расширенные с помощью расширений и нужно добиваться их появления:
Also note that many extensions are enabled by default and that the PHP manual…
Для примера берем потоки в Java и смотрим описание для пакета «java.lang» где находиться класс Thread:
Package «java.lang» provides classes that are fundamental to the design of the Java programming language.
Таким образом в Java потоки относятся к фундаментальному дизайну языка )
2. PHP — язык программирования общего назначения, у него нет предметной области.
2.1. Открываю страницу «Introducing — What is PHP?» и читаю
Although PHP's development is focused on server-side scripting,…
( дальше конечно написано, что если очень нужно, то можно писать и всякое остальное, но это же не «focused» и понятное дело не «common-way», а всякой забавы ради не целевое использование полимеров )
2.2. Открываю FAQ и читаю вопрос «What is PHP?»
PHP is an HTML-embedded scripting language. The goal of the language is to allow web developers to write dynamically generated pages quickly.
Потоки в php и в придачу еще и под windows. Полный набор…
кстати у нас в компании используется подобный подход :) Правда не под windows.
Дело в том что мы используем RabbitMQ, и что бы не писать всю функциональность заново на другом языке было принято решение писать демон на пхп.
кстати у нас в компании используется подобный подход :) Правда не под windows.
Дело в том что мы используем RabbitMQ, и что бы не писать всю функциональность заново на другом языке было принято решение писать демон на пхп.
Многие важные вопросы, такие как, например, обработка ошибок сокетов, опущены.
Так ведь это самое интересное. Вам придется много-много страниц кода написать, пока у вас получится более-менее работающая реализация HTTP, и пока вы сможете начать писать бизнес-логику.
Поэтому соглашусь с предыдущими комментаторами:
Зачем?
У меня две мысли.
1. У меня сервера на Debian, включение thread safety в deb-пакете не предусмотрено (даже если пересобираем пакет с включением thread safety — оно не работает, какой-то из дебиановских патчей ломает), по крайней мере так было два года назад (тогда же пробовал pthreads — сегфолты на каждом шаге). Соответственно это нужно брать голый PHP и собирать из исходников…
2. Никаких серьезных преимуществ у использования тредов перед процессами — нет, после создания сокета можно нафоркать несколько процессов, которые будут принимать соединения. Работать будет ничуть не хуже, но без необходимости включения страшных расширений.
1. У меня сервера на Debian, включение thread safety в deb-пакете не предусмотрено (даже если пересобираем пакет с включением thread safety — оно не работает, какой-то из дебиановских патчей ломает), по крайней мере так было два года назад (тогда же пробовал pthreads — сегфолты на каждом шаге). Соответственно это нужно брать голый PHP и собирать из исходников…
2. Никаких серьезных преимуществ у использования тредов перед процессами — нет, после создания сокета можно нафоркать несколько процессов, которые будут принимать соединения. Работать будет ничуть не хуже, но без необходимости включения страшных расширений.
Ваша вторая мысль очень спорная. Преимущества начинаете понимать когда разберетесь в вопросе и используете и то и другое достаточно хорошо для того что бы «прочувствовать» разницу. Ну это как в Африке знают только один вид снега, а на северном полюсе всего один тип песка, но мы то знаем… снега и песка бывает много разных типов… так и отличий на самом деле огромное количество… взять хотя бы размер стека выделяемого под поток…
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Я бы использовал потоки в тяжёлых sql запросах для движка.
// при попытке закрытия сокета я получаю ошибку zend_mm_heap currupted, поэтому эту часть в тестовом решении опускаю
//socket_close($this->socket);
Это же segfault, потоки или сокеты?
В основном потоке сокет закрывается нормально, во второстепенном — с этой ошибкой. Если поможете победить проблему — буду признателен.
Сначала socket_shutdown, потом уже socket_close ?
Нужно взять за правило: не создавать и не убивать ресурсы в потоках.
Можно попробовать следующее:
создать класс и через его статические свойства сообщать основному потоку, что можно закрывать сокет; когда поток отрабатывает, то он переключает соответствующие флажки в этих свойствах, в основном цикле это отслеживается, и сокет-ресурс основным потоком закрывается
Вообще, раньше pthreads не отличался стабильностью, поэтому прибегать к его использованию было не желательно. Если сервер не предполагает использование долгих вычислений, то потоки, как таковые, не нужны, хватает неблокирующих сокетов.
Можно попробовать следующее:
создать класс и через его статические свойства сообщать основному потоку, что можно закрывать сокет; когда поток отрабатывает, то он переключает соответствующие флажки в этих свойствах, в основном цикле это отслеживается, и сокет-ресурс основным потоком закрывается
Вообще, раньше pthreads не отличался стабильностью, поэтому прибегать к его использованию было не желательно. Если сервер не предполагает использование долгих вычислений, то потоки, как таковые, не нужны, хватает неблокирующих сокетов.
я лично очень часто использую параллельные вычисления на php. но я просто запуская воркеры в нескольких консолях.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Реализация многопоточного сервера на PHP