Языки программирования бывают двух видов: интерпретируемые и компилируемые. А каким языком является PHP? Для того, чтобы ответить на этот вопрос, нам необходимо разобраться в терминологии.

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

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

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

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

Рассмотрим рисунок:

Мы видим, что PHP составлен из двух почти независимых блоков - транслятора и интерпретатора. Зачем же понадобилось так делать? Конечно, из соображений быстродействия.

На вход PHP подается сценарий. Он переводит его (транслирует) , проверяя синтаксис, в специальный байт-код (внутреннее представление). Затем PHP выполняет байт-код (а не код самой программы), при этом он не создает исполняемый файл.

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

Рассмотрим цикл:

For (i=0;i<10; i++) { Operator_1; Operator_2; Operator_3; ............ Operator_99; Operator_100; }

Такой цикл будет «крутиться» 10 раз. За каждый из этих десять проходов интерпретатор должен и 100 строк кода. А в ему нужно проанализировать и выполнить 10*100 = 1000 строк кода! Если перевести один раз весь цикл в байт-код, то анализировать ему придется в 10 раз меньше! А это значит, что сценарии будут выполняться в 10 раз быстрее!

Получается, что PHP является.

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

Стоит вспомнить, что PHP версии 3 был «чистым» интерпретатором», а с PHP 4 сценарии стали выполняться значительно быстрее, поскольку 4-я версия PHP (и PHP5) является интерпретирующим транслятором.

Язык Perl, который практически всегда называют компилятором, работает точно по такой же схеме - он транслирует текст программы во внутреннее представление, а затем использует результирующий код при исполнении. Так что, можно сказать, PHP версии 4 представляет собой компилятор ровно настолько, насколько им является Perl.

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

Использование интерпретатора (а значит и PHP) имеет свои неоспоримые преимущества:

• Нет необходимости заботится об освобождении выделенной памяти, не нужно закрывать файлы по окончании работы с ними – всю рутинную работу сделает интерпретатор, поскольку программа выполняется под его бдительным контролем;
• Не нужно думать о типах переменных, а также не нужно объявлять переменную до его первого использования;
• Отладка программ и обнаружение ошибок существенно упрощаются – интерпретатор полностью контролирует этот процесс;
• В контексте web-приложений, интерпретатор также имеет еще очень важное преимущество – нет опасности «зависания» сервера при неправильной работе программы.

Есть и другие достоинства. Вообще, использование интерпретатора способно дать сценариям ту мощь, которую пользователи Web от них и ожидают.

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

<<< Назад (Что нового в PHP5 ?)

Содержание

Вперед >>> (Переход на PHP 5.3)

Есть еще вопросы или что-то непонятно - добро пожаловать на наш

Компиляция PHP из исходных кодов чаще делается на Unix-подобных систем. Те, кто работает в среде ОС Windows, скорее всего, загрузит и установит PHP из бинарных пакетов. И хотя я не согласен, что это проще в использовании, предварительно скомпилированных решение, даже на системах Unix есть некоторые преимущества, которые могут прийти с составлением двоичной от источника. В общем:

• У вас есть возможность тонкой настройки конечного продукта при компиляции. Может быть, вы хотите определенное расширение которое компилируется непосредственно в двоичном, а не загружать его в качестве внешней библиотеки. Или, возможно, вы хотите, выключить то что особенностью которого, как правило, доступно по умолчанию.
• Вы можете сделать хитрость, в процессе компиляции, если нужно, которые могут повысить производительность для конкретной среды (конечно, это предполагает, что вы уже знаете, что вы делаете в этом случае вы бы не читали эту статью !).
• Компиляция может быть единственным способом заставить вещи работать, если скомпилированные двоичные файлы были построены на более старых версиях с поддержкой программного обеспечения и библиотек, а сейчас Вы работаете на новой системе.

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

Настройка среды сборки

