Котячий kPHP против американского HipHop’а

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

Итак, рассмотрим хронологию создания и принципы HipHop (Facebook) — системы трансляции PHP-кода в бинарные приложения. В качестве бонуса мы сравним ее с новоиспеченным kPHP от ВКонтакте и совсем немного посплетничаем…

Как PHP пытается адаптироваться к миру высоконагруженных проектов?

Концепция трансляции HipHop

Исторически решение этой задачи по оптимизации было многошаговым. Но первым, самым важным и инициирующим весь процесс шагом было создание собственного транслятора исходного кода PHP, который чуть позже был сделан полностью открытым для интернет-сообщества проектом. По сути HipHop (а точнее, его компилятор — HPHPc) получает на вход дерево исходников обычной PHP-программы. В процессе своей работы он программно анализирует и транслирует весь исходный PHP-код в функционально эквивалентный и оптимизированный исходный код на C++.

В качестве второй, уже чисто сервисной функции HPHPc компилирует сгенерированные им исходники с помощью компилятора  g++ в полноценные бинарные и исполняемые файлы.

Общий алгоритм работы HiHop:

1. Сначала проводится подготовительная внутренняя оптимизация целевого PHP-кода.
2. Затем этот PHP-код конвертируется в эквивалентный на языке С++.
3. На основании полученных данных HipHop генерирует оптимизированный многопоточный веб-сервер.
4. Финальная компиляция в исполняемый код при помощи g++ всех составных частей новой системы.
5. Таким образом, на выходе мы получаем специализированный веб-сервер, монолитно встроенной частью которого является функционал, эквивалентный исходной PHP-программе.

И хотя мы перечислили все логические шаги по трансформации программы, следует дополнительно отметить, что HipHop, на самом деле, нечто большее — это скорее самодостаточная экосистема, чем просто обычный кросс-транслятор. Кроме собственного веб-сервера и среды исполнения (HipHop server), сюда также входит набор популярных расширений используемых в мире PHP, которые были заранее переписаны на «чистом Си», при этом сохранив стандартные старые API-интерфейсы, а значит, и совместимость.

В HPHPc обеспечена не эталонная 100-процентная поддержка оригинального PHP: некоторые динамические возможности PHP (например, оператор eval()) просто игнорируются и не включаются в транслируемый код.

Дальнейшее логическое развитие проекта

Как сразу вытекает из разобранного базового алгоритма, важный недостаток HPHPc в том, что после каждого изменения исходной PHP-программы требуется полная повторная перекомпиляция всей среды. Это достаточно неудобная и ресурсоемкая операция для больших приложений, особенно находящихся в стадии постоянной интенсивной разработки.

Как реакция на эту проблему, в рамках HipHop for PHP вскоре появился специальный подпроект — HPHPi. Это почти «интерактивная версия» HipHop, которая в значительной мере автоматизирует цикл перекомпиляции, выполняя ее избирательно и в фоновом режиме. Существенным недостатком именно этого решения стало то, что поведение HPHPi несколько отличается от поведения стандартного HPHPc. Модифицированный алгоритм работы иногда приводит к тому, что некоторые ошибки, которые отсутствовали на стадии тестирования на серверах разработчиков с установленным там в целях удобства отладки HPHPi, неожиданно всплывали на промышленных серверах с HPHPc. Кроме того, очевидно требовалось параллельное совместное использование этих двух разных движков, что еще больше раздувало инфраструктуру и лишало ее унификации.

Продолжая анализировать и упорно совершенствовать уже упомянутые инструменты своего проекта, Facebook в итоге пришла к достаточно неожиданному и радикальному новому решению — HHVM (HipHop virtual machine). Теперь эта виртуальная машина, которая в чем-то похожа на оригинальный PHP-интерпретатор, в режиме реального времени компилирует PHP-скрипты в байткод, запуская последний в виртуальном машинном окружении. Здесь читатель может вполне справедливо удивиться: зачем был пройден столь длинный эволюционный путь, чтобы в итоге получить по устройству нечто похожее на исходный вариант?

Хейпин Жао, главный разработчик HipHop for PHP, Senior Server Engineer (Facebook)

Ответ скрыт в интересных особенностях нового JIT-компилятора, который был создан полностью с нуля силами Facebook, и который снимает упомянутые сложности с промежуточным решением HPHPi, при этом еще больше ускоряя запуск PHP-скриптов по сравнению с HPHPc. Если абстрагироваться от многочисленных деталей и мелких улучшений, главная суть сводится к трем главным новшествам:

