Доклад посвящен асинхронному программированию в PHP, где будут рассмотрены все доступные для разработчика возможности: от самых примитивных до самых высокотехнологичных, о которых вы еще, возможно, не знаете.
Асинхронное программирование весьма интересное направление, за которым будущее в разработке, надо уметь делать работу параллельно, вовремя реагировать на события и масштабироваться.
Ключ к этой асинхронной парадигме будет дан в докладе, где вас будут ожидать: асинхронные вызовы, события, хуки, демоны, процессы, потоки и сопрограммы на PHP5.5
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (22)
WaveCut
28.05.2015 11:20+2Для PHP это актуальное слабое место, т.ч. спасибо за видео.
Fesor
28.05.2015 11:51+3Следует уточнить что слабое место именно в отсутствии качественных решений для реализации асинхронности. Даже та же работа с базами данных уже проблема. Нативный драйверы для postgresql и mysql в принципе поддерживают асинхронную работу с базой, и при чем довольно давно, но вот PDO этого делать не умеет. С другой стороны намного более проще поднять пул процессов-воркеров, которые работают синхронно, и распределять по ним задачи на обработку запросов с процесса-балансера через какую-нибудь очередь например. Так можно изрядно ускорить систему и при этому не сильно переделывать архитектуру приложения.
WaveCut
28.05.2015 11:53Спасибо за комментарий, я все это прекрасно понимаю :)
Fesor
28.05.2015 12:47Ну так я не вам конкретно, я хотел мысль раскрыть, что бы впечатлительные люди не кричали потом что-то в духе «PHP не умеет асинхронщину». У людей до сих пор какой-то страх циклических ссылок со времен < 5.3 остался, и PHP у них должен умирать.
WaveCut
28.05.2015 15:34Да, я сам до позапрошлого года кричал страшилки о текучести PHP, пока не сел и не проверил все версии линейки 5+. Был приятно удивлен, чему и радуюсь до сих пор в обнимку с демоном, работающим неделями. Если в PHP что-то течет, то это какое-то расширение какого либо внешнего ресурса.
gonzazoid
28.05.2015 13:50-7нет, они все таки сделают из php ноду! :)
kolpeex
30.05.2015 09:00Только еще и многопоточность ;)
Fesor
30.05.2015 09:14Из коробки многопоточности нет ни в PHP ни в node.js, с другой стороны есть модули добавляющие эту возможность. Да и многопоточность нужна довольно редко, достаточно комбинации из нескольких процессов и event-loop
gonzazoid
30.05.2015 10:00ну, в ноде ее нет в принципе, и напильником она не впилится по любому. Можно эмулировать, запуская много нод, но мы то знаем… А вот чего действительно сейчас не хватает php-сообществу (именно не хватает, я не говорю что этого нет в принципе) — это умения общаться :) Мне за этот коммент минусов в карму накидали больше чем в дебатах на религиозные и политические темы. Хорошо хоть обзываться не начали :) Хотя к php я неплохо отношусь, нормальный инструмент, какое то время и на нем сидел. Ну да ладно, это все мелочи.
Fesor
30.05.2015 10:27в ноде ее нет в принципе
github.com/audreyt/node-webworker-threads
И это не единственная реализация. Есть и отдельно треды, есть пулы воркеров, есть еще куча других полезных вещей покрывающих 99% всех возможных юзкейсов.
Мне за этот коммент минусов в карму накидали больше чем в дебатах на религиозные и политические темы
Ну это как бы тоже религиозно-политическая тема так сказать :) Да и давайте обсудим ваше утверждение.
сделают из php ноду
PHP и JavaScript довольно разные языки, с разными подходами и т.д. А та фишка ноды из-за которой она стала так популярна — event loop (это пожалуй самый простой способ дать людям простой и эффективный механизм работы с I/O) — не является специфичной штукой для node.js и реализован он был задолго до появления ноды даже в самом PHP (расширения libevent и libev существуют довольно давно).
Вывод, человек пришел и сделал вброс на тему «зачем делать из PHP ноду а не просто взять ноду», при этом даже не обдумав возможные кейсы когда это может понадобиться и в контексте чего. И пошли минусы.
OneArt
28.05.2015 17:54Думаю вопрос будет уместен. Сейчас есть идея реализации SOA приложения. И встаёт такая задачка, например пришел заказ от клиента на покупку товара. Нам нужно его оплатить, подразумевается, что оплата это длительный процесс зависящий от третих «лиц» и его нужно выносить в отдельный сервис. Мы делаем отдельный сервис, с очередью для балансировки нагрузки. Но встаёт такой важный момент, информация прошла ли оплата или нет для нас критична. Т.е. пока мы не получим ответ от сервера мы не можем решить что показывать пользователю, прошла ли его покупка или нет.
Как этот вопрос решается правильно с точки зрения архитектуры приложения? Есть идеи или мысли на этот счёт?
P.S. По идеи это должно быть реализовано на уровне эвентов. Т.е. заказ ушел на оплату и всё. Как оплата прошла, срабатывает тригер и все слушатели продолжают делать свою работу, но как это правильно реализовать в приложение? Вешать скрипт до момента ответа? Тогда получается, что толку от асинхронности не будет.
Fedot
28.05.2015 19:17+1Если идёт как-то длительная операция, то пользователю нужно показывать что идёт процесс обработки. И когда процесс завершится показать ему результат.
john_samilin
Опрос касается асинхронности вообще или конкретно в PHP?
phpclub Автор
Вообще! PHP — как частный случай реализации.