phpclub May 28 2015 at 10:59

Асинхронный PHP — миф? Реальность! Видео с DevConf 2014

1 min

13K

DevConf corporate blogPHP*Website development*

Comments 22

john_samilin May 28 2015 at 11:07

Опрос касается асинхронности вообще или конкретно в PHP?

phpclub May 28 2015 at 11:14

Вообще! PHP — как частный случай реализации.

WaveCut May 28 2015 at 11:20

Для PHP это актуальное слабое место, т.ч. спасибо за видео.

Fesor May 28 2015 at 11:51

Следует уточнить что слабое место именно в отсутствии качественных решений для реализации асинхронности. Даже та же работа с базами данных уже проблема. Нативный драйверы для postgresql и mysql в принципе поддерживают асинхронную работу с базой, и при чем довольно давно, но вот PDO этого делать не умеет. С другой стороны намного более проще поднять пул процессов-воркеров, которые работают синхронно, и распределять по ним задачи на обработку запросов с процесса-балансера через какую-нибудь очередь например. Так можно изрядно ускорить систему и при этому не сильно переделывать архитектуру приложения.

WaveCut May 28 2015 at 11:53

Спасибо за комментарий, я все это прекрасно понимаю :)

Fesor May 28 2015 at 12:47

Ну так я не вам конкретно, я хотел мысль раскрыть, что бы впечатлительные люди не кричали потом что-то в духе «PHP не умеет асинхронщину». У людей до сих пор какой-то страх циклических ссылок со времен < 5.3 остался, и PHP у них должен умирать.

WaveCut May 28 2015 at 15:34

Да, я сам до позапрошлого года кричал страшилки о текучести PHP, пока не сел и не проверил все версии линейки 5+. Был приятно удивлен, чему и радуюсь до сих пор в обнимку с демоном, работающим неделями. Если в PHP что-то течет, то это какое-то расширение какого либо внешнего ресурса.

UFO just landed and posted this here

gonzazoid May 28 2015 at 13:50

нет, они все таки сделают из php ноду! :)

kolpeex May 30 2015 at 09:00

Только еще и многопоточность ;)

Fesor May 30 2015 at 09:14

Из коробки многопоточности нет ни в PHP ни в node.js, с другой стороны есть модули добавляющие эту возможность. Да и многопоточность нужна довольно редко, достаточно комбинации из нескольких процессов и event-loop

gonzazoid May 30 2015 at 10:00

ну, в ноде ее нет в принципе, и напильником она не впилится по любому. Можно эмулировать, запуская много нод, но мы то знаем… А вот чего действительно сейчас не хватает php-сообществу (именно не хватает, я не говорю что этого нет в принципе) — это умения общаться :) Мне за этот коммент минусов в карму накидали больше чем в дебатах на религиозные и политические темы. Хорошо хоть обзываться не начали :) Хотя к php я неплохо отношусь, нормальный инструмент, какое то время и на нем сидел. Ну да ладно, это все мелочи.

Fesor May 30 2015 at 10:27

в ноде ее нет в принципе

github.com/audreyt/node-webworker-threads

И это не единственная реализация. Есть и отдельно треды, есть пулы воркеров, есть еще куча других полезных вещей покрывающих 99% всех возможных юзкейсов.

Мне за этот коммент минусов в карму накидали больше чем в дебатах на религиозные и политические темы

Ну это как бы тоже религиозно-политическая тема так сказать :) Да и давайте обсудим ваше утверждение.

сделают из php ноду

PHP и JavaScript довольно разные языки, с разными подходами и т.д. А та фишка ноды из-за которой она стала так популярна — event loop (это пожалуй самый простой способ дать людям простой и эффективный механизм работы с I/O) — не является специфичной штукой для node.js и реализован он был задолго до появления ноды даже в самом PHP (расширения libevent и libev существуют довольно давно).

Вывод, человек пришел и сделал вброс на тему «зачем делать из PHP ноду а не просто взять ноду», при этом даже не обдумав возможные кейсы когда это может понадобиться и в контексте чего. И пошли минусы.

gonzazoid May 30 2015 at 10:39

блин, ну Вы хотя бы себе в зеркале ведь улыбаетесь?

Fesor May 30 2015 at 10:40

Жизнь боль, все тлен

OneArt May 28 2015 at 17:54

Думаю вопрос будет уместен. Сейчас есть идея реализации SOA приложения. И встаёт такая задачка, например пришел заказ от клиента на покупку товара. Нам нужно его оплатить, подразумевается, что оплата это длительный процесс зависящий от третих «лиц» и его нужно выносить в отдельный сервис. Мы делаем отдельный сервис, с очередью для балансировки нагрузки. Но встаёт такой важный момент, информация прошла ли оплата или нет для нас критична. Т.е. пока мы не получим ответ от сервера мы не можем решить что показывать пользователю, прошла ли его покупка или нет.
Как этот вопрос решается правильно с точки зрения архитектуры приложения? Есть идеи или мысли на этот счёт?

P.S. По идеи это должно быть реализовано на уровне эвентов. Т.е. заказ ушел на оплату и всё. Как оплата прошла, срабатывает тригер и все слушатели продолжают делать свою работу, но как это правильно реализовать в приложение? Вешать скрипт до момента ответа? Тогда получается, что толку от асинхронности не будет.