Комментарии 25
«Сайт тормозит, 20 мегабайт js’а, грузится 2 минуты»
Да вот сайт-то как раз не тормозит и всегда радовал своей производительностью, разве что последний дизайн стал слишком округлым и стрёмным, а вот приложение... по крайней мере для Android это убожество, куда ни глянь.
ну хз, у меня вк на компе грузится несколько секунд. интерфейс тормозной донельзя. чтобы куда-то добраться, нужно кучу кнопочек понажимать на ощупь, интуитивно пытаясь протискиваться через кучу хлама. раньше всё было намного быстрее, проще и не отжирало кучу места бесполезной информацией. чего только стоит один лишь фон аватарки на полэкрана. а в разделе музыки на вкладке моя музыка видна только одна песенка, самая первая в самом низу экрана, вот там и начинается мой главный плейлист. а весь остальной экран занят барахлом. они там все поголовно наверное уже давно переехали на 8к мониторы, 13900к, ртх4090, 500 гигабит и им норм, у них всё быстро летает и грузится.
Первые экраны (я про десктопную версию) отображается шустро, на самом деле. Но начинаешь листать ленту в каком-нибудь сообществе и после пары десятков постов начинается 'черт знает што'. Браузер - свежий хром, памяти свободной полно, загрузка процессора не вызывает опасений, а то кнопки нажимаются не те (хотел запустить трек, а выскочили эти кривляющиеся смайлы), то срабатывают только после нескольких кликов, то подгрузка тормозит. Справедливости ради, такая же ерунда при прокрутке нескольких экранов комментов к видео на ютюбе. Похоже эти бесконечные ленты новостей так реализованы.
да, приложение стало загружаться очень долго на Android
Нескромный вопрос: планируете ли отрезать пуповину (и когда)?: Объявить kphp и иже с ним отдельным языком, похожим на php.
Судя по тому, что функционал языка ограничивается с одной стороны и планируются добавлять "нестандартный" функционал (поправьте, если ошибаюсь) с другой, то такое решение просто напрашивается.
Конечно, программисты и коммюнити могут посмотреть на это странно. С другой стороны, примеры отпочковывания языков есть, это создаёт отдельную нишу. В любом случае текущий функционал решает очень важную задачу ускорения вычислений (а это сейчас очень актуально) - поэтому может "взлететь".
оставляя plain PHP как интерпретируемый способ разработки на KPHP
Видимо, таких планов пока нет
"Планируете ли отрезать пуповину?" — этот вопрос выглядит скромным, а вот "и когда?" уже и правда нет :D
Ох, сколько же раз я над этим думал — и до сих пор не нахожу правильного ответа.
Естественно, как инженера, меня максимально завораживает перспектива отпочковаться от PHP, забить на обратную совместимость и уехать в отдельный язык — а там уже творить, что хочу: и синтаксис клёвый, и дженерики нативные, и типы нормальные сделать, и прочее.
Но правильно ли это? Интерпретируемая разработка на PHP — это очень удобно для бэкендеров. Максимально быстрое прототипирование: залил файл на сервер, F5, и готово. Плюс, используем привычные инструменты: пройтись по шагам в xdebug, прогнать тесты на PHPUnit, всякие там моки и рефлексия, всё это во время разработки — а KPHP это не поддерживает и не должен. Он для продакшена.
Если отпочковываться — это как? Уходить от интерпретируемой разработки, заставляя бэкендеров после каждого изменения компилировать гигантский бинарь? Слишком долго, все взвоют. Сделать свой модный форк PHP, тоже интерпретируемый? Но сразу же разойдёмся и законфликнуем с основной версией. Да и любой язык — это далеко не синтаксис, это прежде всего экосистема вокруг. А дебаггер? А тесты? А написание кода в IDE, причём в разных? А подсветка в гитхабе/гитлабе? Уйма примеров. И всё это нужно делать? И поддерживать? Здесь bus factor не то что единичка, по-моему он отрицательный будет )
(если интересно, в [другой социальной сети] Hack'ом занимается отдел более чем из 50-ти человек, уже 10 лет)
В общем, вот такие примерно соображения. Так что — я не знаю, в какую сторону качнуть этот trade-off :)
Добавлять нестандартный функционал можно, почему нет? А вот исходный необходимо поддерживать, чтобы можно было переходить.
Но тогда в vk всё равно придётся на исходном php писать, да и почти везде. Откуда возьмётся мотивация для отпочкования?
У них не получится поддерживать исходный функционал. Если почитать предыдущие статьи, то на php код накладывается ряд ограничений:
строгая типизация
нельзя обращаться к полям по имени или вызывать так методы
и список можно продолжить.
Поэтому php для kphp это не только нестандартный функционал, но и сужение стандартного. В общем, напрашивается новый язык.
Большое вам спасибо за развернутую статью и интересные наработки полезные вне VK.
Мы называем это job-воркерами. Ими удалось откусить 10–15% времени ответов API (которые через полгода обратно съелись продуктовым кодом, как оно всегда и бывает).
Ключевая фраза.
Оптимизации на низком уровне это круто.
А вот на других уровнях, где можно получить эффект не в полтора-два раза, а на порядок, безнадёжная обычность (ссылка не по технической теме и может вызвать противоречивые чувства, скорее всего лучше по ней не кликать).
Всё правильно. Не поспорить. Это эффект любых enterprise'ов и корпораций.
Пока команда маленькая, знания хорошо пошарены и каждый представляет примерно весь проект — есть возможность всё контролировать. Как только начинают выделяться отдельные команды, юниты, иерархия, области ответственности, противоречивые KPI — начинается нагромождение, абстракции, перекладывания данных. И микросервисы в кубере конечно же давайте затащим!!! Но это уже личное :D
Это везде так. Я не знаю, что с этим делать. В моих силах лишь максимально долго сохранять порядок на низком уровне. И пока это получается хорошо.
Оптимизации на низком уровне это круто.
Оптимизации на низком уровне часто позволяют создавать эффективные фундаментальные блоки. Например, какие-нибудь библиотеки, производительность которых важна для работы систем. Если сам язык не позволяет такую написать на нём же, то придётся в случае PHP писать расширения. Для таких библиотек эффективные низкоуровневые оптимизации могут давать прирост выше, чем 10-15%.
KPHP интересен тем, что он позволяет многие такие фундаментальные вещи писать на самом же PHP и они будут приемлемы по производительности. Задача компилятора тут дать нужные оптимизации и распознавать идиомы.
Зато теперь KPHP поддерживает и NUMA, и CPU affinity, и множественные сокет-бэклоги, а nginx отстреливает бэкенды по-другому.
- Что такое множественные сокет-бэклоги?
- Что тут имеется ввиду под CPU affinity? Один входящий запрос в приложение всегда обрабатывается одним и тем же ядром, или что-то другое?
Под множественными имелось в виду просто несколько серверных сокетов, у каждого из которых свой backlog. Путем многочисленных экспериментов выяснили, что в случае с двумя сокетами, причем на разных портах, можем держать больший RPS без деградации, чем с одним. Пробовали разные варианты: и
SO_REUSEPORTна 2 сокета + fork n раз, и отдельный listen сокет в каждом воркере сSO_REUSEPORT, и еще много всяких. Резльутат один: 2 слушающих сокета на разных портах выигрывают. Скорее всего причина тому -- contention в ядре на слушающий сокет на accept'е.Напомню, что в KPHP prefork сервер, то есть много воркер процессов которые обрабатывают запросы. Под CPU affinity имелось в виду прибивание этих воркер процессов к ядрам. Более точно - к наборам ядер, соответвующих конкретной NUMA ноде. Еще из подобных оптимизаций решили сделать прибитие проксей к NUMA нодам, чтобы каждый воркер взаимодействовал с проксей со "своей" ноды. В совокупности это все позволило выиграть несколько процентов CPU.
Я же правильно понимаю, что KPHP транслируется в C++? А зачем это вообще требуется, почему сразу не C++ (возможно я упустил часть статей, тогда прошу прислать ссылку)?
Отвечу за автора.
Потому что есть 8 миллионов строк кода на PHP и тысяча php-разработчиков.
Ключевое, как я писал про наш опыт миграции, быстрая проверка - быстрое исполнение.
PHP даёт быструю проверку. После сборки - быстрое исполнение. Также часть абстракций C++ уходит в DSL на PHP и с ними проще работать. Мы думали о переходе в одну сторону.. Это становится дороже в разработке.
Жалуюсь: много лет писал в поддержку(каждые пол года) о том чтобы добавили регулятор скорости для Подкастов и прослушивания музыка. И?! Свершилось, добавили год назад, с шагом 50%: т.е. 0.5x, 1x, 1.5x, 2x, 2.5x. Ну спасибо конечно, но это как безногому ботинки подарить.
Любые курсы, уроки, подкасты всегда (в 99% случаев) содержат очень много воды. Например центральные новости и блоги известных блогеров всегда записаны ёмко и сжато без воды. А вот остальные записи 99% людей всегда содержат много воды. Например инструкция о том как разобрать смартфон, или как поменять радиатор на автомобиле, или как сделать пельмени. Курс пельменей на 10мин, конечно хочется прослушать это намного быстрей но без ущерба для психики. Как можно слушать чтото с ускорением с шагом 50%?.
Ведь видео, аудио контент это не только музыка и мультики с фильмами где не требуется ускорение, но это еще и уроки, курсы, подкасты, новости, в которых ускорение главная функция вопреке качеству записи.
А сейчас вообще нет ускорения.
Сделайте ускорение в 10%: Например: выбор ускорения из меню можно сделать с шагом 40%, но и нажимая кнопки +,- можно было бы с шагом 10%.
👍👌Коллеги, а разве PHP как модуль Apache (mod_php) и KPHP это не одно и тоже?
Я понимаю что KPHP конвертируется в C++, но задача же стояла не в конвертации, а в экономии ресурсов на интерпретаторе, на инициализации объектов.
Ведь, тем более выполнять параллельные запросы можно используя семафоры.
KPHP спустя 2 года