Прошло чуть более двух лет с момента последнего сообщения Мэтта Турланда о HHVM . Что изменилось за это время? Сделал что-нибудь? Давайте посмотрим, насколько успешным был PHP-поиск производительности.
HHVM — что это было снова?
Как Мэтт говорит в своей статье, HHVM
[…] Компилятор Just-In-Time (или JIT). Вместо того чтобы проходить фазу компиляции C ++ для перевода PHP в нативный код, hhvm переводит PHP в язык промежуточных байт-кодов, называемый HipHop Byte Code (HHBC), который может быть преобразован в нативный код в режиме реального времени, когда это необходимо […]
Другими словами, ваш PHP-код выполняется практически на скорости, близкой к C ++. HipHop начинал как компилятор, чьи двоичные файлы, когда они были созданы, вы бы развернули — как Zend Guard или IonCube. HHVM отличается тем, что работает в режиме реального времени. Сам по себе процесс ручной компиляции пока нет, и цикл разработки остается быстрым.
Так что же это? Сервер? Как он на самом деле выполняет мой PHP? Работает ли это с Apache / Nginx / IIS? Это заменяет их? Может ли это даже конкурировать с ними? Как вы используете его? Вы устанавливаете это как расширение? Я знаю, что такие вопросы могут вызывать определенные головные боли, когда все это звучит так абстрактно. Давайте попробуем демистифицировать это немного дальше.
Как на самом деле работает HHVM?
HHVM при получении файла PHP компилирует указанный файл в байт-код HHVM. Он буквально переписывает его на более низкий язык, который быстрее переписать в нативный код — то, что процессор может интерпретировать напрямую. Как вы можете себе представить, делать это снова и снова при каждом обращении к файлу было бы излишним и на самом деле замедляло бы работу всего приложения. Вот почему HHVM использует базу данных SQLite на диске для запоминания скомпилированных файлов.
Если вы знакомы с APC, это более или менее одно и то же. При первом запуске HHVM кеш пуст, поэтому в первых нескольких запросах все выглядит медленнее. Однако со временем все прогревается, и приложение ускоряется. Есть одно принципиальное отличие между работой APC и HHVM. APC сохраняет скомпилированный код в памяти, в то время как HHVM делает это на диске (БД SQLite). Это означает, что скомпилированные результаты сохраняются и перезапускаются — когда вы перезагружаете свой сервер, кэшированные скомпилированные файлы все еще там, поэтому не требуется период прогрева. Хотя это несколько медленнее, чем чтение из памяти (каждый диск всегда будет медленнее, чем ОЗУ), это также означает, что вы можете еще больше повысить скорость своего приложения, разместив его на SSD-сервере.
Дальнейшее повышение производительности достигается с помощью JIT. Это опция, но она включена по умолчанию для режима сервера и демона. Что JIT делает, так это дополнительно компилирует байт-код HHVM в собственный код, поскольку он узнает о наиболее часто используемых файлах. Опять же, это приносит определенный период разогрева, но как только мяч катится, появляется немало инерции, чтобы конкурировать с ним.
Совместимость HHVM с популярными серверами
HHVM устанавливается через менеджер пакетов или создается из исходного кода. По сути, это просто программа, которую нужно установить, как и любую другую — в настоящее время она доступна в Ubuntu, Debian, CentOS и Fedora. Первоначально HHVM заменил весь стек PHP + серверов — у него был собственный сервер. Это все еще, на самом деле. Сервер HHVM мало чем отличается от того, что вы можете увидеть при работе с NodeJS — вы запускаете его из командной строки, говорите ему принимать запросы на данный порт и все остальное, что вы обычно говорите Apache, Nginx, IIS, Tomcat, Lighttpd или любым другим сервер. Существует множество параметров конфигурации для вашего прочтения ( https://github.com/facebook/hhvm/wiki/runtime-options ), и большинство из них довольно понятны и просты. Фактически, если вы будете следовать превосходному учебнику по WordPress от HHVM, вы увидите, насколько проста базовая конфигурация сервера.
Однако 17 декабря 2013 года команда HHVM объявила о поддержке FastCGI. FastCGI — это протокол для взаимодействия сервера с сервером приложений. Это позволяет разделить обязанности — HHVM выполняет код PHP, для которого он и предназначен, а ваш сервер обрабатывает все аспекты HTTP, перенаправляя обработку PHP в HHVM. Хотя оригинальный сервер HHVM не плохой, полезно знать, что теперь HHVM можно использовать в тандеме с вашим обычным сервером. Важно отметить, что в настоящее время он поддерживает только связь через TCP — после добавления поддержки сокетов Unix узкое место в сети, которое в настоящее время мешает, исчезнет, а производительность HHVM будет улучшаться еще больше.
Вопросы производительности
При рассмотрении скорости фактическая производительность HHVM FastCGI по сравнению только с HHVM зависит от количества статических ресурсов. В то время как чистый HHVM почти всегда будет быстрее при выполнении сценариев PHP, когда речь идет о статических ресурсах числа, сервер, оптимизированный для такой задачи, может просто выполнять свою работу лучше, что подтверждается твитом HHVM:
Естественно, это не имеет смысла, если вы используете сторонние CDN для статических ресурсов, так что решать вам. Хорошая новость заключается в том, что оба подхода просты в реализации, и выполнение некоторого a / b-тестирования производительности и обслуживания не должно быть слишком сложным, если вы решите выяснить, какой подход лучше для вашего приложения.
Способы улучшить общую скорость в целом:
— развертывание на SSD для более быстрого чтения / записи в кэш
— предварительный анализ
— авторитетный кеш
— следуйте этим микро-оптимизациям
Pre-анализирующей
Предварительный анализ — это концепция, хорошо освещенная в их официальном блоге, но я постараюсь подвести итог здесь. Когда HHVM компилируется / устанавливается, он имеет двоичный файл, называемый onhhvm-analyzehphp Этот двоичный файл — то, что запускается при выполнении оптимизаций во время выполнения — он выполняется до того, как сервер раскрутится, чтобы обслужить результаты запроса. С HHVM у вас есть возможность запустить анализ до того, как приложение будет запущено — вы можете передать ему список файлов, которые вы хотите включить в кеш, и предварительно кэшировать их. Это дает дополнительное преимущество, заключающееся в том, что вы избегаете периода прогрева и выполняете более детальную, более медленную оптимизацию, потому что никто кроме вас этого не ждет. Предполагается, что вы запустили его для предварительной оптимизации, поэтому для того, чтобы сделать это правильно, требуется дополнительное время.
Авторитетный кеш
Когда вы устанавливаете кеш как авторитетный в конфигурации веб-сервера или демона, вот так…
Repo {
Authoritative = true
}
… HHVM предполагает, что кэш скомпилированного кода является единственным источником кода. Когда это ложно (по умолчанию), HHVM проверяет, был ли файл изменен, и если это было так, его нужно перекомпилировать. Это означает дополнительную работу с диском (даже если перекомпиляция не требуется, ему все равно нужно было прочитать заголовок файла, чтобы увидеть, был ли он вообще изменен), что означает дополнительные потери производительности. Если для авторитетного кэша установлено значение true, HHVM даже не ищет оригинальный файл. Если он изменился, вам нужно вручную перестроить кеш. Если вы обновили HHVM до более новой версии, кеш становится недействительным, и вам необходимо заново перестроить кеш вручную. Из-за этих дополнительных шагов авторитетный флаг обычно используется только в производстве, где практически нет шансов на частичное изменение отдельных файлов PHP.
Вывод
HHVM развивался быстро и значительно за последние 2 года, когда мы в последний раз освещали этот вопрос. Повышение производительности измеряется факторами, удобство использования впечатляюще возросло, кривая обучения установке практически исчезла, и последние тесты показывают, что она даже поддерживает большинство популярных на сегодняшний день фреймворков и приложений с открытым исходным кодом PHP, от PhpMyAdmin до Symfony2 и далее.
С таким уровнем зрелости SitePoint будет охватывать HHVM в гораздо большей степени. Следуйте тегу HHVM для получения дополнительных статей и руководств, включая, но не ограничиваясь, демонстрационные приложения, установки пользовательских сред, развертывания в реальном времени и многое другое.
Если вы хотите, чтобы был рассмотрен особый случай использования HHVM, или хотели бы рассказать о своем собственном опыте с ним, пожалуйста, свяжитесь со мной через + BrunoSkvorc, и мы поговорим подробнее! Оставьте свои комментарии и мысли ниже!