Компютърни уроци

Селекция от онлайн компилатори: изпълняваме и тестваме кода директно в браузъра. Пример за изпълнение на компилация на PHP скрипт

Всички безплатни PHP компилатори, които са представени тук, могат да пресъздадат PHP скриптове в машинен код, който може да се изпълнява на компютър, без да изтеглят специален PHP интерпретатор, или да ги компилират в интерфейс на команден ред с байт код (NET или Mono framework или Java байт код са необходими за инсталиране ( където за инсталиране е необходима виртуална машина на Java)).

Такива компилатори могат да бъдат полезни за различни цели: те могат да ускорят изпълнението на вашия скрипт, защото вече не се интерпретират по време на изпълнение; или благодарение на тях можете да разпространявате вашите приложения, без да разкривате изходния код (което изискват други комерсиални скриптове). Предполагам, че те са подходящи и за случая, когато някой иска да напише уеб-зависими PHP програми и да ги разпространява с функционалността да работят на работния плот (за разлика от обикновените уеб приложения, които се изпълняват на сървър), всичко това е възможно, защото това PHP е лесен за научаване език за програмиране и основно съдържа много вградени функции с достъп до Интернет. (В този случай ще трябва или да разпространявате приложения с вграден уеб сървър, или да използвате компилатор, който компилира сървъра във вашето приложение.)

Между другото, ако искате да използвате обфускация във вашия код, тогава знайте, че това е възможно и при използване PHP ускорител. Такива ускорители също предполагат увеличаване на скоростта на изпълнение на вашия скрипт.

Полезна информация за тези, които все още не знаят, че официалната версия на PHP преводача може да бъде изтеглена от уебсайта на PHP: Хипертекстов процесор.

Безплатни PHP компилатори за композиране на собствен код, .NET или Java байт код скриптове.

Бамбалам (нов)

Тази програма създава самостоятелни Windows EXE приложения за вашия PHP изходен код. Това всъщност не е компилатор на естествен код, тъй като той просто кодира изходния код и вгражда PHP интерпретатор, но със сигурност е подходящ за хора, които търсят компилатори на естествен код и компилатори на байт код. По времето, когато цялата програма беше написана, нейната среда за изпълнение беше вградената версия на PHP 4.4.4 (програмата не беше актуализирана от 2006 г.). Изходният код за Bambalam е публично достъпен.

Phalanger (за .NET)

Phalanger компилира вашия PHP код в CLI байт код (.exe или .dll). Тази програма може да се изпълнява през .NET 4.0 или Mono frameworks. Вашият PHP код може да използва всякакви .NET обекти и допълнителни стандартни библиотеки за разширения на PHP. Полученият NET монтаж може да бъде подписан или скрит. Програмата също така създава шаблони, които ви позволяват да създавате PHP приложения с помощта на Visual Studio. Програмата е пусната под лиценз Apache.

HipHop за PHP (за естествен код)

HipHop превежда вашия PHP код в C++ код, който по-късно се компилира с помощта на GNU C++ компилатора в изпълним двоичен код. Компилаторът поддържа всички функции на PHP 5.3 (с изключение, разбира се, на неща като оценка ()). Работи и компилира код за 64-битов Linux и FreeBSD. Тъй като програмата се разпространява под формата на изходен код, ще трябва да компилирате ръчно (сами). Пуснат е под PHP лиценз.

Roadsend PHP (за собствен код).

Компилаторът Roadsend PHP създава собствени двоични файлове (изпълними) за Windows и Linux. Вашите скриптове не са ограничени до конзолни програми (командни редове): те могат да бъдат изградени с помощта на вградени уеб сървъри, което им позволява да се изпълняват по същия начин, по който се изпълняват на уебсайт, макар и на вашата собствена потребителска система. Компилаторът е издаден под GNU GPL лиценз и работи под GNU LGPL. За съжаление, програмата е спряла активното си развитие.

Project Zero (за Java)

(Забележка: Този софтуер изглежда нефункциониращ. Сайтът е недостъпен от около половин година.) Project Zero включва компилатор и CLR, които могат да компилират вашия PHP код в Java байткод и да го изпълняват. Обърнете внимание, че Project Zero е нещо повече от PHP компилатор/време за изпълнение; предоставя богата рамка, която ви позволява да подобрявате уеб приложенията с помощта на PHP или Groovy (друг скриптов език). Този компилатор е наличен за Windows, Mac OS X и Linux. За да работите с този компилатор, ще трябва да изтеглите Java Development Kit.

Кой от предложените компилатори предпочитате? Или имате друг любим преводач? Оставете вашите забележки и коментари по-долу, ние ще се радваме да ги прочетем и да ги навием.

Тагове: PHP компилатори, превод на скриптове

Има два вида езици за програмиране: интерпретирани и компилирани. Какъв език е PHP? За да отговорим на този въпрос, трябва да разберем терминологията.

Програма, която превежда код, написан на един програмен език на друг, се нарича преводач. Компилаторът също е преводач. Той превежда код, написан на език от високо ниво, в машинен код. Процесът на компилиране създава двоичен изпълним файл, който може да се изпълнява без компилатор.

Преводачът е съвсем друга категория. Интерпретаторът не превежда кода, а го изпълнява. Интерпретаторът анализира програмния код и изпълнява всеки ред от него. Всеки път, когато изпълнявате такъв код, трябва да използвате интерпретатор.

По отношение на производителността интерпретаторите са значително по-ниски от компилаторите, тъй като двоичният код се изпълнява много по-бързо. Но интерпретаторите ви позволяват напълно да контролирате програмата по време на нейното изпълнение.

Що се отнася до PHP, той не е нито компилатор, нито интерпретатор. PHP е кръстоска между компилатор и интерпретатор. Нека се опитаме да разберем това и да разгледаме как PHP обработва кода.

Да погледнем снимката:

Виждаме, че PHP е съставен от два почти независими блока - преводач и интерпретатор. Защо трябваше да правиш това? Разбира се, от съображения за бързина.

Входът на PHP е скрипт. Той го превежда (превежда), като проверява синтаксиса, в специален байт код (вътрешно представяне). След това PHP изпълнява байт кода (не самия програмен код), но не създава изпълним файл.

Байт кодът е много по-компактен от обикновения програмен код, така че е по-лесен (и по-бърз) за интерпретиране (изпълнение). Съдете сами: анализът се извършва само веднъж на етапа на превод и се изпълнява „полуготов продукт“ - байт код, който е много по-удобен за тези цели. Следователно PHP е повече интерпретатор, отколкото компилатор. Тази „двойна работа“ беше необходима за следните цели.

Помислете за цикъла:

За (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 скриптовете започнаха да работят много по-бързо, тъй като PHP версия 4 (и PHP5) е интерпретативен преводач.

Езикът Perl, който почти винаги се нарича компилатор, работи по абсолютно същия начин - той превежда текста на програмата във вътрешно представяне и след това използва получения код по време на изпълнение. И така, можем да кажем, че PHP версия 4 е компилатор по абсолютно същия начин, по който е Perl.

И така, ние сме принудени да заключим, че PHP е интерпретатор с вграден блок за превод, който оптимизира потока на интерпретация.

Използването на интерпретатор (и следователно PHP) има своите неоспорими предимства:

  • Няма нужда да се притеснявате за освобождаването на разпределената памет, няма нужда да затваряте файлове, когато приключите работата с тях - интерпретаторът ще свърши цялата рутинна работа, тъй като програмата се изпълнява под негов зорък контрол;
  • Няма нужда да мислите за типовете променливи и няма нужда да декларирате променлива преди първата й употреба;
  • Дебъгването на програми и откриването на грешки е значително опростено - интерпретаторът има пълен контрол над този процес;
  • В контекста на уеб приложенията интерпретаторът има и много важно предимство - няма опасност сървърът да „замръзне“, ако програмата не работи правилно.

Има и други предимства. Като цяло използването на интерпретатор може да даде на скриптовете силата, която уеб потребителите очакват от тях.

Наказанието за производителност на PHP е забележимо в случай на големи и сложни цикли, при обработка на голям брой редове и т.н. Все пак имайте предвид, че това е единственият недостатък на PHP, който ще се появява все по-малко и по-малко с пускането на по-мощни процесори , така че в крайна сметка да изчезнат напълно.

<<< Назад
(Какво е новото в PHP5?)
Съдържание Напред >>>
(Преход към PHP 5.3)

Ако имате други въпроси или нещо не е ясно - заповядайте при нас

PHP е интерпретиран език за програмиране; с всяка заявка изходният код се анализира и „изпълнява“. Този подход, разбира се, е много удобен на етапа на разработване на проекта, но въвежда допълнителна стъпка в процеса на изпълнение на производствен код. По този начин интерпретацията, която на пръв поглед е силната страна на PHP, коства допълнително време и ресурси на процесора.

По-долу ще говорим за компилатори, които ви позволяват да компилирате PHP код в C++ и него в изпълним код. Така PHP приложенията се изпълняват директно от процесора, заобикаляйки интерпретатора.

Нека проверим дали всичко е толкова добро на практика.

Как работи преводачът

Интерпретацията на PHP кода се извършва на два етапа:

  1. Разбор на код и генериране на кодове за операции (Zend кодове за операции) - инструкции, разбираеми за интерпретатора.
  2. Изпълнение на кодове за операции.

Докато първата фаза се поддава добре на оптимизация (използване на кеш на операционния код), втората е доста затворена - интерпретаторът винаги е посредник между набора от инструкции и процесора, който ги изпълнява. Без интерпретатор процесорът не може да разбере какво да прави с кодовете за операции.

За да се отървете от връзката на интерпретатора, бяха изобретени компилатори, най-популярният и нов от които е HipHop от Facebook. Нека го усетим по-близо.

Хип-хоп PHP

HipHop е написан от разработчици на Facebook и е приложение, което:
  1. оптимизира PHP кода
  2. преобразува в C++
  3. генерира от вашето приложение многонишков уеб сървър, който го изпълнява
  4. компилира в изпълним код с помощта на g++

Така входът е PHP код, изходът е сървър, част от който е написаната функционалност.

Нека проверим как HipHop може да се справи с компилирането на приложение, написано с помощта на рамка, като Wordpress.

Компилиране на Wordpress

След като инсталираме HipHop, в папката src/hphp/ ще получим hphp файла, който е компилаторът. Преди да започне компилацията, задайте променливите на средата:

Cd .. # отидете в папката с hiphop export HPHP_HOME=`pwd` export HPHP_LIB=`pwd`/bin export CMAKE_PREFIX_PATH=`/bin/pwd`/../

и давай напред!

Изтеглете Wordpress и разархивирайте архива:

Wget http://wordpress.org/latest.tar.gz tar zxvf latest.tar.gz

Копирайте wp-config-sample.php в wp-config.php и задайте настройките за свързване към базата данни (в настройките на хоста посочваме 127.0.0.1, а не localhost).

За успешна компилация трябва малко да закърпите Wordpress:

  1. Отворете wp-includes/js/tinymce/plugins/spellchecker/classes/SpellChecker.php и заменете: функция &loopback(/* args.. */) ( return func_get_args(); ) с функция &loopback(/* args.. */ ) ( $ret = func_get_args(); върне $ret; )
  2. В wp-includes/query.php, вместо if (!isset($q["suppress_filters"])) $q["suppress_filters"] = false; вмъкнете $q["suppress_filters"] = вярно;

Wordpress е готов.

Hiphop трябва да уточни списъка с файлове, които ще компилираме - ще го получим и запазим във files.list:

Намирам. -име "*.php" > files.list

Всичко е готово за компилация, нека продължим:

$HPHP_HOME/src/hphp/hphp --input-list=files.list -k 1 --log=3 --force=1 --cluster-count=50

След като изпълним командата, във временната папка (в началото на компилацията hphp ще покаже своя път, нещо като “/tmp/hphp_ptRgV1”) ще получим компилиран уеб сървър. Нека го стартираме (ако нещо виси на порт 80, например apache или nginx, първо трябва да го спрете, за да освободите порта):

Sudo /tmp/hphp_6s0pzd/program -m сървър -v "Server.SourceRoot=`pwd`" -v "Server.DefaultDocument=index.php" -c $HPHP_HOME/bin/mime.hdf

Ето! Отивайки на http://localost, ще видим работещ блог на Wordpress.

производителност

Да видим дали ще има увеличение на производителността в сравнение с некомпилираната версия на WordPress, работеща на apache2. По-долу има графики на зависимостта на скоростта на генериране на страници от броя на паралелните потребители.

Както можете да видите, резултатите бяха шокиращи: компилираният блог работи средно 6 пъти по-бързо! Средният брой обработени заявки за секунда в некомпилираната версия е 9, а в компилираната е 50! Не знам за вас, но тези резултати ме удивиха; не очаквах толкова силно увеличение на производителността.

Обобщете

След толкова зашеметяващи резултати може да се каже само едно - момчетата от Facebook се справиха страхотно. Компилаторът наистина прави ракета от приложение и въпреки че приложението трябва да бъде подготвено преди компилиране, резултатът си заслужава.

Към основния въпрос:

Ако публикацията ви е харесала, кликнете върху Google +1 - това ще ми даде повече мотивация да пиша и просто ще е удоволствие.

Алексей Романенко:Казвам се Алексей Романенко, работя в RBC. Темата на този доклад е донякъде противоречива. Изглежда, защо да компилирате PHP скриптове, когато всичко изглежда така?

Вероятно основният въпрос е: "Защо?" Като цяло целта на тази презентация е да се опитаме да разберем дали е необходима такава компилация, ако да, защо, под каква форма и за кого.

Какво е PHP компилатор?

Първо, кратък преглед на това какво е PHP компилатор. Ще ви кажа как работи, какво представлява и как можете да го ускорите.

Първият функционален модул е ​​така нареченият SAPI (Server API), който предоставя интерфейс за достъп до PHP от различни клиенти (Apache, някакъв CGI сървър (Common Gateway Interface) и други). Има и вграден SAPI, който ви позволява да вградите 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 скрипт в нещо друго, в някакъв друг код.

В този случай тя може да бъде два вида.

Родният код е вид двоичен файл, който може да бъде изпълнен на физическа машина.

Не-роден код. Можете да компилирате някакъв байт код, който може да бъде изпълнен на друга виртуална машина, например на JVM.

Как можете да компилирате естествен код от PHP?

Компилатор на Roadsend. Неговото продължение е Raven. Има и PHC (това е PHP компилатор с отворен код). Наскоро се появи и HipHop (Facebook).

Ще дам кратък преглед на това, което може да се направи за чуждия код. Доколкото знам има 3 работни варианта. Това е генериране на байт код за Java и генериране на байт код за .Net: Quercus, Project Zero, Phalanger. Няма да обмислям компилиране в чужд код, защото не го използваме. Нека се върнем към компилирането в естествен код.

Според мен най-старият компилатор е Roadsend. Започва да се развива доста отдавна, през 2002 г. Първоначално беше търговско приложение. Беше затворен, едва през 2007 г. беше пуснат в Open Source. Има много сложна схема за компилиране: определен компилатор Bigloo се използва за езика Scheme, след което се генерира собствен код. Този компилатор не използва Zend Engine.

Можем или да генерираме отделен изпълним двоичен файл, или да генерираме модул за Apache. Също така е възможно да се генерира двоичен файл, който ще работи като уеб сървър. Но не става. Не знам защо, но изобщо не ми действа.

Доколкото знам, работата по Roadsend в момента не е в ход. Той се превърна в проекта Raven, който беше напълно пренаписан на C++. Като компилатор, той използва LLVM за генериране на код.

В момента всичко изглежда много обещаващо.

Но все още е в процес на изграждане. Дори в документацията има намеци, че няма да генерираме двоични файлове. Изчакайте.

Нещата щяха да бъдат тъжни, ако нямахме ПЗК. Това е OpenSource компилатор. Разработва се от 2005 г. Един от неговите недостатъци: използва вграден SAPI. Ние не изоставяме Java машината, Zend Engine. По същество той превежда PHP код в код на модул за разширение на PHP. След това се компилира, но процесът на изпълнение отново включва Zend Engine.

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

Много подобно на това как работим, например, с конвенционалните компилатори, gcc. Първият показва, че има един двоичен файл, можем също просто да генерираме C кода. Тъй като същият gcc се използва вътре след генерирането на този код, можем да използваме тези флагове, които са предназначени за оптимизация и други неща.

Говорихме за приложение, което работи от командния ред.

За да стартирате уеб приложение, трябва да изпълните няколко стъпки, доста е сложно. Първо трябва да генерирате разширение, след това да компилирате кода и след това по някакъв начин (динамично или статично) да го свържете.

Основни предимства на ПМЗ

По същество ние използваме същия PHP, ние сме напълно съвместими. Всички други разширения се поддържат. Използваме всичко, което сме компилирали. Доста добра документация.

Между другото, един от допълнителните бонуси на PHC е, че можете да генерирате XML работата на нашия скрипт въз основа на това как е конструиран XML, понякога това може да бъде полезно.

минуси

Според мен това е по-нисък двоичен файл, защото все още има зависимост от Zend Engine. Съществува и известна сложност по отношение на свързването на уеб проекти.

Основното нещо

Този доклад вероятно нямаше да се случи, ако не се появи HipHop, решение от Facebook. Създателите му също натрупаха голямо количество PHP код и дълго време мислиха какво да правят с него.

Доколкото разбирам, след като опциите за пренаписване на всичко бяха отхвърлени, беше решено да се напише някакъв преводач (в този случай в C++ код). Проектът е сравнително млад, той беше официално пуснат едва през февруари тази година. PHP кодът се превежда в C++ код и след това се генерира с помощта на стандартни инструменти на вашата операционна система. Засега обаче се поддържа само операционната система Linux.

Точно вчера попитах представител на Facebook за това решение. Той каза, че в момента 100% от PHP кода се компилира чрез HipHop. Кодът не работи в чист вид чрез PHP интерпретатора. Отново създателите обявиха значително намаляване на натоварването на процесора.

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

Той директно генерира самия двоичен файл, който може да бъде изпълнен от командния ред. Има такава опция за стартиране като стрийминг уеб сървър. Има и отделен вграден дебъгер. Може да отстранява грешки в скриптове както локално, така и отдалечено (ще работи като сървър).

Процесът на сглобяване е доста нетривиален. Има описание, но не е събрано навсякъде. В момента, както казах, всичко е асемблирано за Linux, плюс първоначално всичко беше „пригодено“ за 64 бита. Въпреки че 32 бита вече се поддържат експериментално. Но успях да го сглобя и да го закърпя малко - като цяло направи всичко това, защото не е сглобено по подразбиране.

В допълнение, те имат свои собствени версии на libcore и според мен има няколко библиотеки, които също трябва да бъдат закърпени. Като цяло процесът на сглобяване не е толкова прост.

На изхода след асемблирането получаваме определен hphp файл, който е преводач на нашия PHP код в C++. Ако погледнем знамената, те са доста. Тук подчертах няколко основни, от които може да се нуждаете.

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

Ние задаваме нивото на регистриране по време на компилация: показване на всички грешки или също показване на предупреждения, допълнителна информация или като цяло поддържа пълен регистър на всичко, което се случва.

Много полезна директива е input_list=FILE, която ни позволява да посочим списък със скриптове, които искаме да компилираме. Струва си да се спомене и директива като lazy-bind. Можем да посочим всички файлове на проекта - тези, които ще бъдат компилирани.

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

Инсталирано е третото ниво на регистриране, има доста обща информация за времето, можете да видите колко време е отнело. Всъщност сценарият е доста прост. Това е обичайното „Здравей, свят“, току-що направих екранна снимка.

Най-тежкият файл е нашият „програмен“ двоичен файл, неговият размер е 28 MB. По същество нашето „Hello, World“ тежи 28 MB. Исках да отбележа, че в допълнение към стандартния ред "Echo" Hello, World!", Този двоичен файл включва много повече. Това е пълноправен уеб сървър, пълноправен сървър за администриране.

Какво правим?

Имаме "Hello..." в C++, който изпълнява функция, състояща се от един ред "echo" Hello, World". Освен това се зареждат много неща от трети страни. Както виждаме, това е пълноправен файл в C++.

Това е получената програма. Той вече съдържа доста различни ключове за различни конфигурации, но ще спомена само някои от тях.

Това е --mode, това е режимът на стартиране на нашата програма. Можем да го стартираме или директно (от командния ред), или в режим на уеб сървър или пълноправен демон. Има още няколко опции, но те са маловажни.

config се използва в същия формат. Не съм давал указания, защото са много. HipHop идва с документация. Няма го в wiki сайта, но към дистрибуцията се предоставя документация, където всичко е ясно описано. Дори не очаквах, че описанието ще бъде толкова подробно.Това ви позволява да конфигурирате решението доста гъвкаво.

За да работим в сървърен режим, можем да посочим порта. За администриране се използва отделен порт, където можете да изпращате някои заявки, които ви позволяват да управлявате сървъра. Ако имаме работещ сървър за отстраняване на грешки, тогава посочваме хоста и порта, където ще се „свържем“ за отстраняване на грешки.

Пример за стартиране

Например, за излъчване посочихме порт 9999. Чрез изпълнение на прости http заявки можем да получаваме или статистика, или по някакъв начин да управляваме сървъра, или да получим допълнителна информация. Като цяло е много удобно.

Възможност за получаване на информация за състоянието

Възможно е да получите зададения статус на сървъра в различни вградени формати (xml, json, html). По същество се предоставя информация за самия главен процес на сървъра и манипулаторите - нишки, които обработват заявки.

Допълнителна статистика

Всъщност се предоставят много статистики. Тъй като HipHop работи естествено с memcache и SQL под формата на MySQL, той предоставя подробна информация за всички операции, които се извършват с него.

Пълна статистика на паметта

Тук има много полезна функция - Статистика на приложението. Използвайки допълнителните функции на самия HipHop в PHP, можем да записваме статистики в нашите скриптове, които след това получаваме чрез редовен достъп до http.

Отстраняване на грешки

Както вече казах, възможно е да използвате вградения "debug" за отстраняване на грешки в скриптове. Това е много удобно, защото интерпретаторът на hphpi работи подобно на това, което сме компилирали. Има разлика в "поведението" на скриптовете, когато се изпълняват в стандартен PHP и когато се използват някои компилирани данни. За отстраняване на грешки в това, което е компилирано, Facebook написа отделен интерпретатор.

В първия случай изпълняваме кода с превключвателя „-f“ и виждаме как се държи файлът; целият изход отива към stdout. Или можем да го стартираме в режим на отстраняване на грешки и да влезем в интерактивния инструмент за отстраняване на грешки. Той е много подобен на стандартния GDB: можете също да задавате точки на прекъсване, да изпълнявате, да въвеждате стойности на променливи, да проследявате и др.

Една от допълнителните функции

Имаме програма, която се получи след компилация. Може да се използва като RPC сървър. Изпълняваме заявки през http и чрез извикване на функцията params можем да предадем параметър като json масив или отделен параметър. Ще имаме върнат json, който връща резултатите от тези функции. Това е много удобно - необходимата функционалност вече е вградена от самото начало.

Минуси на хип-хопа

В момента 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. Искате ли да прехвърлите уебсайта на RBC, например, към HipHop? Алексей Романенко:Ще започна с второто. Уебсайтът на RBC е труден за превод. Относно успешното изпълнение. Сам компилирах PHP Unit, компилира се успешно. Освен това, доколкото знам, дъската на PHP Bunty се компилира успешно. Редица организации всъщност вече използват компилация. По-нататъшни тестове ще покажат колко оправдано ще бъде използването на този проект. Въпрос от публиката:Можете ли да дадете пример за организация, която го използва? Алексей Романенко:Честно казано, сега няма да ви кажа, но това е Западът. Доколкото знам, тук никой не го използва. Въпрос от публиката:Каква е разликата по време на изпълнение, освен липсата на поддръжка за някои от функциите, които споменахте. Колко опасно е да се превежда „жив“ проект? Алексей Романенко:Разликата е, че всяка компилирана програма може да се срине. Може би ще се появят някои проблеми, които все още не са идентифицирани. Всъщност има редица разлики в "поведението" на самия PHP. Не ги включих, защото по-подробна информация можете да намерите в документацията. Екипът на Facebook е написал свой собствен интерпретатор, който по същество е 99,9% еквивалентен на този, който ще работи в компилиран вид. По-добре е да тествате кода си не със стандартен PHP интерпретатор, а както казах с hphpi за PHP.