PHP написан на C и поэтому компилятор C необходим, если вы собираетесь построить PHP из исходных кодов. C + + это супер набор C, так что хороший C + + компилятор должен иметь возможность компилировать код C, и хотя это не всегда так. Для Windows, Visual Microsoft, C + + Express (который после будет называться VC + +) в свободном доступе на веб-сайте компании Microsoft . Использовалось издание 2010 года.

При выборе версии компилятора, вы должны иметь в виду, как вы будете работать под управлением PHP. Если вам придется работать с mod_php официально скомпилированных двоичных Apache, и вы хотите, скомпилировать PHP с помощью Visual Studio 6, так как это версия для компиляции Apache. Модуль должен нацелиться на ту же библиотеку времени выполнения, как Apache, в этом случае msvcrt.dll . Если вы строите Apache из исходных кодов, а также, или если вы собираетесь запускать PHP как FastCGI или CLI, то это не проблема, и 2010 год будет работать нормально.

Вы также должны установить программное обеспечение Windows Development Kit (SDK после). SDK дает нам важные файлы заголовков для платформы Windows, которая нам понадобится для успешной компиляции. Это тоже , использовалась версия 7.1.

Установите компилятор, а затем SDK. Я не буду обсуждать установку, так как оба имеют графический мастер установки, проведет вас через весь процесс.

Если у вас есть работающий компилятор создать, загрузить двоичный инструменты и Известные пакеты из windows.php.net . Бинарный пакет инструментов (я использую 20110915 архив) содержит средства разработки, как re2c, зубры, и некоторые дополнительные команды, которые вы должны будете построить PHP. Известные пакет (я использую 5,4 архив, поскольку это совпадает с версией PHP я буду компиляции) содержит минимальные заголовки и библиотеки зависимостей необходимо, например, zlib.h .

Это, вероятно, само собой разумеется, что вы хотите скачать источник PHP, а также от windows.php.net . На момент написания этой статьи, текущая версия PHP 5.4.6, так что этот номер версии вы увидите в примерах.

Это хорошая идея, чтобы создать рабочее пространство, к которому можно распаковать исходный код и компилировать что бы они не влияли на остальную часть Вашей системы. Создайте папку C: \ PHP-Dev , которая будут служить в качестве рабочего каталога, а затем распаковать в ней бинарный архив и инструменты.

Далее, распакуйте содержимое архива, источник PHP в C: \ PHP-Dev теперь у вас есть php5.4 в исходной папке, а затем извлечь его архив deps в одноуровневую папку deps. Структура каталога должна выглядеть примерно так:

Откройте Windows SDK Command Prompt, которая была установлен ​​с SDK (Start => Microsoft Windows SDK => Windows SDK Command Prompt) и выполнить следующие команды:

Setenv /release /xp /x86 cd C:\PHP-Dev bin\phpsdk_setvars.bat

С помощью командной строки консоли SDK желательно перед обычным cmd.exe консоли, как она задает много переменных среды, специфичных для компиляции исходного кода. Компиляции команд позже также должны быть выполнены в этой консоли.

setenv установить некоторые свойства сборки для окружающей среды, в данном случае установлена среда целевой Windows XP 32-разрядной версии сборки. Вы можете попробовать и построить с / x64 , если вы ищете приключений. Определение различных версий Windows, таких как / Vista , скорее всего, проблемы выхода из-за какой-то странной определений в скриптах (PHP по-прежнему хочет быть XP-совместимым). Если вы действительно не знаете, что вы делаете, это, наверное, безопаснее всего придерживаться рекомендуемых значений, которые я использовал выше.

phpsdk_setvars.bat сценарий выходит на некоторые дополнительные переменные окружения, процесс сборки смог найти бинарные инструменты.

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

Checking for bison.exe ... ERROR: bison is required

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

Компиляция PHP

В командной строке SDK, перейдите в папку источник PHP и запустить buildconf. Команда отвечает за генерацию конфигурационных файлов, которые будут созданы Makefile для управления процессом компиляции.

