Эх, а я надеялся, что вы через MDK сделали :). Но Consul тоже хорошее решение, оно вроде как для таких вещей и предназначено, насколько я понимаю.

У Apple есть «адаптивная зарядка» с относительно недавнего времени, которая временно уменьшает заряд батареи, если она сильно нагрелась, чтобы уменьшить её износ: https://support.apple.com/en-gb/HT211094

Блин, да сколько раз объяснять, правильно будет ClickHouse, а не Clubhouse!

Я не думаю, что в этом сериале она стоит. По крайней мере в экранизации многие моменты упрощены или пропущены, поскольку это было бы скучно смотреть (например, лишь намекают на то, что полеты зачастую занимают недели).

Тем не менее, законы физики не игнорируются, и лично мне, как человеку с образованием ученого, это как минимум приятно.

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

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

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

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

Кстати говоря, очень частая ошибка, которую люди совершают при, скажем, отладке программ или больших сложных систем, это как раз ставить эксперименты, которые должны подтвердить чьё-то предположение, а не опровергнуть. Людям вообще больше нравится, когда их поддерживают, а не когда их подвергают сомнению, и это нормально :). Но это иногда и мешает, и нужно уметь применять научный подход там, где он полезен больше всего — при написании тестов, при поиске ошибок, и так далее.

Так можно же акциями заплатить за что-то и не продавать их. Я так понимаю, при покупке компаний за $N млрд далеко не всё из этого это наличные.

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

Вообще, находить причину проблемы обычно помогает ее исправить и не допустить в будущем, что обычно хорошо, как минимум для компании.

Саш, я помню, что раздел про history simplification в мане про git-log был ещё лет 5 назад… Впрочем, может быть, ты прав, что он был только в rev-list.

Я напарывался на похожие проблемы, когда для системы переводов пытался надежно определить последний коммит, в котором менялся файл, и, на удивление, не смог, именно из-за сложностей обработки merge-коммитов, и в итоге на эту идею плюнул :).

Ещё в целом прикольные подводные камни возникают, когда в прямо merge-коммите что-то дополнительно добавляют или убирают, а не просто разрешают конфликты. В таких случаях раньше git show -p для такого коммита ничего не показывал, а git log <filename> по-моему не показывает merge-коммиты по умолчанию :).

Разделение экрана по горизонтали — да, поддерживается давно. Разделение экрана по вертикали добавили буквально 4-5 лет назад в основную репу, если мне не изменяет память.

Это было актуально лет 5-7 назад :).

Я думаю, причина примерно та же, почему ФБ сначала реализовал транслятор в C++ — есть такое распространенное (и нельзя сказать, что необоснованное...) мнение, что никакой JIT не будет быстрее хорошего кода на плюсах. В случае с тем, как реализованы классы в KPHP, я лично сомневаюсь, что JIT в PHP в скором времени сможет догнать простой код на плюсах, который генерит KPHP, а усилий приложить придется намного больше.

Побуду немного адвокатом дьявола. В VK разработка идет на обычном PHP, а KPHP используется только для финальной сборки кода на продакшене, поэтому разработческий опыт при разработке с использованием KPHP и при использовании обычного PHP отличается слабо. При этом, PHP до сих пор очень хорошо подходит для разработки в вебе, в том числе и для новых проектов, даже по сравнению с языками с быстрой компиляцией, такими как Go. В PHP действительно работает парадигма «сохранил файл, перезагрузил страницу, посмотрел, что изменилось», и это очень сильно помогает при разработке, особенно в начале.

Даже если у вас есть большой готовый проект, который мало использует рефлексию и прочее (хотя бы из соображений производительности) и код всё равно из себя в основном представляет из себя ООП с уже прописанными аннотациями типов, KPHP может дать очень большой выигрыш в производительности за счёт того, что он компилируется в почти что эквивалентный C++. Стоит ли того переделка кодовой базы (или допиливание фич в KPHP) или нет, решается на основе того, сколько стоят альтернативы: переписать существующую и хорошо отлаженную, пусть и legacy, кодовую базу с нуля на Go будет намного дороже и рискованней для бизнеса, чем адаптация существующего кода под новые реалии. Если производительность PHP-кода действительно становится узким местом и у вас много серверов, то, как мне кажется, вариант с KPHP может и взлететь, даже если для этого нужно будет добавить в KPHP какие-то недостающие для вас фичи.

Но кстати даже тогда, когда повсюду были ассоциативные нетипизированные массивы — даже тогда KPHP выигрывал больше, чем 10%, тут ты занижаешь.

Ну времена работы многих страниц (повторюсь, в основном, конечно же, тех, где нет или почти нет асинхронного кода) правда мало отличались. Так и должно быть, потому что основной выигрыш в производительности от PHP7 по сравнению с PHP5 как раз и был в том, что были оптимизированы внутренние хэш-таблицы, а JIT, как оказалось, на реальном PHP-коде давал не так уж и много.

