company_banner

Производительность PHP-бэкенда. Видео с Badoo PHP Meetup #3

    Привет! Готовы материалы с Badoo PHP Meetup #3, традиционной неформальной встречи сообщества. Напомню, в этот раз мы обсуждали проблемы производительности бэкенда на PHP и их решение в разных компаниях.  



    Тема нашла моментальный отклик среди почти 200 гостей — на каждом перерыве спикеров окружала толпа с вопросами. Опытом делились Александр Малащицкий из Superjob, Павел Мурзаков pmurzakov из Badoo и Антон Шабовта zloyusr из Onliner, а к панельной дискуссии также присоединились Семён Катаев из Avito и Михаил Буйлов из Mamba.

    Все материалы — под катом, полезного просмотра!

    «Систематизация оптимизации» — Александр Малащицкий, ведущий разработчик команды «Платформа» в Superjob 


    Александр рассказал, как его команда искала и нашла системный подход к поиску и оптимизации проблемных мест. Перечислил свои ошибки и посоветовал, какие метрики учитывать, чтобы процесс стал эффективным.



    Слайды


    «Боремся с shared-nothing моделью: PHP 7.4 preload, RoadRunner и другие» — Павел Мурзаков, Badoo PHP Team Lead 


    Традиционное PHP-приложение (т. е. mod_php, php-fpm и т. п.) каждый раз исполняет весь код с нуля. Это значит, что весь bootstrap приложения происходит заново на каждый запрос. В докладе Павел объяснил, на что тратятся ресурсы, и рассказал, что делать, чтобы минимизировать проблему. 


    Слайды


    «Когда производительности PHP не хватает. Переносим код в C» — Антон Шабовта zloyusr, энтузиаст асинхронного PHP (Onliner)


    Антон описал протокол и особенности реализации RoadRunner, рассказал, как писал драйвер для PHP + RoadRunner на С. Cравнил производительность PHP-FPM, RoadRunner и RoadRunner + C. И проникся корпоративной культурой Badoo.


    Слайды


    Панельная дискуссия о производительности


    Представители Badoo, Avito и Mamba рассказали, как в их компаниях решают проблему производительности PHP: как сформирована экосистема, какие метрики считают главными, как выбирают между оптимизацией и железом и решают другие проблемы.

    Модератор — Владимир Янц vyants.

    Участники:
    Павел Мурзаков, Badoo 
    Семён Катаев, Avito
    Михаил Буйлов, Mamba


    Фотографии митапа уже лежат у нас на Facebook и ВКонтакте. Плейлист митапа целиком — на YouTube-канале. Подписывайтесь, чтобы не пропускать материалы по теме!

    Заходите в наш PHP-чат, где появляются первые анонсы событий и возникают интересные обсуждения. И подписывайтесь на Telegram-канал.

    На этом всё. В следующий раз пригласим пхпшников пообщаться, когда потеплеет. Но если весну вам ждать слишком долго и холодно, присоединяйтесь к дружественному сообществу Beer PHP Moscow, они чаще собираются и греются в пабах.
    • +33
    • 6,6k
    • 6
    Badoo
    338,13
    Big Dating
    Поделиться публикацией

    Комментарии 6

      0
      Добрый день.
      Был участником, но уже после PHP Meetup #3, немного осмыслив что к чему, у меня возник вопрос по RoadRunner, буду благодарен если ответите на него или дадите ссылку где почитать. Спасибо!
      К примеру у нас на сервер идет 1000 обращений в секунду, RoadRunner обслуживает 10 воркеров, время исполнения кода одного воркера 500мс (цифры условные, взяты из головы), т.е. в секунду полноценно обработать можем только 20 запросов. Что происходит с остальными 980 запросами?
      Запросы выстраиваются в очередь в RoadRunner? Или идет переключение контента и один воркер разом может обрабатывать 100 запросов.
      Если идет переключение контента, то возникает много других вопросов. К примеру в какой момент какое состояние будет у исполняемого скрипта? Кто отвечает за переключение контента, диспетчер задач Go или PHP интерпретатор отдает это на откуп операционной системе (правда это уже из области многопоточности и асинхронности)
        +2
        Запросы выстраиваются в очередь в RoadRunner?

        Да, запросы находятся в ожидании. Контекст не переключается что гарантирует что ваш PHP скрипт работает в однопоточном режиме.

          0
          Правильно понимаю, что 1 воркер — это довольно полная аналогия php-fpm?
          Или все же fpm плодит процессы, а воркер RR работает только с одним процессом?
            0
            Наверное Вам ответят еще представители разработчиков RR, у меня пока у самого вопросов хватает, но как понял:
            Если по простому то да, это аналогия, отличие в том, что fpm хранит пул только процессов php, далее идет обычный алгоритм работы PHP (родился -> исполнился -> умер, и так каждый раз). RR же хранит в памяти пул процессов с уже загруженными, интерпретированными и транслированными данными скриптов в байт код. Т.е. весь код уже сидит в памяти (включая открытые ресурсы, подключения к БД, открытые файлы и т.п.), интерпритатору только остается его исполнить (родился -> исполнился -> ожидает следующего обращения к воркеру вися в памяти). НО естественно и написание кода должно быть уже другим, т.к. все инициализированные переменные, все открытые ресурсы, остаются в памяти, т.е. их надо очищать (на ваше усмотрение конечно закрывать ли открытые ресурсы, подключения к БД и т.п.), иначе при следующем обращении к воркеру в них уже будут данные.
            Мои вопросы представителям разработчиков RR:
            1. Корректно ли я описал RR?
            2. Какое количество воркеров рекомендуется создавать т.е. от чего это зависит, на что обращать внимание?
            Спасибо!
              +1

              Привет, описание корректное.


              Количество воркеров зависит напрямую от нагрузки на систему и количество времени который воркер проводит в IO-wait. Т.е. например если ваш ПХП код выполняется без внешних ресурсов за 0.01мс то вам хватит воркеров по количеству ядер. Если же коду требуется что-то записать в сокет/файл и задача уже "зависает" на 10мс то количество воркеров стоит поднимать эмпирически.


              Фактически вся работа по оптимизации кода для roadrunner заключается в выносе тяжелых операций в фон — чтобы не блокировать http воркеры.


              Действительно, при разработке приложения стоит учитывать что все остается в памяти. Но это не такая уж и сложная задача если у вас есть правильно настроенный фреймворк.

              +1

              RR работает с несколькими процессами, разница в том что процессы лучше утилизируются за счет использования RAM по ее прямому назначению.

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

        Самое читаемое