После buildconf завершает (это займет всего секунду), выполните настройку configure --help - и изучить помощь, какие функции вы хотите включить / выключить, а затем снова запустите configure (настройки) с любой желаемой опцией. Это хорошая идея, чтобы проверить выходные перед переходом, поскольку он предупредит вас, если любой из необходимых зависимостей не доступны. Если это произойдет, вы можете либо установить зависимости и повторно запустить настройку еще раз или отрегулируйте вызова для отключения расширений, которые в них нуждаются.

Наконец, запустите NMAKE , чтобы начать компиляции.

Cd C:\PHP-Dev\php5.4 buildconf configure nmake nmake test

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

Когда первый NMAKE процесса компиляции завершен вы найдете свой ​​новенькие PHP файлы в папке Release_TS. NMAKE тест запускает новые двойные через ёмкость ошибка тестов, чтобы убедиться, что все работает как и должно быть. Результаты тестов NMAKE направляются в QA команда, которая зависит от них, чтобы улучшить PHP, так что это может занять несколько минут, для работы, это ответственное дело.

На этом этапе вы также можете воспользоваться дополнительным шагом ведения NMAKE оснастки, которая создаст ZIP архивы и двоичные файлы, которые можно скопировать вокруг.

Компиляция extensions

Есть два пути для компиляции PHP extensions (расширений): статически и динамически. Статически скомпилированные расширение компилируется в бинарный PHP, в то время как динамически скомпилированных один отдельный DLL, которые могут быть загружены позже через php.ini файл. Расширения, как правило, составлен по состоянию DLL, хотя есть некоторые преимущества для статической компиляции, а также, в конечном итоге это зависит от ваших потребностей.

Для компиляции PHP extensions (расширений) на Windows, экстракт расширение исходного кода папку, в ext папку вашу директорию-источник PHP. Затем, заново настроить скрипт, запустив buildconf--force и перекомпиляции PHP, используя соответствующие пункты, чтобы включить расширение.

В качестве примера, давайте компиляции расширение AOP статически. Скачать исходный код из PECL , и распакуйте его в папку, в ext . Затем выполните следующие действия:

Cd C:\PHP-Dev\php5.4 buildconf --force configure --enable-aop nmake

Опцией --force, buildconf сила ей восстановить конфигурационный скрипт. Затем, запустите configure --help и вы должны увидеть вариант включить новое расширение на выходе. В этом случае, это --enable-AOP.

Когда nmake finishes заканчивается, вы должны будете недавно построенный PHP двоичный PHP с AOP.

Расширения будут доступны как DLL, а не испеченный в PHP, вы можете выполнить те же действия, что и выше, но определять "shared" (общие) в качестве значения для настройки, позволяет вариант.

Buildconf --force configure --enable-aop=shared

В результате DLL будет в папке Release_TS вместе с двоичным PHP компиляция закончится, в данном случае имя php_aop.dll .

P.S.

Компиляция в Windows, все еще ​​немного сложна, особенно когда дело доходит до расширения. Возможность компилировать исходный код хороший навык, особенно если впоследствии вы захотите изменить PHP.

Статья подготовлена для вас, коллективом сайта
Оригинал статьи:
Перевел: Виктор Клим

Алексей Романенко: Меня зовут Алексей Романенко, я работаю в компании РБК. Тема этого доклада несколько спорна. Казалось бы, зачем компилировать скрипты PHP, когда вроде и так все работает?

Наверное, основной вопрос: «Зачем?» В общем-то, цель этой презентации - попытаться понять, нужна ли такая компиляция, если да, то зачем, в каком виде и кому.

Что такое компилятор PHP?

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

Первый функциональный модуль - так называемый SAPI (Server API), который предоставляет интерфейс для доступа к PHP из различных клиентов (Apache, какой-то сервер CGI (Common Gateway Interface) и прочие). Есть еще SAPI embedded, который позволяет встроить PHP в какое-либо приложение.

Вторая основная часть - это PHP Core, который обрабатывает запросы, реализует всю работу с сетью, файловой системой и парсингом самих скриптов.

Третья глобальная часть - это Zend Engine, который компилирует наши скрипты в некий байт-код, выполняет его на своей виртуальной машине и занимается управлением памятью (реализует всесторонние аллокаторы).