Хотелось бы всё-таки увидеть полноценную методологию тестирования с цифрами (хотя бы относительными, чтобы не нарушать NDA и прочее) и анализом CPU usage и прочего, чтобы сравнивать именно производительность PHP без учета асинхронного кода против производительности KPHP без учета асинхронного кода. Также нужно сделать сравнение TL-схемы честным, чтобы и для PHP и для KPHP использовались одинаковые механизмы (поскольку для PHP тоже можно десериализовать TL-схему в расширении и генерировать готовые классы сразу из расширения, и это будет на порядок быстрее десериализации на самом PHP), отключить xdebug и использовать production-режим, где не считаются стректрейсы для отладки на каждый вызов RPC. И также не резолвятся имена хостов без нужного кеширования (т.е. вместо localhost используется 127.0.0.1, например).

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

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

Расскажите про это подробнее как-нибудь, пожалуйста :).

А если его использовать абы как, то PHP кое-где случайно и может окажется быстрее.

Совершенно не случайно. Ядро обычного PHP тоже оптимизировано очень хорошо для того кода, который обычно встречается на практике (то есть этот код не содержит строгих аннотаций типов, например). Плюс в opcache в PHP точно также кешируются константные значения, даже для массивов, и в целом оверхед от рантайма обычного PHP меньше, например в плане потребления памяти, чем в KPHP. Ну и в целом обычный PHP тестируется на реальных кодовых базах за пределами VK, так что несложно представить себе ситуацию, что в том же opcache или в SSA представлении будут существовать оптимизации, которых нет в KPHP, но для конструкций, которые часто используются в сторонних (по отношению к ВК) кодовых базах на PHP.

Но это не наш случай.

Я бы не был так категоричен. Код ВК тоже является в первую очередь кодом на PHP, и во вторую это уже некоторое подмножество, которое хорошо работает с KPHP. Тем не менее, я рад, что вы выложили свои наработки в open source и надеюсь, что поддержка ООП и прочего в KPHP уже достаточно хороша для того, чтобы можно было запустить какие-нибудь реальные проекты на его основе без слишком больших модификаций. Надеюсь увидеть от вас больше статей, но в которых поменьше хвастовства и побольше «мяса» и технических деталей.

Спасибо за статью и за то, что открыли исходники!

Однако, как у человека, который работал в ВК не так давно, хотел бы уточнить один момент:

Если говорить про бенчмарки, то на средних VK-страничках у нас профит от 3 до 10 раз. А на конкретных участках, где мы прицельно выжимали максимум, — до 20–50 раз.

Расскажите пожалуйста, как Вы тестировали, и на каких страницах есть выигрыш, и почему. Когда я пару лет назад тестировал производительность сайта под PHP 7.2, для более-менее честного сравнения отключался xdebug и development режим сайта, поскольку оба дают очень существенный оверхед при исполнении. В таком режиме многие страницы, где не используются асинхронные запросы (в PHP коде вместо этого ведь просто заглушки стоят), выполнялись со сравнимой скоростью (страницы вроде списка друзей или мессенджера отрабатывали за такое же время, как и KPHP, плюс-минус 10%). Некоторые страницы, вроде ленты, действительно сильно заточены под KPHP и работали в ~10 раз медленней, но в общем и целом разница была не такая большая, и точно не в 3-10 раз. Причём во большинстве случаев разница была из-за того, что в PHP не реализован тот вид асинхронных запросов, который есть в KPHP, но само ядро PHP вполне поддерживает те же концепции, поскольку как минимум есть конструкция yield, которая точно также сохраняет состояние функции в произвольном месте и умеет восстанавливать его обратно.

При этом, конечно же, на коде, который использует полностью типизированные классы и структуры вряд ли что-то может быть сильно быстрее KPHP, потому что он буквально транслирует этот код в C++ почти что один-в-один, и, как мне кажется, это и является единственным существенным преимуществом KPHP перед современными версиями PHP, и, вероятно, даже с появлением JIT в PHP8 всё равно производительность KPHP будет выше, если специально затачивать код под него.

Просто хотелось поменьше голословных утверждений про производительность KPHP на реальной кодовой базе и больше деталей и примеров по поводу того, какой код действительно ускоряется с помощью KPHP, а какой — нет, или даже работает медленней современного PHP, который тоже на месте всё это время не стоял.

Команды вроде git log, git blame и других будут давать неправильные результаты :). Также мерж веток может быть невозможен, если общий предок был раньше, чем момент, где история заканчивается.

По сути git clone --reference ... и решает все проблемы, которые присущи shallow clone, хоть и вносит новые (лучше всего в reference-репозитории хранить только master ветку, и никакую больше, чтобы был невозможен сценарий, когда после git gc или git prune пропали какие-то объекты из репозитория).

Что же будет, когда они узнают про опцию --reference...

Честно говоря, не уверен, что действительно стоит обновлять страницу сразу после деплоя: как минимум это плохо тем, что это вызовет шквал запросов от пользователя сразу после деплоя. Если деплой происходит часто, то это будет ещё и плохой user experience.

Также нужно учитывать, что у многих (большинства?) более-менее крупных сервисов есть ещё и мобильные клиенты, а иногда и десктопные тоже, и соответственно у вас должен быть более-менее стабильный API на стороне бэкенда, и соответственно, если вы из JS обращаетесь напрямую к этому API, то не обязательно перезагружать страницу пользователя принудительно. Понятно, что часто для веба делают ещё один слой между чистым API на бекенде и фронтендом, но даже в этом случае иметь некоторую обратную совместимость было бы тоже полезно.