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

7 комментариев
Котячий 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 на полном серьезе мы будем лишь после релиза исходников последнего.

Горячие события

Конкурс EY Entrepreneur Of The Year 2020
31 мая — 31 мая

Конкурс EY Entrepreneur Of The Year 2020

ISsoft Insights 2020
6 июня — 6 июня

ISsoft Insights 2020

Минск
GoWayFest 4.0
11 июля — 11 июля

GoWayFest 4.0

Минск

Читайте также

iOS-приложение Zoom сливает данные в Facebook — даже если пользователя нет в соцсети
iOS-приложение Zoom сливает данные в Facebook — даже если пользователя нет в соцсети

iOS-приложение Zoom сливает данные в Facebook — даже если пользователя нет в соцсети

ВОЗ запускает коронавирусный хакатон
ВОЗ запускает коронавирусный хакатон

ВОЗ запускает коронавирусный хакатон

Как крупные ИТ-компании помогают бороться с коронавирусом
Как крупные ИТ-компании помогают бороться с коронавирусом

Как крупные ИТ-компании помогают бороться с коронавирусом

США хотят использовать данные геолокации со смартфонов, чтобы отслеживать вирус (обновлено)
США хотят использовать данные геолокации со смартфонов, чтобы отслеживать вирус (обновлено)

США хотят использовать данные геолокации со смартфонов, чтобы отслеживать вирус (обновлено)

1 комментарий

Обсуждение

0

«драматически ускоряет работу»... калька с “dramatically increase”? ;)

1

Хорошая статья, спасибо. Интересно было бы почитать, как с производительностью сейчас дела у конкурирующих языков (python, ruby...).

1

слабо.
нужно сразу asm генерить. тогда нагрузку на CPU на пару порядков можно снизить.

1

А еще лучше реализовать все аппаратно на микросхемах серии КР1533, а для особых эстетов - на лампах )

0

Да, LAMP на лампах - теплее некуда :)

0

Отличный слоган!

0

Интересно какие операции она могла ускорить там конкретно в вк