Одна из самых важных и больших частей - это модуль расширений (англ. Extentions), который реализует 99 % того, что мы используем в PHP. Это либо "обертки" для каких-то библиотек, либо функционал, либо классы, встроенные библиотеки и прочее. Также мы можем писать свои расширения.

Как выполняется сам скрипт?

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

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

В конце Zend Engine его выполняет. Результат отдается обратно клиенту.

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

Но решения есть. Они давно известны.

Как добиться ускорения?

Самое простое, дешевое и хорошо опробованное решение - это кэширование байткода. Вместо того, чтобы проводить фазы парсинга, синтаксического анализа, мы просто кэшируем наш байткод. Для этого есть специальные расширения, - они хорошо знакомы всем, кто работал с PHP, - это APC, eAccelerator, Xcache и так далее. Zend Engine просто выполняет байткод.

Второй вариант - это профилирование кода, выявление узких мест. Мы можем что-то переписать в виде расширений PHP (это будет расширение на C/C++) скомпилировать это и использовать в качестве модулей.

Третий вариант более глобальный - забыть про PHP и все переписать. В общем-то, вариант имеет право на жизнь, но только в том случае, когда php-кода мало. В больших, крупных проектах (или которые существуют довольно долгое время) его обычно скапливается много, и все переписывать будет долго. Бизнес-требования вам не позволят это сделать. В общем-то, писать что-то на PHP, например, для сервера front-end не слишком долго, потому что это простой язык. Он позволяет быстро делать то, что на низкоуровневых языках делать дольше.

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

Давайте что-нибудь скомпилируем?

Под словом «компиляция» я буду понимать перевод кода скрипта PHP во что-либо еще, в какой-то другой код.

В данном случае это может быть два вида.

Нативный код (англ. Native code) - это некий бинарный файл, который можно выполнить на физической машине.

Ненативный код (англ. Non-native code). Можно скомпилировать некий байт-код, который можно выполнить на другой виртуальной машине, например, на JVM.

С помощью чего можно скомпилировать нативный код из PHP?

Компилятор Roadsend. Его продолжение - Raven. Есть еще PHC (это PHP Open Source компилятор). В последнее время появился еще HipHop (Facebook).

Дам небольшой обзор того, что можно сделать для ненативного кода. Насколько я знаю, есть 3 рабочих варианта. Это генерация байт-кода для Java и генерация байт-кода для.Net: Quercus, Project Zero, Phalanger. Компиляцию в ненативный код я рассматривать не буду, потому что мы ее не используем. Вернемся к компиляции в нативный код.

На мой взгляд, самый старый компилятор - это Roadsend. Он начал разрабатываться довольно давно, в 2002-м году. Изначально это было коммерческое приложение. Оно было закрытым, только в 2007-м году оно вышло в Open Source. Там очень сложная схема компиляции: используется некий компилятор Bigloo для языка Scheme, после этого генерируется нативный код. Этот компилятор не использует Zend Engine.

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

Работа над Roadsend, насколько я знаю, сейчас не ведется. Он переродился в проект Raven, который был полностью переписан на C++. В качестве компиляции он использует LLVM для генерации кода.

На данный момент все выглядит очень перспективно.

Но он пока в стадии создания. Даже в документации есть намеки на то, что бинарники мы не сгенерируем. Ждите.

Все было бы грустно, если бы у нас не было PHC. Это OpenSource-компилятор. Он разрабатывается с 2005-го года. Один из его минусов: он использует встроенный SAPI. Мы не отказываемся от Java-машины, от Zend Engine. По сути, он переводит код PHP в код модуля расширений для PHP. После этого он компилируется, но процесс выполнения, опять же, задействует Zend Engine.

Пример использования PHC

Очень похоже на то, как мы работаем, например, с обычными компиляторами, gcc. Первый показывает, что есть один бинарник, также мы можем просто сгенерировать код на "Си". Так как внутри после генерации этого кода используется тот же gcc, мы можем использовать те флаги, которые предназначены для оптимизации и прочего.

