Как стать автором
Обновить
79
0
Pavel Murzakov @pmurzakov

Engineering manager

Отправить сообщение

В случае если узкое место приложения — CPU, асинхронные фреймворки ничем не выигрывают, а даже наоборот вредят (из-за издержек на асинхронность). При этом код и отладка с ними становятся сложнее.


Если у вас иная ситуация, например, ваше приложение бОльшую часть времени проводит в ожидании чего-либо (например, сетевого взаимодействия) и по каким-то причинам вас перестала устраивать синхронная модель (например, у вас одновременно открыто огромное количество постоянных соединений => уже поставили очередной десяток серверов из-за нехватки памяти и большого количества процессов, а CPU у всех простаивает), то возможно вам имеет смысл задуматься над асинхронными фреймворками.
У нас ситуация абсолютно противоположная, поэтому для нас это не имеет смысла.

Да, ты прав, оказывается, что он сейчас делает reload на каждый деплой патча. (хотя мог бы делать это только в случае изменения тех файлов, которые были загружены в родительском процессе до первого fork, в противном случае reload — лишний)


Но "рестартовать" — достаточно громкое название для этого процесса: там делается pcntl_exec(), который суть execve(), поэтому мы не сталкиваемся с теми проблемами, о которых ты говоришь.


Полноценный рестарт происходит крайне редко. Это нештатная ситуация.

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

Если только не считать то, что Soft Mocks сами(и частично работу с ними) пришлось править под 7.4 :)

В этой статье я рассказывал про наши эксперименты. Если коротко, то на тестовом эндпоинте PHP 7.4 давал +10% в сравнении с PHP 7.2, включение preload давало ещё +10% сверху.
Сколько будет в реальности — узнаем, когда перейдём, и, возможно, поделимся результатами, если они будут интересные. :)

Да, но фактически это время просто перенесётся из периода обработки скрипта в фазу прелоада. Общее суммарное время старта не изменится.

RoadRunner в экспериментах работал с версией PHP 7.4.


RoadRunner фактически запускает скрипт как CLI, т.е. он позволяет делать практически всё, что можно делать в CLI, в том числе использовать preload. Но вот смысла в этом значительно меньше, чем в случае PHP-FPM, mod_php и подобных: в RoadRunner память не очищается между запросами, поэтому все классы, функции и прочие символы нужно загрузить и так только однажды (т.е. тут теряется основной смысл включения preload).
Единственная разница — preload может сделать дополнительные кросс-файловые оптимизации, что не может сделать сам RoadRunner (без дополнительного включения preload). Но это обычно даёт гораздо меньший выигрыш производительности в сравнении с избеганием подключения файлов на каждый запрос.

И есть текстовая версия на Хабре, если не хочется смотреть видео: https://habr.com/ru/company/badoo/blog/417399/

Всё это зависит от конкретного приложения: характера того, что оно делает, и степени его "оптимизированности". У нас бОльшую часть времени выполнения клиентского запроса занимает непосредственно работа PHP: все горячие данные лежат в быстрых сервисах (от которых время ответа в пределах единиц милисекунд).
10000 запросов мы выдерживаем без проблем, но если на нас внезапно увеличится траффик в несколько раз, то в первую очередь мы ощутим это именно по CPU, а не по сервисам/базам.


В общем, всё то, что вы говорите — верно, но только для ограниченного набора случаев. Часто бывает по-другому и даже с точностью до наоборот :)

Там был ещё огромный запас до того, чтобы упереться в сеть — никаких флуктуаций в данном случае от этого не было.
Точную долю на бутстрап назвать сложно (если в середине логики мы троагем какой-то новый класс и выполняется его автолоадинг — это тоже в какой-то степени бутстрап, как и какое-то условное ленивое поднятие конфигов/библиотек, которое может случиться тоже где-то посередине скрипта). За какой-то примерный ориентир можно взять 1/4 времени выполнения скрипта как затраты на бутстрап — примерно такая цифра получается в результате анализа того, что показывают профайлеры.

На CPU-bounded выжать скорость больше чем может дать CPU уже не получится.

С этим сложно спорить. :) Но суть как раз заключается в том, на что именно тратится CPU. В статье я писал, на чём может потенциально помочь сэкономить RoadRunner (подключение файлов, инициализация, кешировние чего-то в памяти и т. д.). Всё это присутствовало в нашем тестовом скрипте, из-за чего и получился выигрыш.

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


Что, наверное, может быть важно — в скрипте мы не ходим в базы и внешние хранилища. Он CPU-bound (как я писал выше). Если сильно упростить, то он сводится к тому, что мы получаем большие пачки данных от клиентов, рассериализовываем их, преобразуем в сущности (создаём много объектов разных классов — их может быть несколько десятков на запрос), преобразуем их по-всякому, сериализуем-пакуем и отправляем в LSD.

Условия — утилизировать железо, fpm не утилизировал. Разные подходы — разные настройки

Поддерживаю. Бенчмарк, имеющий условие, что какая-то настройка (у всех значащая разное) равна двум, не имеет смысла.


mrsuh может быть добавите правильно настроенный PHP-FPM к результатам?

Приветствуем создателя RoadRunner и соавтора оригинальной статьи — Lachezis

На Яндексе тоже появилась страница о том, что перенесены ящики с qip.ru: https://yandex.ru/support/mail/qip.html
Но для моего ящика Яндекс всё так же пишет "Такой логин не подойдет", хотя домен и есть в официальном списке.

Вот тут то, что исползуем мы: https://github.com/tony2001/xhprof/tree/badoo-7.0
Есть другие форки для PHP >=7.0 и даже в официальном репозитории есть экспериментальная ветка, но не могу сказать, насколько они хорошо работают.

  1. php-cgi (в контексте этой статьи) — это название воркеров PHP-FPM.
  2. У нас нет нейронок и компьютерного зрения на PHP. Из PHP мы используем более "классические" варианты ML. Если как-то попытаться обобщить все задачи, то по сути они сводятся к тому, чтобы иметь какое-то предсказание и в зависимости от этого что-то разное пользователю показывать или предлагать.

Сейчас это в основном xgboost-php, но есть кое-что и на основе sklearn.

RoadRunner не пробовали.
У нас есть места, на которых подобный инструмент может дать прирост и на которых не сложно поэкспериментировать, — возможно в ближайшем будущем попробуем.


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

Да, мы используем обученные модели из PHP.
Благодаря Pinba за их потреблением легко следить — сейчас это сотые доли процента кластера.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность