Комментарии 50
Но зачем?
+3
троллейбус_из_хлеба.jpg
+4
Такие штука на несколько порядков быстрее и стабильнее серверов, вроде Nginx. На просторах хабра были где-то статьи на эту тему с бенчмарками, найти правда не могу.
-10
Минусы за то, что нет пруфов подозреваю? Ловите: https://habrahabr.ru/post/220393/
Любая стейтфулл реализация сервера на пыхе будет на порядок быстрее и стабильнее стейлесс серверов. И не из-за того, что пых якобы быстрее сишек, а из-за модели работы. Это очевидно каждому понимающему модель работы пыха в классическом варианте.
-3
Это, мягко говоря, не правда: master процесс в nginx при старте форкает воркеров, которые в асинхронном режиме обрабатывают соединения (по одному воркеру на поток ядра проца).
В вашем же случае, мастер процесс будет обрабатывать соединения, и только потом форкать процессы.
При определенной нагрузке, ядро проца, на котором работает мастер процесс приложения, встанет колом по CPU из-за затраченного времени на переключения контекстов в ядре ос.
Стабильнее и быстрее? Ну-ну.
В вашем же случае, мастер процесс будет обрабатывать соединения, и только потом форкать процессы.
При определенной нагрузке, ядро проца, на котором работает мастер процесс приложения, встанет колом по CPU из-за затраченного времени на переключения контекстов в ядре ос.
Стабильнее и быстрее? Ну-ну.
+6
Сколько перерезал, сколько душ я загубил.
Сколько PHP-серверов многопоточных я убил.
Сколько PHP-серверов многопоточных я убил.
-3
Справедливости ради.
Случай из практики.
Обращается заказчик: Необходимо что-то сделать с php cервером который обрабатывает websocket-соединения.
Сервер кое-как обслуживает 5 подключений, а потом все встает колом внутри него.
Специфика протокола была такова, что клиенты генерировали очень много маленьких сообщений в единицу времени.
PHP-сервер был выкинут, и на его место за 2 часа работы водружено нормальное решение, которое справляется с поставленными задачами до сих пор.
Случай из практики.
Обращается заказчик: Необходимо что-то сделать с php cервером который обрабатывает websocket-соединения.
Сервер кое-как обслуживает 5 подключений, а потом все встает колом внутри него.
Специфика протокола была такова, что клиенты генерировали очень много маленьких сообщений в единицу времени.
PHP-сервер был выкинут, и на его место за 2 часа работы водружено нормальное решение, которое справляется с поставленными задачами до сих пор.
+1
случай из практики: жрет 70мб, обслуживает 10к соединений. :) кто больше?
0
и все же
>> 5 подключений, а потом все встает колом внутри него
очевидно что тут дело совсем не в php. понятно, что интерпретируемый язык со сборщиком мусора по определению не самый производительный. но не до такой степени.
>> 5 подключений, а потом все встает колом внутри него
очевидно что тут дело совсем не в php. понятно, что интерпретируемый язык со сборщиком мусора по определению не самый производительный. но не до такой степени.
0
Все зависит от задачи. PHP великолепен как генератор HTML.
Но делать для него сервера, которые смогли бы обслуживать 10к и больше соединений, я бы не стал.
Всему свой инструмент.
Но делать для него сервера, которые смогли бы обслуживать 10к и больше соединений, я бы не стал.
Всему свой инструмент.
0
У вас устаревший взгляд на PHP
0
Нет, скорее кто знает PHP пихает его везде где можно. Может быть достаточно попробовать другие инструменты? Может быть тогда вы измените свои взляды?
+1
Может быть достаточно попробовать другие инструменты?
В случае с «Сервер кое-как обслуживает 5 подключений» было незнание одного инструмента, потому начали использовать тот, который знали лучше.
К PHP, как всегда, это отношения не имеет.
+1
Нет, скорее кто знает PHP пихает его везде где можно. Может быть достаточно попробовать другие инструменты? Может быть тогда вы измените свои взляды?
По-моему, ровно то же самое можно сказать и тем, «кто знает другие инструменты». :)
Человеку свойственно в первую очередь пользоваться тем инструментом, которым он владеет лучше.
0
Согласен при условии что этот инструмент работает как надо в тех условиях, которые ему уготованы.
0
И это не просто свойственно, это повышает эффективность решения реальных задач. Грубо, на PHP я подниму относительной простой веб-сокет сервер за день, на Node.js — за три дня, на Go или C — за месяц. Примерно в той же пропорции будет и скорость решения возникающих проблем, от багфиксов до изменившихся требований. Естественно, пока их можно решить в рамках выбранного стека.
0
В конкретно данном случае лучше будет работать однопоточный асинхронный сервер
0
НЛО прилетело и опубликовало эту надпись здесь
Зачем?
-2
Как минимум в статье можно подсмотреть пример использования потоков для сложных вычислений или асинхронных действий.
+1
Потоки для сложных вычислений? :) Вы точно правильно понимаете, что такое треды? :)
0
Немного смущает только, что нужно дополнительно в PHP включать потоки.
0
На самом деле потоки в PHP могут пригодиться только в узкоспециализированных приложениях и, я думаю, если это действительно нужно, установить расширение не будет проблемой.
+2
Я бы сказал немного иначе — во многих самостоятельных приложениях используют потоки, мьютесы, семафоры, а еще иногда события и блокировки. Именно из-за предметной области PHP в нем это в диковинку, а в любом другом языке потоки стандартное средство языка. И тут надо ответить себе на вопрос «Почему мне понадобились потоки?». Варианты ответа: 1. я не по назначению использую PHP 2. я не могу взять другой язык с потоками 3. автор реализации не предполагал написания самостоятельных приложений
0
Официальные расширения — стандартное средство языка. PHP — язык программирования общего назначения, у него нет предметной области.
+1
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.
+1
Потоки в php и в придачу еще и под windows. Полный набор…
кстати у нас в компании используется подобный подход :) Правда не под windows.
Дело в том что мы используем RabbitMQ, и что бы не писать всю функциональность заново на другом языке было принято решение писать демон на пхп.
кстати у нас в компании используется подобный подход :) Правда не под windows.
Дело в том что мы используем RabbitMQ, и что бы не писать всю функциональность заново на другом языке было принято решение писать демон на пхп.
0
Многие важные вопросы, такие как, например, обработка ошибок сокетов, опущены.
Так ведь это самое интересное. Вам придется много-много страниц кода написать, пока у вас получится более-менее работающая реализация HTTP, и пока вы сможете начать писать бизнес-логику.
Поэтому соглашусь с предыдущими комментаторами:
Зачем?
+1
У меня две мысли.
1. У меня сервера на Debian, включение thread safety в deb-пакете не предусмотрено (даже если пересобираем пакет с включением thread safety — оно не работает, какой-то из дебиановских патчей ломает), по крайней мере так было два года назад (тогда же пробовал pthreads — сегфолты на каждом шаге). Соответственно это нужно брать голый PHP и собирать из исходников…
2. Никаких серьезных преимуществ у использования тредов перед процессами — нет, после создания сокета можно нафоркать несколько процессов, которые будут принимать соединения. Работать будет ничуть не хуже, но без необходимости включения страшных расширений.
1. У меня сервера на Debian, включение thread safety в deb-пакете не предусмотрено (даже если пересобираем пакет с включением thread safety — оно не работает, какой-то из дебиановских патчей ломает), по крайней мере так было два года назад (тогда же пробовал pthreads — сегфолты на каждом шаге). Соответственно это нужно брать голый PHP и собирать из исходников…
2. Никаких серьезных преимуществ у использования тредов перед процессами — нет, после создания сокета можно нафоркать несколько процессов, которые будут принимать соединения. Работать будет ничуть не хуже, но без необходимости включения страшных расширений.
+2
Ваша вторая мысль очень спорная. Преимущества начинаете понимать когда разберетесь в вопросе и используете и то и другое достаточно хорошо для того что бы «прочувствовать» разницу. Ну это как в Африке знают только один вид снега, а на северном полюсе всего один тип песка, но мы то знаем… снега и песка бывает много разных типов… так и отличий на самом деле огромное количество… взять хотя бы размер стека выделяемого под поток…
0
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Я бы использовал потоки в тяжёлых sql запросах для движка.
0
// при попытке закрытия сокета я получаю ошибку zend_mm_heap currupted, поэтому эту часть в тестовом решении опускаю
//socket_close($this->socket);
Это же segfault, потоки или сокеты?
0
В основном потоке сокет закрывается нормально, во второстепенном — с этой ошибкой. Если поможете победить проблему — буду признателен.
+1
Сначала socket_shutdown, потом уже socket_close ?
0
Нужно взять за правило: не создавать и не убивать ресурсы в потоках.
Можно попробовать следующее:
создать класс и через его статические свойства сообщать основному потоку, что можно закрывать сокет; когда поток отрабатывает, то он переключает соответствующие флажки в этих свойствах, в основном цикле это отслеживается, и сокет-ресурс основным потоком закрывается
Вообще, раньше pthreads не отличался стабильностью, поэтому прибегать к его использованию было не желательно. Если сервер не предполагает использование долгих вычислений, то потоки, как таковые, не нужны, хватает неблокирующих сокетов.
Можно попробовать следующее:
создать класс и через его статические свойства сообщать основному потоку, что можно закрывать сокет; когда поток отрабатывает, то он переключает соответствующие флажки в этих свойствах, в основном цикле это отслеживается, и сокет-ресурс основным потоком закрывается
Вообще, раньше pthreads не отличался стабильностью, поэтому прибегать к его использованию было не желательно. Если сервер не предполагает использование долгих вычислений, то потоки, как таковые, не нужны, хватает неблокирующих сокетов.
0
я лично очень часто использую параллельные вычисления на php. но я просто запуская воркеры в нескольких консолях.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Реализация многопоточного сервера на PHP