Речь шла о приложении, которое работает в командной строке (англ. command line).

Для запуска веб-приложения нужно выполнить несколько действий, это довольно сложно. Сначала нужно сгенерировать расширение (англ. Extention), потом скомпилировать код, а затем каким-либо образом (либо динамически, либо статически) его подключить.

Основные преимущества PHC

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

Кстати, один из дополнительных бонусов PHC - можно сгенерировать XML-работу нашего скрипта на основе того, как строится XML, иногда это может быть полезно.

Минусы

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

О главном

Наверное, этого доклада бы не было, если бы не появился HipHop, решение от Facebook. Его создатели тоже накопили большой объем PHP-кода и долго думали, что с ним делать.

Я так понимаю, что после того как варианты все переписать были отвергнуты, было принято решение написать некий транслятор (в данном случае в код C++). Проект сравнительно молодой, официально он вышел только в феврале этого года. PHP-код транслируется в код C++, а затем генерируется стандартными средствами вашей операционной системы. Правда, пока поддерживается только операционная система Linux.

Как раз вчера я спрашивал об этом решении представителя Facebook. Он сказал, что на данный момент 100 % PHP-кода компилируется через HipHop. В чистом виде через интерпретатор PHP код не работает. Опять же, создателями было заявлено существенное снижение загрузки по процессору.

Основной функционал HipHop

Он генерирует непосредственно сам бинарник, который можно будет выполнять в командной строке. Есть такой вариант его запуска, как потоковый веб-сервер. Также присутствует отдельный встроенный отладчик (англ. debugger). Им можно отлаживать скрипты как локально, так и удаленно (он будет работать в качестве сервера).

Процесс сборки довольно нетривиален. Описание есть, но оно собирается не везде. На данный момент, как я и говорил, все собирается под Linux, плюс изначально все было "заточено" под 64 бита. Хотя сейчас экспериментально поддерживается 32 бита. Но мне удалось собрать и немного пропатчить - в общем-то, он все это делал, потому что по умолчанию оно не собирается.

К тому же у них свои версии libcore и, по-моему, есть пара библиотек, которые тоже нужно патчить. В общем, процесс сборки не так уж прост.

На выходе после сборки мы получаем некий файл hphp, который является транслятором нашего кода PHP в C++. Если мы посмотрим на флаги, то их довольно много. Я выделил тут несколько основных, которые могут понадобиться.

В качестве конфигурационного файла (config) мы можем использовать файл в формате HDF, задавая различные директивы. Мы можем устанавливать там уровень ошибок и прочего (HDF - это все, что имеется в структурированном виде). Также сам config мы можем брать из базы данных либо использовать непосредственно в командной строке.

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

Очень полезная директива - input_list=FILE, которая позволяет нам указать список скриптов, которые мы хотим скомпилировать. Также стоит упомянуть такую директиву, как lazy-bind. Мы можем указывать все файлы проекта - те, которые будут компилироваться.

Пример запуска компиляции PHP-скрипта

Поставлен третий уровень логирования, здесь довольно-таки общая информация по времени, можно посмотреть сколько что заняло. На самом деле, скрипт довольно простой. Это обычный “Hello, World”, просто я сделал снимок экрана.

Самый "тяжелый" файл - это наш бинарник "program", его размер 28 Мб. По сути, наш "Hello, World" весит 28 Мб. Я хотел заметить, что кроме стандартной строчки "Echo "Hello, World!", этот бинарник включает в себя еще много чего другого. Это полноценный веб-сервер, полноценный сервер для администрирования.

Что у нас получается?

Мы имеем "Hello…" на C++, который выполняет функцию, состоящую из одной строчки "echo "Hello, World". К тому же, грузится масса всего стороннего. Как мы видим, это полноценный файл на C++.

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

Это --mode, это режим запуска нашей программы. Мы можем запускать ее как напрямую (из командной строки), так и в режиме веб-сервера или полноценного демона. Есть еще пара вариантов, но они несущественны.

Используется config в том же формате. Я не стал приводить директивы, потому что их очень много. В комплекте с HipHop поставляется документация. На сайте wiki ее нет, но с дистрибутивом предоставляется документация, где все понятно описано. Я даже не ожидал, что описание будет таким подробным Это позволяет довольно гибко конфигурировать решение.

Для запуска в режиме сервера мы можем указывать порт. Для администрирования используется отдельный порт, куда можно складывать какие-то запросы, которые позволяют управлять сервером. Если у нас запущен сервер отладки, то указываем хост и порт, куда будем "биндиться" для проведения отладки.

Пример запуска

Например, мы указали для транслирования порт 9999. Выполняя простые http-запросы, мы можем получать либо статистику, либо каким-то образом управлять сервером, либо получать какую-то дополнительную информацию. В общем-то, это очень удобно.

Вариант получения сведений о состоянии

Имеется возможность получать статус-набор сервера, в различных встроенных форматах (xml, json, html). По сути, предоставляется информация о самом мастер-процессе сервера и обработчиках - потоках, которые обрабатывают запросы.

Дополнительная статистика

На самом деле, предоставляется очень много статистики. Поскольку HipHop изначально работает с memcache и SQL в виде MySQL, он предоставляет подробную информацию по всем операциям, которые производятся с ним.

Полная статистика работы с памятью

Тут очень полезная фишка - Application Stats. Используя дополнительные функции самого HipHop в PHP, мы можем в наших скриптах писать статистику, которую мы потом получаем через обычный доступ в http.

Отладка

Как я уже говорил, есть возможность использовать встроенный "debug" для отладки скриптов. Это очень удобно, потому что интерпретатор hphpi работает аналогично тому, что у нас скомпилировано. Есть отличие в "поведении" скриптов, когда они выполняются на стандартном PHP и при использовании каких-то данных из скомпилированных. Чтобы выполнить отладку того, что скомпилировано, в Facebook написали отдельный интерпретатор.

В первом случае запускаем код с ключом “-f” и смотрим, как ведет себя файл; весь вывод идет по stdout. Либо мы можем запустить его в режиме отладки и попасть в интерактивный отладчик. Он очень похож на стандартный GDB: также можно ставить точки останова (англ. breakpoints), запускать, вводить значения переменных, отслеживание и прочее.

Одна из дополнительных возможностей

У нас есть программа, которая получилась после компиляции. Ее можно использовать в качестве RPC-сервера. Мы запускаем запросы по http, и, вызывая функцию params, мы можем передать параметр в виде либо json-массива, либо отдельный параметр. У нас будет возвращаться json, который возвращает результаты этих функций. Это очень удобно, - нужный функционал уже встроен изначально.

Минусы HipHop

На данный момент в HipHop не поддерживаются такие языковые конструкции и функции, как eval(), create_function() и preg_replace() с /e, хотя все это является аналогом eval(). Правда, в последних релизах, по-моему, все-таки можно включить eval() через config. Но не рекомендуется так делать. Вообще eval() использовать плохо.

Основные плюсы HipHop

Конечно же, основной плюс - есть поддержка со стороны Facebook. Это работает и довольно-таки активно развивается. Складывается сообщество разработчиков вокруг этого проекта. Написана полностью новая реализация PHP.

Как я уже говорил, плюс в том, что генерируется нативный код. Заявлен прирост производительности путем снижения затрат на загрузку процессора (тесты подтверждают это).

Он довольно гибок в конфигурации. Я был приятно удивлен тем, что предусмотрено довольно много параметров для настройки. Я думаю, это связано с тем, что проект реально работает. Все, что используется, инкрементировано.

Как я уже упоминал, HipHop предоставляет довольно много дополнительных возможностей. Среди них использование в качестве RPC-сервера, администрирование, различная статистика и еще много всего. Кстати, есть и API для работы с другими языками.

Для этого решения написана довольно-таки неплохая документация. Еще одно преимущество: это решение, реально готовое к использованию в продакшн (пример - Facebook).