• Возможность настроек стратегии хранения ранее скомпилированного кода: как в промежуточном байткоде, так и сразу в настоящем машинном коде. В HHVM, в отличие от HPHPc, не нужен g++, равно как и промежуточная стадия трансформации в C++ тоже: при выборе соответствующей стратегии компиляция для получения бинарного кода осуществляется сразу и напрямую;
• Реализовано очень развитое кеширование уже скомпилированного кода — учет и управление всеми участками и фрагментами кода во всех его доступных в любой текущий момент состояниях осуществляется на базе единого репозитория. Здесь кеш всегда хранится на диске, а не в оперативной памяти, как у некоторых традиционных PHP-акселераторов. Любая перезагрузка или остановка не лишает систему «кешевой памяти», также доступна и обратная возможность — предгенерация полной версии кеша сразу для всего приложения еще перед запуском веб-сервиса;
• HHVM изначально оптимизирован и предназначен для работы исключительно на 64-битовых системах. И хотя есть неофициальные проекты, которые создали патчи в том числе и для 32-битовых процессоров, их производительность или стабильность работы не гарантируется.

Тем, кто ознакомился с этим довольно длинным и сложным эволюционным путем, в качестве десерта предлагаю некоторые цифры и факты, которые более ярко характеризуют эти такие разные 3 инкарнации проекта HipHop for PHP:

• самая первая публичная версия HipHop (начало 2010 года) примерно в два раза снижала нагрузку на CPU по сравнению с классическими методами оптимизации (имеются в виду в первую очередь Zend Engine, eAccelerator и APC);
• на данный момент Facebook заявляет, что использование последней версии HPHPc позволило уменьшить нагрузку на процессор в среднем в 5—9 раз по сравнению с исполнением PHP-скриптов в их родном окружении;
• в ноябре 2012 года было объявлено, что текущая версия движка HHVM в среднем в 2 раза превосходит по своей производительности предшественника HPHPc. Впрочем, на этом разработчики останавливаться не планируют, заявляя о возможностях дальнейшего роста производительности текущей отладочной версии HHVM в результате еще более тщательной ее оптимизации;
• данные разработки Facebook позволили выявить довольно много узких мест со скоростью на стороне самого PHP. В частности, не так широко известен факт, что заявленный в релизе PHP 5.3 скачок производительности в 10% — почти полностью вклад инженеров Facebook, это побочный результат их исследований в рамках своего проекта HipHop;
• обеспечена интеграция с Intel Threading Building Blocks (TBB), что драматически ускоряет работу откомпилированных скриптов на современных многопроцессорных системах;
• по мнению аналитиков Facebook, именно HipHop позволил успешно преодолеть этой социальной сети недавний серьезный барьер в 1 триллион просмотров в сутки так называемых «сложных» PHP-страниц (сборка каждой Facebook-страницы требует учета большого числа настроек и зависимостей, например, множества событий на страницах всех друзей и так далее);
• в силу не полной поддержки трансляции PHP летом 2011 года проектом HipHop была проведена дополнительная работа по адаптации кода самых популярных CMS-проектов написанных на PHP (вот лишь некоторые из них: Drupal, MediaWiki, phpBB, WordPress).

Как логичный результат этого поступательного развития, уже в текущей сборке HipHop for PHP ее наиболее проблемная составляющая HPHPi помечена как «нежелательная к использованию» (она будет отключена в ближайших релизах). В связи со ставкой на HHVM еще в 2012 году было анонсировано, что основная на тот момент подсистема HPHPc также постепенно будет переведена в статус «не рекомендовано для использования».

И вот историческое для Facebook событие — в мае-июне текущего 2013 года серверы Facebook полностью перешли с HPHPc на HHVM. В связи с этим на Github был выложен исходный код виртуальной машины, а также уже собранные пакеты для Ubuntu 12.04, Debian 7 (wheezy) и Centos 6.4 (в самое ближайшее время будет добавлен пакет и для FreeBSD 9).

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

ВКонтакте наносит ответный удар

Крупнейшая российская социальная сеть ВКонтакте, которая также растет буквально на дрожжах, аналогично работает на PHP, поэтому столкнулась в процессе роста с сопоставимыми по сложности проблемами. В том же мае-июне 2013 г., одновременно с Facebook, она осуществила миграцию на собственный вариант PHP-ускорителя — kPHP. Для искушенной webdev-публики таинственный незнакомец kPHP стал во многом тем же HipHop’ом, только намертво сращенным с APC (с которым HipHop с недавних пор также идет в одном комплекте). В чём же тогда отличия и новизна kPHP, с дурным скепсисом вопрошают отечественные люди-разработчики?

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

На изображениях ниже можно оценить замеры-изменения по скорости работы соцсети ВКонтакте до и после ее перехода с чистого PHP на kPHP:

Что же касается многочисленных сравнений с HipHop, то вот как сам Вождь нескромно поясняет эту деликатную тему:

