Хабрахабр

Анонс митапа, плавно переходящего в BeerPHP дринкап (в Москве и онлайне)

Привет, в августе мы проведем в Москве митап с докладчиками из других городов, встречей BeerPHP и трансляцией официальной части для всех, кто не сможет присоединиться.

Сергей Жук приедет на митап из Брянска — в его городе нет тусовки, а ему есть что рассказать об асинхронном PHP: он написал об этом книги, серию статей и не только. Сегодня начинаем представлять докладчиков. Ниже — расшифровка недавнего подкаста об этом, ссылки на прослушивание и просмотр выпуска, а также детали о самом митапе.

Сергей, недавно я заходил на сайт reactphp.org и обнаружил тебя на главной странице. Пётр Мязин aka PQR: Сегодня со мной на связи один из главных знатоков ReactPHP. Расскажи, как ты к этому пришел, что тебя зацепило в ReactPHP?
Ты достаточно много пишешь по теме, у тебя даже есть свой канал с видеороликами-инструкциями.

По сути, ты заново для себя открываешь язык, на котором уже пишешь много лет

Сергей aka seregazhuk: Два года назад, еще на предыдущей работе, нужно было написать скрипт, который постоянно бы обзванивал клиентов и работал очень быстро. Задачу надо было выполнить “еще вчера”, в команде были только PHP-разработчики, — времени на новый стек, сами понимаете, не было. Но так вышло, что все что-то слышали про ReactPHP. Он позиционировал себя как production-ready, все было очень легко: мы просто устанавливали company через composer, и можно было писать асинхронный код. В итоге написали решение на нем, запустили, все остались довольны.

В итоге я написал пару статей в своем блоге, получил положительный фидбек, и все — это как-то затянуло меня. Я понял, что инструмент-то у нас есть — но каких-то статей, практических примеров вроде «У нас есть такая проблема, мы ее решали вот так» ни на русском, ни на английском почти не было. Мы привыкли к модели Request- Response, но стоит погрузить в асинхронный код, и ты сразу спросишь: «А так можно было?».

Когда мы ждем ответа от них, наш процессор простаивает — вместо того, чтобы заняться чем-то полезным. Пётр: Давай еще раз проговорим, какую проблему для нас решает асинхронный код, и зачем нужен ReactPHP в частности?

Сергей: Почти в каждом приложении есть либо вызовы API, либо взаимодействие с файловой системой, либо запросы к базе. Возникает вопрос: «Если мы везде для ввода-вывода поюзаем ReactPHP, то наши приложения станут в разы быстрее?» Можно не ждать ответа, а стартовать неблокирующие операции и двигаться дальше.

К сожалению, нельзя просто так взять и переписать наши приложения на асинхронные

Это Сергей Жук

Сережа — автор книг ReactPHP For Beginners, Learning Event-Driven PHP With ReactPHP и PHP OOP Way и кучи других полезностей

Сергей: Я бы задумался об использовании ReactPHP в тех случаях, где производительность критична, а ввод-вывод— это наш боттлнэк, который все блокирует. Более того, я бы порекомендовал не переносить все приложение на асинхронные рельсы, а именно переписать этот конкретный боттлнэк. Как правило, асинхронный кусочек гораздо легче вставить в традиционный блокирующий код, нежели пытаться переписать полностью все приложение.

Этот простаивает, зато соседний занимается делом. Пётр: Ок, но почему бы нам тогда просто не запустить несколько PHP-процессов?

Допустим, нам надо получить данные из трех источников, мы делаем вызовы к трем API, потом компонуем результаты и отдаем пользователю. Сергей: А как нам тогда координировать результаты? Если мы сделаем три отдельных потока, то возникнет проблема координации результата.

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

У меня в голове крутилась такая мысль: если мы хотим увеличить число пользователей. Пётр: Я понял. обрабатываемых в секунду, как бы весь стек приложения из Symfony запустить в асинхронном варианте и обработать большее количество коннекшенов?