Минусы

Основной минус - на данный момент поддерживается довольно ограниченный ряд модулей. Например, при работе с базой данных мы можем использовать только функции работы с MySQL. Здесь нет поддержки PostgreSQL.

Существует и такой момент, как сложность сборки, о которой я уже упоминал. Есть проблемы со сборкой на 32-битных системах. Но это, думаю, в скором времени будет исправлено. Пока что используется только компиляция из PHP 5.2. Версия 5.3 пока не поддерживается, но будет поддерживаться, как обещают.

Что не стоит ожидать от компиляции вообще и от HipHop в частности?

Компиляция ни в коем случае не ускорит ваши медленные SQL-запросы в базе данных. Если узкое место - это база, то компилируй ее или не компилируй, толку от этого не будет.

Компиляция не ускоряет загрузку статики, только по динамике. Она значительно осложняет отладку. Наверное, многие привыкли, что в PHP довольно просто все отлаживается. При компиляции такое уже не пройдет. Хотя, как я отмечал, Facebook по возможности упростил этот процесс, без этого было бы еще сложнее - каждый раз компилировать.

Не стоит ждать, что это какая-то «серебряная пуля», которая решит все ваши проблемы. На самом деле, компиляция решает довольно узкий круг проблем. Если они есть, то это может помочь.

Какие проблемы решает компиляция?

Она дает снижение нагрузки на ЦП, так как при активной работе с PHP при большом количестве запросов нагрузка на него возрастает довольно сильно. Конечно, хотелось бы провести какие-то тесты.

Тестирование

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

Нагрузка полностью ложится на процессор. Тест показал, что HipHop "выиграл" у всех: он работает почти в полтора раза быстрее, чем стандартный PHP-компилятор. PHC прошел этот тест очень медленно.

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

HipHop снова был впереди. Причем со стандартным PHP разница по времени примерно в 3 раза. PHC здесь показал себя лучше, но примерно в два раза хуже, чем HipHop.

В основном PHP используется для потоков, в которых обрабатываются http-запросы, - об этом стоит помнить.

Несколько стандартных конфигураций (Apache с PHP, Nginx с fpm-php и с подключаемым APC для кэширования кода). В качестве пятого варианта - HipHop.

Тесты я, честно говоря, проводил не на сервере, а на ноутбуке. Цифры, конечно, могут не вполне соответствовать действительности, но в данном случае результаты нормальные. Стоит обратить внимание, что с увеличением нагрузки одновременно растет количество запросов и общее количество запросов. Дальше - RPS. Тестировалась стандартная страничка, которая включает в себя 10 каких-то простых включений. По сути, это тестирование PHP в роли интерпретатора.

Вопрос из зала: Что такое цифры в ячейке - секунды?

Алексей Романенко: Это fps.

Здесь можно сделать вывод о том, что с увеличением количества одновременных запросов HipHop ведет себя очень хорошо.

Видно, что использование APC - это в стандартная практика. Она показывает, что добавляет, например, в качестве Apache прирост производительности примерно в 2 раза. С Nginx такое тоже есть. Но то, что Nginx медленный, не говорит о том, что эта связка хуже. Просто конкретный тест. Если мы здесь будем реально тестировать, то Apache "умрет" на медленных запросах.

Наверное, хочется понять, нужно нам это или нет.

Когда стоит задумываться о компиляции?

Скорее всего, это нужно в том случае, когда мы видим, что наше узкое место - это ЦП. Если мы "упираемся" в ЦП, используя PHP как стандартный интерпретатор, наверное, стоит задуматься о том, что, возможно, часть проекта можно будет скомпилировать.

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

Снижение количества серверов. Когда серверов много, то снижая производительность в 2 раза, грубо говоря, количество мы тоже снижаем в два раза. Когда это один сервер, смысла нет, но когда их 100-200, то, наверное, смысл есть.

Основная причина, по которой Facebook стал использовать HipHop, - это наличие больших объемов PHP-кода, который нет возможности переписывать (или некому, или просто затратно). Увеличение производительности в 2 раза - это уже неплохо.