На всех тестах было неудобно за PHP HipHop. Либо Facebook дал в общий доступ сильно испорченную версию, либо мы разработали нечто принципиально лучшее. Это касается не только скорости работы скомпилированного кода, но, в первую очередь, скорости компиляции.

И тут время ясно сформулировать главный приоритет и глубинную причину клонирования HipHop создания kPHP — это максимально возможное увеличение скорости выполнения PHP. Якобы именно по этой причине ВКонтакте не устроил HipHop, также нарекания вызвала высокая сложность и нестабильность сборки конкурента.

Так, разработчиками vk.com утверждается, что скорость выполнения кода в среде kPHP увеличилась более чем в 10 раз (при условии идеальных внешних условий, то есть отсутствия лагов/ожидания ответов со стороны БД и т.п.). Программисты также заявляют, что после перехода на kPHP они стали использовать почти в два раза меньше серверов для обработки пользовательских запросов, при этом нагрузка осталась прежней.

Информации о потрохах kPHP пока мало, ниже я попробовал перечислить все факты, которые уже стали известны публике:

• в kPHP не поддерживается ООП, за исключением всего нескольких стандартных объектов PHP. Кстати, одной из задач при переводе социальной сети на kPHP было полное избавление от оверхеда, генерируемого «ненужным» ООП;
• kPHP планировался как не полностью совместимый с PHP язык: в нем есть ряд конструкций, которые, например, позволяют явно задавать типы переменных, чтобы ускорить выполнение-компиляцию;
• достигнуты существенные преимущества в использовании памяти. Кроме того, kPHP значительно меньше грузит процессоры;
• очень, очень хороший статический анализ;
• префикс k в названии проекта — от слова kitten, который стал традицией в названиях внутренних разработок ВКонтакте;
• компиляция всего PHP-кода соцсети ВКонтакте через kPHP занимает несколько минут — итоговый скомпилированный бинарник сейчас весит около 300 мегабайт (не учитывая библиотек);
• распределенная компиляция проекта;
• все стандартные внутрисетевые для ВКонтакте функции вынесены в отдельные внешние библиотеки, реализованные на чистом C++. Впрочем, в обычном PHP тоже можно добавлять новые функции, написанные на C;
• в будущем планируется реализация ограниченной поддержки ООП.

Я сказал, ООП обратно запили!

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

В сети ВКонтакте основные тормоза на данный момент — это вовсе не скорость генерации страниц, которая тем более подскочила после озвученных нововведений. Наиболее узкое место — это (традиционно для всего HiLoad) ожидание ответа от многочисленных баз данных. В этой ситуации главный тренд развития ВКонтакте — уход от медленного MySQL, на который ещё три года назад был завязан весь основной код. В данный момент используются некие «высокооптимизированные» самописные движки БД, о которых лишь известно, что в будущем их исходный код будет также открыт широкой общественности (уже шаблонная оговорка — «вот только сейчас код немного подчистим, и сразу выложим»). Сейчас они взаимодействуют с внешним миром на базе хорошо известных memcache-совместимых протоколов.

Существует мнение, что именно этот протокол является наиболее узким местом в производительности всей системы. Поэтому в качестве ответа на этот серьезный вызов, в игру введен сам родной брат главного Дурова aka Вождя — Николай Дуров, — который и разработал, как это водится в таких случаях, не размениваясь по мелочам — «принципиально новый» универсальный протокол mtproto. Недавно сетью ВКонтакте была развернута бодрая движуха, в частности, начата компания популяризации этого протокола, где делается попытка создания рабочих клиентов на его базе. Впрочем, как сообщают голоса в моей голове некоторые слухи, в скором будущем этот специализированный и более лаконичный протокол может заменить те самые memcache-совместимые интерфейсы в натруженной утробе ВКонтакте.

В связи с этим, поскольку этот новый бинарный протокол использует объектную TL (схема типов этого протокола), разработчики kPHP внезапно осознали… что им все-таки нужен уже выпиленный ООП! Впрочем, я бы не ерничал в этом месте, потому как любой разработчик, имевший дело с долгосрочными и сложными проектами, как мне кажется, самолично и многократно наблюдал похожие жестокие для самооценки любого системного архитектора сюжеты вызывающие отчаянное желание немедленно переписать все с нуля. Подмечено, что такие, отчасти неловкие озарения, обычно случаются аккурат после успешной сдачи и завершения проекта.

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

Что же касается самого mtproto (который получился сильно навороченным с креном в сторону безопасности и шифрования), то будем надеяться, что его не постигнет фейл Mail.ru с их типа «совсем новым» протоколом WebRTC. Сравнивать же HipHop с kPHP на полном серьезе мы будем лишь после релиза исходников последнего.

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.