PHP асинхронность, многопоточность, параллельность

Ну там вроде модуль parallel на замену пришел, но я его не тестировал. К тому времени уже активно подсев на Golang.

А с помощью pthreads в свое время сократил выполнение с баш скриптов (30-40с) до 3 секунд на PHP в потоках, а потом до 500 мс переписав код на Golang. Можно еще в сторону rust посмотреть, но топик ведь не о том :)

Таких инструментов же уже вагон и маленькая тележка:

- swoole
- reactphp
- workerman
- amphp
- roadrunner (app server)

Это то что я знаю, тестил и живее всех живых. Но писать асинхронный код в php идея не очень благодарная, большинство драйверов блокирующие, надо писать а потом поддерживать обертки неблокирующие, большая часть библиотек написана в той парадигме что после запроса все чистится и в 98% случаев сторонних либ потечет память..... в целом это узкий инструмент достаточно, например чтоб реализовать свой сокет сервер и то если прям очень нужно, а то лучше на голанг все таки глянуть или на крайний случай на ноду

В питоне использование потоков довольно специфично из-за наличия GIL, а вот использованеи процессов дает толк. Конечно если это многоядерный проц. Например добавление 10000 записей в базу в 4 потока сокращает время с 77 сек до 17 примерно.

я для таких задач использую очереди, без всех этих встроенных сомнительных многопоточных библиотек. Просто пишу демона обработчика на пхп, запускаю его через системд в нужном количестве экземпляр а они в свою очередь являются консьюмерами =)) не совсем понимаю зачем для такой задачи многопоточность в языке =))

Но вот на го у меня есть сервер tcp который принимает подключения от IoT и там мне нужна многопоточность так как эти соединения постоянные с передачей данных в обе стороны =)) в общем все зависит от специфики, но сделать большой энтерпрайз (монолит) на пхп проще чем на го =))

Для вебсокет-сервера использовали в своё время (лет 5 назад) https://github.com/ratchetphp/Ratchet , кажется, поверх reactPHP написан. Пришлось, правда, копнуться поглубже, так как в лоб текла память, но когда понял логику, то исправил ошибку у нас в коде (деталей уже не помню, кажется, реальность и документация отличались) и проект заработал.  Через некоторое время проект задвинулся на задний план и я о нём призабыл. Через какое-то длительное время (может через несколько месяцев, если не через полгода) решил зайти глянуть, что там - все ок, утечек не было, сам вебсокет-сервер работал. Из одного источника, если мне память не изменяет данные получались.  С другого - нет, но там чисто программно нужно было что-то типа сессии перезапускать раз в несколько дней, то есть, это не  проблема ни php, ни его ассинхронности, а чисто организационный вопрос. 

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

Для вебсокетов я использую центрифугу не используя какие то велосипеды =))

Сообщество пока не готово =)) Другая парадигма, мало готовых библиотек, а те что есть могут вполне себе не поддерживаться и иметь кучу багов (open source во всей красе). В целом как оказалось, асинхронность в пхп нужна только тогда, когда у вас уже есть php разрабы и узкая задача под это, в остальных случаях, вот мое мнение и мнение наверное большинства, запилить на Go. Язык простой, кодить продакшен реди код можно буквально за выходные (если ты конечно Senor XXX). При том там "настоящая" многопоточность с горутинами. Я раньше так себе относился к Go, но теперь пилю на нем многие вещи и заказчикам и себе компонуя его с php, так как сейчас большая часть проектов это "api first" проекты. Хотя за проектами асинхронности в php пристально слежу, ведь я люблю php не зависимо от того что у меня большой достаточно стэк.

А есть примеры

Т.е, скрипт отработал за 0.62932, тогда как время затраченное на доставку 2 документов с этой темы составило 1.22971

0.625237226486206
PHP асинхронность, многопоточность, параллельность - Веб-строительство - Сайтостроение - Форум об интернет-маркетинге
https://searchengines.guru/ru/forum/1074587/page1
0.6044747829437256
PHP асинхронность, многопоточность, параллельность - Веб-строительство - Сайтостроение - Форум об интернет-маркетинге - Страница 2
https://searchengines.guru/ru/forum/1074587/page2

Посмотрите в сторону SSE:

Разрабатывать web-приложения, использующие Server-Sent Events намного проще, чем с использованием websockets. Нужно всего лишь немного кода на стороне сервера, чтобы переправлять события web-приложению, но клиентская часть кода для обработки этих событий работает почти точно так же, как и для любых других событий.

Песочница

Ну, мне тогда нужно было бы, чтобы программеру было меньше разбираться. То есть, PHP был первым вариантом выбора + нужно было с реактом (который JS, а не reactPHP) разобраться, потому что сторонняя библиотека, которую я решил использовать в проекте, был на нём написана. И чтобы я мог подключаться время от времени не тратя время на изучения нового. :)

Подскажите, что какую мысль вы хотите донести, суммируя время доставки двух страниц?