Наверное, все. Жду вопросов.

Вопросы и ответы

Вопрос из зала: Здравствуйте. Скажите, пожалуйста, есть ли у вас еще примеры удачных внедрений Hiphop, кроме Facebook. Не хотели бы вы перевести сайт РБК, к примеру, на HipHop? Алексей Романенко: Начну со второго. Сайт РБК перевести сложно. По поводу успешного внедрения. Я сам компилировал PHP Unit, он удачно скомпилировался. Также, насколько я знаю, удачно компилируется PHP Bunty board. Ряд организаций, на самом деле, уже использует компиляцию. Дальнейшие тесты покажут, насколько оправданно будет использовать этот проект. Вопрос из зала: Можете привести пример организации, которая ее использует? Алексей Романенко: Честно говорю, сейчас я вам не скажу, но это Запад. Насколько я знаю, у нас никто не использует. Вопрос из зала: В чем отличие во время выполнения, кроме отсутствия поддержки некоторых функций, о которых вы сказали. Насколько опасно переводить "живой" проект? Алексей Романенко: Отличие - любая компилируемая программа может "упасть". Возможно, какие-то неполадки появятся, которые еще не выявлены. На самом деле, есть ряд отличий в "поведении" самого PHP. Я не стал их приводить, потому что более подробную информацию можно получить в документации. Команда Facebook написала свой интерпретатор, который, по сути, на 99,9 % эквивалентен тому, который будет работать в скомпилированном виде. Тестировать ваш код лучше не стандартным PHP-интерпретатором, а, как я говорил, hphpi для PHP.

Почти все разработчики рано или поздно сталкиваются с необходимостью запустить или быстро проверить какой-то код, но не все знают, что для такой простой задачи совсем не обязательно запускать тяжёлые десктопные IDE или прикладные компиляторы. Достаточно воспользоваться онлайн-инструментами, которые позволяют всё сделать намного быстрее: Ctrl+C, Ctrl+V, Run, вжух - и вывод программы уже перед вашими красноватыми глазами.

Мы отобрали лучшие онлайн-компиляторы: некоторые из них довольно универсальны, другие заточены под строго определённые задачи. В любом случае лишними они не будут.

Koding

Koding.com не является онлайн-компилятором в привычном смысле. Каждый пользователь сервиса может создать в облаке несколько полноценных виртуальных машин под управлением Ubuntu 14.04, на которых может сделать всё, что пожелает, в том числе - скомпилировать код. Все популярные языки поддерживаются по умолчанию, но вы с лёгкостью сможете добавить свои.

Кроме панели управления своим сервером, в интерфейсе доступна удобная IDE и окошко терминала. Koding является самым универсальным средством, далее мы рассмотрим более простые и специализированные варианты.

IdeOne

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

Для тех, у кого нет девушки, создатели предусмотрели компиляцию кода на языке Brainfuck.

JDoodle

Ещё один онлайн-компилятор, который поддерживает множество языков, в том числе и тех, которые вы не найдете во многих других онлайн-компиляторах. Приятной особенностью JDoodle является возможность совместной работы - просто отправьте ссылку на вашу текущую сессию и плодите баги с двойной скоростью!

jsFiddle

Пусть название вас не обманывает - jsFiddle создан не только для JavaScript. Этот онлайн-редактор для фронтенда позволяет проверить любое сочетание JavaScript, HTML и CSS. Разумеется, есть поддержка разных фреймворков, например, jQuery, Vue, React, TypeScript, а также CSS-препроцессоров вроде SCSS. Для удобства вы можете выбрать привязку клавиш из любимого редактора. Правда, только в том случае, если ваш любимый редактор - Vim, Emacs или Sublime Text.

CodePad

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

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

Из минусов можно назвать полное отсутствие подсветки синтаксиса при вводе кода в форму. Впрочем, при просмотре уже сохранённой записи подсветка присутствует.

GCC GodBolt

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

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