Комментарии 52
А можно показать, что именно делает скрипт?
Показать его, к сожалению, не получится, да и в этом нет большого смысла. С одной стороны, я не могу это сделать, так как пришлось бы выложить большую часть наших исходников, а, с другой стороны, человеку, не знакомому с кодом Badoo и нюансами бизнес-логики и инфраструктуры, всё равно будет сложно понять, что там происходит и зачем это делается.
Что, наверное, может быть важно — в скрипте мы не ходим в базы и внешние хранилища. Он CPU-bound (как я писал выше). Если сильно упростить, то он сводится к тому, что мы получаем большие пачки данных от клиентов, рассериализовываем их, преобразуем в сущности (создаём много объектов разных классов — их может быть несколько десятков на запрос), преобразуем их по-всякому, сериализуем-пакуем и отправляем в LSD.
да и в этом нет большого смысла
Единственное что срезает RoadRunner — это бутстрап. И вот в вашем варианте не ясно, сколько занимала изначально инициализация, а сколько непосредственно работа.
получаем большие пачки данных от клиентов
Network bound? Это всё потенциально даёт флуктации в измерениях, которые сильно искажают результаты тестирования. В этом случае, как мне кажется, будет более уместен hello world.
Там был ещё огромный запас до того, чтобы упереться в сеть — никаких флуктуаций в данном случае от этого не было.
Точную долю на бутстрап назвать сложно (если в середине логики мы троагем какой-то новый класс и выполняется его автолоадинг — это тоже в какой-то степени бутстрап, как и какое-то условное ленивое поднятие конфигов/библиотек, которое может случиться тоже где-то посередине скрипта). За какой-то примерный ориентир можно взять 1/4 времени выполнения скрипта как затраты на бутстрап — примерно такая цифра получается в результате анализа того, что показывают профайлеры.
Не только, он еще срежет время на keep-alive соединения и на коннект с базой.
На CPU-bounded выжать скорость больше чем может дать CPU уже не получится.
Нужно менять сам скрипт: один из вариантов вынести часть вычислений в фон через пакет очередей родраннера, либо переписать самые тормозящие части на го (RPC) оставив остальную бизнес логику. Но это уже более глубокая интеграция.
На CPU-bounded выжать скорость больше чем может дать CPU уже не получится.
С этим сложно спорить. :) Но суть как раз заключается в том, на что именно тратится CPU. В статье я писал, на чём может потенциально помочь сэкономить RoadRunner (подключение файлов, инициализация, кешировние чего-то в памяти и т. д.). Всё это присутствовало в нашем тестовом скрипте, из-за чего и получился выигрыш.
Если 90 процентов жрёт инициализация (вполне реально для какого-то di/sl контейнера без ленивого инстанцирования), то можно выжать на порядок большую скорость.
С другой стороны — никто не оптимизирует программу чтобы собрать все замыкания в условном бустрапе.
На ларавеле возможно нет, но это один из лучших и проверенных способов оптимизации для long-running приложений.
У Yii не так много замыканий. Я запустил Yii 2 и получил ответ за 1-2 мс. А в Yii 3 поддержка RoadRunner и Swoole, вероятно, будет из коробки.
Ну т.е. типичное приложение на php зачастую занимается тем, что добрую половину времени ждет ответа от базы данных и ничего по сути само не делает. Ну увеличили вы на пару процентов инициализацию, но в итоге как висел php-fpm процесс, так и висит, ждет ответа от базы/апи и т.д.
И если будет одновременно 10000 запросов идти, всё упадет, потому что придется держать 10000 воркеров php-fpm одновременно. И даже если переписать это на RoadRunner, ничего не изменится — нужно будет также 10000 воркеров, которые будут ждать ответа от базы данных.
Короче, имхо для хайлоада лучше php всё же не использовать. Ни с RoadRunner ни с preload
Всё это зависит от конкретного приложения: характера того, что оно делает, и степени его "оптимизированности". У нас бОльшую часть времени выполнения клиентского запроса занимает непосредственно работа PHP: все горячие данные лежат в быстрых сервисах (от которых время ответа в пределах единиц милисекунд).
10000 запросов мы выдерживаем без проблем, но если на нас внезапно увеличится траффик в несколько раз, то в первую очередь мы ощутим это именно по CPU, а не по сервисам/базам.
В общем, всё то, что вы говорите — верно, но только для ограниченного набора случаев. Часто бывает по-другому и даже с точностью до наоборот :)
Я не оч. понимаю,
Я тоже не очень понимаю на чем основано ваше мнение? Я вот работал с одним из самых высоконагруженных сайтов в мире и там используется PHP. И в Badoo и в Facebook довольно высокая нагрузка и используется PHP уже много лет.
Вы вот видели хоть один вебсайт на Rust написанный?
Я думаю это будет отличная статья! Я готов на вас даже подписаться, если у вас есть пример сайта с высокой нагрузкой работающий на Rust.
И даже если переписать это на RoadRunner, ничего не изменится
То есть опять, люди — специалисты, потратили время и силы чтобы все протестировать и обосновать, подтвердить все доказательствами и измерениями, написать статью, чтобы поделиться своим мнением, идеями и опытом. Но вам просто все и так понятно — все врут, а вы просто знаете истину (аки бог?) и голословно утверждаете что «ничего не изменится» в ответ на развернутую статью с доказательствами что, и как именно, и почему изменится?
Я тоже не очень понимаю на чем основано ваше мнение?
На опыте и логике
Я работал с хайлоадом на php, но по сути просто потому, что это было легаси, и потому что код писать немного проще. У меня были кейсы, когда всё упиралось именно в проблематику php-fpm. Например, нужно параллельно дернуть бд и несколько API — php не подходит (или нужно жестко костылять). Нужно, чтобы сервера с бд работали чуть дольше чем какой-то минимум, то php не подходит, нужно слишком много воркеров, всё умирает. И т.д.
Если взять Golang, то никаких таких проблем нет. Если взять nodejs, то тоже можно разрулить (но там побольше возни, так как nodejs юзает одно ядро). На расте тоже можно.
специалисты, потратили время и силы чтобы все протестировать и обосновать, подтвердить все доказательствами и измерениями, написать статью, чтобы поделиться своим мнением, идеями и опытом.
Спасибо, что они поделились, было интересно. Я плюсанул статью, если чо. Однако вопрос, почему php, остается открытым. Один воркер php-fpm в один момент времени может обслуживать только один http-запрос. Это накладывает кучу ограничений. Потому что нельзя просто так взять и наплодить 10000 процессов в ОС.
вы просто знаете истину (аки бог?) и голословно утверждаете
я же привел аргументы. Причем тут вообще бог )
Вы вот видели хоть один вебсайт на Rust написанный?
При чем тут, видел, не видел. Rust точно подходит, так как там есть например библиотека tokio, заточенная на такие вещи. По сути аналог зеленым тредам в го
При чем тут, видел, не видел. Rust точно подходит, так как там есть например библиотека tokio, заточенная на такие вещи. По сути аналог зеленым тредам в го
Я попробую объяснить почему " видел, не видел" тут при чем. Во-первых вы его упомянули как альтернативу «неприемлемому» на ваш взгляд PHP. А во-вторых, очень много вещей и теорий выглядящих логично на первый взгляд не выдерживают проверки временем и практикой. Поэтому любые теоретические преимущества очень полезно проверять экспериментально.
Например, в далекие 80-ые было расхожее утверждение что параллельный LPT порт должен быть быстрее чем последовательный COM, поскольку мы передаем данные «одновременно» и пропускная способность должна расти соответственно. Но уже лет через 10-15 стало ясно что по технологическим причинам реализация высокоскоростных последовательных интерфейсов намного проще и на свет появился USB, который развивается и здравствует и по сей день.
Или вот возьмем эту статью, RoadRunner показал себя не лучшим образом при первом запуске. Пришлось покопаться авторам чтобы заставить его принести какую-то пользу. Но, как они написали в заключении, они не собираются пока его ставить в продакшн. (Я бы тоже не поставил). Потому что за все надо платить. И приложение и разработчики должны будут постоянно сверять свой код на предмет «совместимости» с RoadRunner. И к багам и ошибкам самого. кода могут прибавиться какие-то новые баги и ошибки вызванные подобным архитектурным решением.
Насчет Rust, я почти уверен что мы никогда не увидим сколь угодно значимых внедрений
на backend там где активно используется PHP. У PHP есть своя ниша в вебразработке которую он хорошо держит вместе с кучей фрэймворков. Есть хоть один на Rust (ориентированный именно на MVC)? мне кажется максимум что сможет тут предложить Rust это какой-нибудь RESTfull фрэймворк. Хотя поскольку с Rust я не знаком вообще, все же подозреваю что даже слово «фрэймворк» там слабо применимо.
Даже если предположить, что Rust может быть удобен для веба. Пожелание переписать Badoo на Rust не может вызвать ничего кроме улыбки. Я не знаю сколько раз в своей жизни вы переписывали что-то действительно большое и сложное полностью с одного языка и парадигмы на другой язык с другой парадигмой. На практике это АД. Реально это возможно только по кусочкам. Как и делают многие компании, начиная дробить монолиты на микросервисы и уже на уровне микросервиса выбирая технологический стек. Для любого ИТ менеджара-практика, ваше предложение переписать все на Rust как алтьтернатива перейти на PHP 7.4 + RoadRunner далеки друг от друга как небо и земля.
PS: Но я вам даже где-то завидую. Уже много лет я не могу произнести ничего настолько простого как: «При чем тут, видел, не видел. Rust точно подходит, так как там есть например библиотека tokio, заточенная на такие вещи.». Это так просто и так наивно, что даже слова трудно подобрать, чтобы начать возражать. На Марс тоже просто полететь, ведь есть же Роскосмос, заточенный пот такие вещи?
Все что я хочу сказать, что для хайлоада есть более удачные альтернативы, чем PHP, на мой взгляд:
1) Если нужна относительная простота синтаксиса и заточенность языка на конкаренси, то Go. К примеру, как показывает мой личный опыт, не так уж и сложно переучить команду пхп-шников на го.
2) Если нужно выжать все соки производительности, то Rust или C/C++. Полно веб-фреймворков на Rust, если что. Единственный минус — порог входа в язык, но это цена за суперпроизводительность и безопасность по памяти без GC. Смотря что нужно.
3) Есть также удобства в nodejs: все знают язык Javascript, например.
У PHP, кмк, меньше всего преимуществ (именно для хайлоада, сам язык норм). И я написал почему, в предыдущих коментах. Если вы не согласны, аргументируйте.
Теперь про переписывание/непереписывание кода, раз уж зашла речь. Это зависит от бизнеса. Вполне может быть, что и на Раст стоит переписать самые нагруженные части. Если в Badoo крутятся 100500 серверов, то переписав с PHP на Раст можно сэкономить кучу денег. Даже если писать на Раст очень дорого и сложно. И совсем это не наивно. Это зависит от ситуации.
И давайте уже обойдемся без переходов на личности(«так просто и наивно»), а также без неуместных сравнений (Марс, Роскосмос) и без апеллирования к авторитету («специалисты написали статью»). Я предпочитаю конкретные аргументы, и всегда рад оказаться неправым и узнать что-то новое в конструктивной беседе.
не так уж и сложно переучить команду пхп-шников на го.
При условии, что они пишут в стиле PHP3? :) А если серьёзно, то очень сложно переходить, если нет какого-то квалифицированного фидбэка. Пишешь код, он работает, пускай и его в 2 раза больше чем было на PHP хотя бы за счёт if err!=nil через строку, но не понимаешь то ли ты говнокод написал, то ли в мире Go это говнокодом не считается.
Ну так это язык такой. На любителя. ))
Вообще, нужен один тру гошник, который пару лет на го писал, все остальные быстро фишку начинают сечь
Ну вот решили попробовать что-то на Go написать в виде эксперимента что ли, но который в продакшен пойдёт 99% — типа важная инфраструктурная часть, которая должн работать быстро и асинхронно, вроде типовая задача для Go. Нанимать тругошника никто не будет под это, даже пехепешника с Го в бэкграунде. И если среди 5 пехепешников ни у кого опыта с Го нет, то как-то непонятно вообще как оценивать результат: работать работает, заметно быстрее чем PHP. Как работает обычному пехепешнику вроде понятно, даже логику где-то можно изменить относительно быстро. Но вот код выглядит как сборник PHP антипаттернов большей частью. И не понятно, это просто языки настолько разные, или умения готовить Go не хватает
У PHP, кмк, меньше всего преимуществ (именно для хайлоада, сам язык норм). И я написал почему, в предыдущих коментах.
В php давно есть API для выполнения параллельных curl-запросов, запросов в БД, которые можно использовать в стандартном php-fpm. Есть асинхронные фреймворки amphp, ReactPHP, которые правда накладывают ограничения на код (эти ограничения есть и в nodejs и в других языках).
Если в Badoo крутятся 100500 серверов, то переписав с PHP на Раст можно сэкономить кучу денег.
Нужно иметь ввиду, что в проектах с многолетней историей, вроде Badoo, уже написано очень много кода. Поэтому на переписывание этого кода нужно будет потратить кучу (большую) денег на разработчиков, а так же кучу времени, вместо выпуска новых фич. Как уже писали выше, перейти на PHP 7.4 с прелоадом проще. От себя добавлю, что это гораздо дешевле, экономит сервера (пусть в меньшей степени), и самое главное точно окупается.
Так или иначе в баду есть сервисы для которых php не очень подходит, и они написаны не на php.
С JIT те же CPU bound tasks станут быстрее.
Если изначально понятно, что бэкенд будет нагружен, возможно, имеет смысл сразу смотреть в сторону RoadRunner, так как он потенциально может дать ещё больше производительности.
Вероятно в этом случае надо сразу смотреть в сторону более эффективного в highload языка? Кмк PHP пишут в основном из-за того, что прототип будущего highload сервиса был на нем написан и оброс бизнес логикой и в среднем дешевле придумывать обходные пути для текущего решения, чем переписывать на другой язык?
RoadRunner в экспериментах работал с версией PHP 7.4.
RoadRunner фактически запускает скрипт как CLI, т.е. он позволяет делать практически всё, что можно делать в CLI, в том числе использовать preload. Но вот смысла в этом значительно меньше, чем в случае PHP-FPM, mod_php и подобных: в RoadRunner память не очищается между запросами, поэтому все классы, функции и прочие символы нужно загрузить и так только однажды (т.е. тут теряется основной смысл включения preload).
Единственная разница — preload может сделать дополнительные кросс-файловые оптимизации, что не может сделать сам RoadRunner (без дополнительного включения preload). Но это обычно даёт гораздо меньший выигрыш производительности в сравнении с избеганием подключения файлов на каждый запрос.
А используется ди preload для dev/stage? Как там происходит разработка, с учётом требования к restart/reload?
Пробуем preload (PHP 7.4) и RoadRunner