Зачастую же приложение не тормозит прям целиком. Сергей: Я бы так не делал. И вот уже эти узкие места я бы переводил на ReactPHP. Если встает вопрос производительности, скорее всего, внутри есть пара узких мест, которые тоже, скорее всего, выливаются в медленный ввод-вывод.

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

А если мы сравним это все с NodeJS и другими?

Слева - Петр Мязин, ведущий Пятиминутки PHP

Если есть тема для нового подкаста, будет рад обсудить
он будет на митапе и собирался заскочить на афтепати.

Все запросы к базе, к файловой системе — они все асинхронны внутри. Пётр: А если мы сравним это все с NodeJS, допустим, или Go, там ведь действительно асинхронность через все приложение проходит. Значит ли это, в принципе, если все написать в асинхронном виде, получается какой-то профит?

Тогда да, мы ее решим. Сергей: Профит будет, если изначально проблема в вводе-выводе. Но если изначально проблема не в вводе-выводе, то написав все асинхронно, мы вряд ли что-то выиграем, и можем получить сложный код, который тяжело будет и читать, и поддерживать. Наш код будет максимально работоспособен, сможет обработать максимальное количество задач вместо того, чтобы простаивать и ждать, пока вот этот вот вывод обработается.

Значит, у нас есть ReactPHP, а из знаменитых аналогов Swoole, Amp и Ext-async. Пётр: Возвращаемся к PHP. То есть мы ставим нужные компоненты через composer и готово. А расскажи в сравнении, в чем разница между этими проектами, и насколько ReactPHP хорош, быстр и есть ли у него какие-то недостатки по сравнению с тем же самым Swoole?

Сергей: Из всех троих, если честно, я щупал только Amp, и потому, что он, как и ReactPHP, поддерживается сразу из коробки. Потому что если мы остаемся наедине с PHP и асинхронностью, то, мне кажется, более разумно использовать язык и нативные вещи — а если мы используем дополнительные расширения, то здесь уже не особо асинхронный PHP, а асинхронные расширения для PHP. И здесь мне не очень нравится историям с расширениями.

Насколько ReactPHP реально production-ready?

Пётр: У них на сайте написано “long-term support”. То есть некая долговременная поддержка, без критических изменений API. Все так? Все достаточно качественно?

Сам проект ReactPHP уже достаточно взрослый. Сергей: Да. Он уже достаточное время production-ready. Он с двенадцатого года работает, получается ему же 7 лет. То есть можно смело завязываться на эти компоненты, получать фиксы, обновления и не волноваться об обратной совместимости. И да, более того, вот появился long-term support для основных компонентов на 2 года. Это, я считаю, прям реально круто, это большой такой шаг вперед. Два года они обязуются поддерживать свои версии, ничего не сломается. Насколько я помню, еще недавно Amp некоторые свои компоненты обсуждали, они не до конца определились с интерфейсом и со своим публичным API.

Кроме официальной документации и твоих видеоуроков, конечно. Пётр: С чего рекомендуешь начать изучение ReactPHP? Где все комьюнити, есть ли какие-то телеграмм-чаты или дискорд-чаты, форумы?

Есть аккаунт в твиттере достаточно активный: там можно спрашивать, задавать вопросы и интересоваться. Сергей: К сожалению, не знаю таких вот таких прям комьюнити. Я так делал, спрашивал у них какие-то вещи. И майнтейнеры достаточно оперативно отвечают — можно в твиттере им лично написать.

Ты там будешь выступать, верно? Пётр: Ну что, спасибо тебе за такой подробный рассказ о ReactPHP — и в связи с этим проанонсирую Panda Meetup, который пройдет 22 августа в Москве в офисе Skyeng.

Приходите, пообщаемся. Сергей: Да, все верно.

Пётр: Также там будет еще доклад про Domain Driven Design, что тоже классная интересная тема в контексте PHP, [и еще добавилась парочка других] и как мне сказали организаторы — будет некая афтепати.

Полезности:

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть