Wszystkie zaprezentowane tutaj bezpłatne kompilatory PHP potrafią przebudować skrypty PHP na kod maszynowy, który można uruchomić na komputerze bez konieczności pobierania specjalnego interpretera PHP, lub skompilować je do interfejsu wiersza poleceń w postaci kodu bajtowego (do instalacji wymagana jest platforma NET lub Mono lub kod bajtowy Java (gdzie do instalacji wymagana jest wirtualna maszyna Java)).
Takie kompilatory mogą być przydatne do różnych celów: mogą przyspieszyć wykonanie skryptu, ponieważ nie są już interpretowane w czasie wykonywania; lub dzięki nim możesz dystrybuować swoje aplikacje bez ujawniania kodu źródłowego (czego wymagają inne komercyjne skrypty). Przypuszczam, że nadają się również w przypadku, gdy ktoś chce pisać programy PHP zależne od sieci i rozpowszechniać je z funkcjonalnością uruchamiania na komputerze stacjonarnym (w przeciwieństwie do zwykłych aplikacji internetowych, które działają na serwerze), jest to wszystko możliwe, ponieważ PHP jest łatwym do nauczenia się językiem programowania i zasadniczo zawiera wiele wbudowanych funkcji z dostępem do Internetu. (W takim przypadku będziesz musiał dystrybuować aplikacje za pomocą wbudowanego serwera WWW lub użyć kompilatora, który wkompiluje serwer w twoją aplikację.)
Nawiasem mówiąc, jeśli chcesz zastosować zaciemnianie w swoim kodzie, wiedz, że jest to również możliwe podczas używania Akcelerator PHP. Takie akceleratory oznaczają również wzrost szybkości wykonywania skryptu.
Przydatna informacja dla tych, którzy jeszcze nie wiedzą, że oficjalną wersję tłumacza PHP można pobrać ze strony PHP: Procesor hipertekstowy.
Darmowe kompilatory PHP do tworzenia kodu natywnego, skryptów kodu bajtowego .NET lub Java.
Bambalam (nowy)
Ten program tworzy samodzielne aplikacje Windows EXE dla kodu źródłowego PHP. Nie jest to tak naprawdę kompilator kodu natywnego, ponieważ po prostu koduje kod źródłowy i osadza interpreter PHP, ale z pewnością jest dobrym rozwiązaniem dla osób poszukujących kompilatorów natywnych i kodów bajtowych. Do czasu napisania całego programu jego środowiskiem wykonawczym była wbudowana wersja PHP 4.4.4 (program nie był aktualizowany od 2006 roku). Kod źródłowy Bambalam jest publicznie dostępny.
Falanger (dla .NET)
Phalanger kompiluje kod PHP do kodu bajtowego CLI (.exe lub .dll). Ten program można uruchomić w środowisku .NET 4.0 lub Mono. Twój kod PHP może wykorzystywać dowolne obiekty .NET i dodatkowe standardowe biblioteki rozszerzeń PHP. Wynikowy zestaw NET może być podpisany lub ukryty. Program generuje także szablony umożliwiające tworzenie aplikacji PHP przy użyciu Visual Studio. Program udostępniany jest na licencji Apache.
HipHop dla PHP (dla kodu natywnego)
HipHop tłumaczy Twój kod PHP na kod C++, który jest później kompilowany przy użyciu kompilatora GNU C++ do wykonywalnego kodu binarnego. Kompilator obsługuje wszystkie funkcje PHP 5.3 (oczywiście z wyjątkiem takich rzeczy jak ewaluacja()). Działa i kompiluje kod dla 64-bitowego Linuksa i FreeBSD. Ponieważ program jest rozpowszechniany w formie kodu źródłowego, będziesz musiał go skompilować ręcznie (samodzielnie). Jest udostępniany na licencji PHP.
Roadsend PHP (dla kodu natywnego).
Kompilator PHP Roadsend tworzy natywne pliki binarne (pliki wykonywalne) dla systemów Windows i Linux. Twoje skrypty nie ograniczają się do programów konsolowych (wierszy poleceń): można je zbudować przy użyciu wbudowanych serwerów internetowych, dzięki czemu mogą działać w taki sam sposób, jak na stronie internetowej, aczkolwiek we własnym systemie użytkownika. Kompilator jest wydany na licencji GNU GPL i działa na licencji GNU LGPL. Niestety program zatrzymał swój aktywny rozwój.
Projekt Zero (dla Java)
(Uwaga: to oprogramowanie wygląda na nieaktualne. Strona jest niedostępna już od około pół roku.) Project Zero zawiera kompilator i CLR, które mogą skompilować kod PHP do kodu bajtowego Java i go uruchomić. Zauważ, że Project Zero to coś więcej niż tylko kompilator/środowisko wykonawcze PHP; zapewnia bogate środowisko, które pozwala ulepszać aplikacje internetowe przy użyciu PHP lub Groovy (inny język skryptowy). Ten kompilator jest dostępny dla systemów Windows, Mac OS X i Linux. Aby pracować z tym kompilatorem, musisz pobrać zestaw Java Development Kit.
Który z proponowanych kompilatorów wolisz? A może masz innego ulubionego tłumacza? Zostaw swoje uwagi i komentarze poniżej, chętnie je przeczytamy i zrecenzujemy.
Tagi: Kompilatory PHP, tłumaczenie skryptów
Istnieją dwa rodzaje języków programowania: interpretowane i kompilowane. Jakim językiem jest PHP? Aby odpowiedzieć na to pytanie, musimy zrozumieć terminologię.
Program, który tłumaczy kod napisany w jednym języku programowania na inny, nazywa się tłumaczem. Kompilator jest także tłumaczem. Tłumaczy kod napisany w języku wysokiego poziomu na kod maszynowy. Proces kompilacji tworzy binarny plik wykonywalny, który można uruchomić bez kompilatora.
Tłumacz ustny to zupełnie inna kategoria. Interpreter nie tłumaczy kodu, ale go wykonuje. Interpreter analizuje kod programu i wykonuje każdą jego linię. Za każdym razem, gdy wykonujesz taki kod, musisz użyć interpretera.
Pod względem wydajności interpretery są znacznie gorsze od kompilatorów, ponieważ kod binarny wykonuje się znacznie szybciej. Ale tłumacze pozwalają na pełną kontrolę programu podczas jego wykonywania.
Jeśli chodzi o PHP, nie jest to ani kompilator, ani interpreter. PHP jest skrzyżowaniem kompilatora i interpretera. Spróbujmy to zrozumieć i przyjrzyjmy się, jak PHP przetwarza kod.
Spójrzmy na zdjęcie:
Widzimy, że PHP składa się z dwóch niemal niezależnych bloków – tłumacza i interpretera. Dlaczego musiałeś to zrobić? Oczywiście ze względu na prędkość.
Dane wejściowe PHP to skrypt. Tłumaczy to (tłumaczy), sprawdzając składnię, na specjalny kod bajtowy (reprezentacja wewnętrzna). Następnie PHP wykonuje kod bajtowy (a nie sam kod programu), ale nie tworzy pliku wykonywalnego.
Kod bajtowy jest znacznie bardziej zwarty niż zwykły kod programu, dlatego łatwiej (i szybciej) interpretować (wykonywać). Oceń sam: parsowanie przeprowadza się tylko raz na etapie tłumaczenia i wykonywany jest „półprodukt” - kod bajtowy, co jest znacznie wygodniejsze do tych celów. Dlatego PHP jest bardziej interpretatorem niż kompilatorem. Ta „podwójna praca” była konieczna w następujących celach.
Rozważ pętlę:
Dla (i=0;tj<10; i++) { Operator_1; Operator_2; Operator_3; ............ Operator_99; Operator_100; }
Cykl ten „obróci się” 10 razy. Dla każdego z tych dziesięciu przejść tłumacz musi 100 linie kodu. Musi przeanalizować i wykonać 10*100 = 1000 linii kodu! Jeśli raz przekonwertujesz całą pętlę na kod bajtowy, będzie ona musiała analizować 10 razy mniej! Oznacza to, że skrypty będą działać 10 razy szybciej!
Okazuje się, że PHP jest.
Główną fazą pracy PHP jest interpretacja wewnętrznej reprezentacji programu i jego wykonanie. To właśnie ta faza zajmuje najwięcej czasu w poważnych scenariuszach. Jednak spowolnienie nie jest aż tak znaczące.
Warto pamiętać, że PHP w wersji 3 było „czystym” interpreterem, a od PHP 4 skrypty zaczęły działać znacznie szybciej, ponieważ PHP w wersji 4 (i PHP5) jest tłumaczem interpretacyjnym.
Język Perl, który prawie zawsze nazywany jest kompilatorem, działa dokładnie w ten sam sposób - tłumaczy tekst programu na jego wewnętrzną reprezentację, a następnie wykorzystuje wynikowy kod podczas wykonywania. Można więc powiedzieć, że PHP w wersji 4 jest kompilatorem dokładnie w taki sam sposób, jak Perl.
Jesteśmy zatem zmuszeni stwierdzić, że PHP jest interpreterem z wbudowanym blokiem tłumaczeniowym, który optymalizuje przepływ interpretacji.
Korzystanie z interpretera (a co za tym idzie PHP) ma swoje niezaprzeczalne zalety:
- Nie ma potrzeby martwić się o zwolnienie przydzielonej pamięci, nie ma potrzeby zamykania plików po zakończeniu pracy z nimi - całą rutynową pracę wykona interpreter, ponieważ program jest wykonywany pod jego czujną kontrolą;
- Nie ma potrzeby myśleć o typach zmiennych i nie ma potrzeby deklarowania zmiennej przed jej pierwszym użyciem;
- Debugowanie programów i wykrywanie błędów jest znacznie uproszczone - interpreter ma pełną kontrolę nad tym procesem;
- W kontekście aplikacji webowych interpreter ma także bardzo istotną zaletę – nie ma niebezpieczeństwa „zamrożenia” serwera w przypadku nieprawidłowego działania programu.
Są też inne zalety. Ogólnie rzecz biorąc, użycie interpretera może zapewnić skryptom moc, jakiej oczekują od nich użytkownicy Internetu.
Spadek wydajności PHP jest zauważalny w przypadku dużych i złożonych pętli, podczas przetwarzania dużej liczby linii itp. Należy jednak pamiętać, że jest to jedyna wada PHP, która będzie pojawiać się coraz rzadziej w miarę wypuszczania mocniejszych procesorów , aby w końcu całkowicie zniknąć.
|
<<< Назад
(Co nowego w PHP5?) |
Treść |
Do przodu >>>
(Przejście na PHP 5.3) |
| Jeśli masz inne pytania lub coś jest niejasne - zapraszamy do naszego serwisu | |
|
|
PHP jest interpretowanym językiem programowania; przy każdym żądaniu kod źródłowy jest analizowany i „wykonywany”. Takie podejście jest oczywiście bardzo wygodne na etapie tworzenia projektu, jednak wprowadza dodatkowy krok do procesu wykonania kodu produkcyjnego. Zatem interpretacja, która na pierwszy rzut oka jest mocną stroną PHP, kosztuje dodatkowy czas i zasoby procesora.
Poniżej porozmawiamy o kompilatorach, które pozwalają skompilować kod PHP do C++, a następnie do kodu wykonywalnego. Zatem aplikacje PHP są wykonywane bezpośrednio przez procesor, z pominięciem interpretera.
Sprawdźmy, czy w praktyce wszystko jest takie dobre.
Jak pracuje tłumacz
Interpretacja kodu PHP odbywa się w dwóch etapach:
- Parsowanie kodu i generowanie opkodów (Zend opcodes) - instrukcje zrozumiałe dla interpretera.
- Wykonywanie rozkazów.
O ile pierwsza faza dobrze nadaje się do optymalizacji (przy użyciu pamięci podręcznej opcode), druga jest dość zamknięta - interpreter jest zawsze pośrednikiem pomiędzy zestawem instrukcji a wykonującym je procesorem. Bez interpretera procesor nie będzie w stanie zrozumieć, co zrobić z kodami operacji.
Aby pozbyć się łącza interpretera, wymyślono kompilatory, z których najpopularniejszym i najnowszym jest HipHop z Facebooka. Poczujmy to bliżej.
Hiphopowy PHP
HipHop został napisany przez programistów Facebooka i jest aplikacją, która:- optymalizuje kod PHP
- konwertuje do C++
- generuje z Twojej aplikacji wielowątkowy serwer WWW, który ją wykonuje
- kompiluje się do kodu wykonywalnego przy użyciu g++
Zatem wejściem jest kod PHP, wyjściem jest serwer, którego częścią jest zapisana funkcjonalność.
Sprawdźmy jak HipHop radzi sobie z kompilacją aplikacji napisanej przy użyciu frameworka takiego jak Wordpress.
Kompilacja Wordpressa
Po zainstalowaniu HipHopa, w folderze src/hphp/ otrzymamy plik hphp będący kompilatorem. Przed rozpoczęciem kompilacji ustaw zmienne środowiskowe:
Cd .. # przejdź do folderu z eksportem hiphopowym HPHP_HOME=`pwd` eksport HPHP_LIB=`pwd`/bin eksport CMAKE_PREFIX_PATH=`/bin/pwd`/../
i śmiało!
Pobierz Wordpress i rozpakuj archiwum:
Wget http://wordpress.org/latest.tar.gz tar zxvf najnowsze.tar.gz
Skopiuj wp-config-sample.php do wp-config.php i określ ustawienia połączenia z bazą danych (w ustawieniach hosta podajemy 127.0.0.1, a nie localhost).
Aby kompilacja przebiegła pomyślnie, musisz trochę załatać Wordpressa:
- Otwórz wp-includes/js/tinymce/plugins/spellchecker/classes/SpellChecker.php i zamień: funkcję &loopback(/* args.. */) ( return func_get_args(); ) funkcją &loopback(/* args.. */ ) ( $ret = func_get_args(); return $ret; )
- W wp-includes/query.php zamiast if (!isset($q["suppress_filters"])) $q["suppress_filters"] = false; wstaw $q["suppress_filters"] = true;
Wordpress jest gotowy.
Hiphop musi określić listę plików, które skompilujemy - pobierzemy ją i zapiszemy w files.list:
Znajdować. -name "*.php" > lista plików
Wszystko jest gotowe do kompilacji, kontynuujmy:
$HPHP_HOME/src/hphp/hphp --input-list=files.list -k 1 --log=3 --force=1 --cluster-count=50
Po wykonaniu polecenia, w folderze tymczasowym (na początku kompilacji hphp pokaże swoją ścieżkę, coś w stylu „/tmp/hphp_ptRgV1”) otrzymamy skompilowany serwer WWW. Uruchommy go (jeśli coś zawiesza się na porcie 80, na przykład Apache lub Nginx, musisz najpierw to zatrzymać, aby zwolnić port):
Sudo /tmp/hphp_6s0pzd/program -m serwer -v "Serwer.SourceRoot=`pwd`" -v "Serwer.DefaultDocument=index.php" -c $HPHP_HOME/bin/mime.hdf
Voila! Wchodząc na http://localost zobaczymy działający blog Wordpress.
Wydajność
Zobaczmy, czy nastąpi wzrost wydajności w porównaniu z nieskompilowaną wersją WordPressa działającą na Apache2. Poniżej znajdują się wykresy zależności szybkości generowania strony od liczby równoległych użytkowników.
Jak widać, wyniki były szokujące: skompilowany blog działa średnio 6 razy szybciej! Średnia liczba żądań przetwarzanych na sekundę w wersji nieskompilowanej wynosi 9, a w wersji skompilowanej 50! Nie wiem jak Wy, ale mnie te wyniki zadziwiły, nie spodziewałem się tak dużego wzrostu wydajności.
Podsumować
Po tak oszałamiających wynikach można powiedzieć tylko jedno – chłopaki z Facebooka spisali się znakomicie. Kompilator naprawdę robi z aplikacji rakietę i chociaż aplikację należy przygotować przed kompilacją, wynik jest tego wart.
Do momentu:
Jeśli post przypadł Ci do gustu, kliknij w Google +1 - da mi to dodatkową motywację do pisania i będzie to po prostu przyjemność.
Aleksiej Romanenko: Nazywam się Alexey Romanenko, pracuję w RBC. Temat niniejszego raportu jest nieco kontrowersyjny. Wydawałoby się, po co kompilować skrypty PHP, skoro wszystko wydaje się tak działać?
Prawdopodobnie główne pytanie brzmi: „Dlaczego?” Generalnie celem tej prezentacji jest próba zrozumienia, czy takie zestawienie jest potrzebne, a jeśli tak, to dlaczego, w jakiej formie i dla kogo.
Co to jest kompilator PHP?
Na początek krótki przegląd tego, czym jest kompilator PHP. Opowiem Ci jak to działa, na czym polega i jak możesz to przyspieszyć.
Pierwszym modułem funkcjonalnym jest tzw. SAPI (Server API), który zapewnia interfejs umożliwiający dostęp do PHP z różnych klientów (Apache, jakiś rodzaj serwera CGI (Common Gateway Interface) i inne). Istnieje również wbudowany SAPI, który pozwala na osadzenie PHP w dowolnej aplikacji.
Drugą główną częścią jest PHP Core, który przetwarza żądania, implementuje całą pracę z siecią, systemem plików i analizuje same skrypty.
Trzecią globalną częścią jest Zend Engine, który kompiluje nasze skrypty do pewnego kodu bajtowego, wykonuje go na swojej maszynie wirtualnej i zajmuje się zarządzaniem pamięcią (implementuje kompleksowe alokatory).
Jedną z najważniejszych i największych części jest moduł Extentions, który implementuje 99% tego, czego używamy w PHP. Są to albo „opakowania” niektórych bibliotek, albo funkcjonalności, albo klasy, biblioteki wbudowane itp. Możemy także napisać własne rozszerzenia.
Jak wykonywany jest sam skrypt?
Pierwszy. Następuje analiza leksykalna – plik jest pobierany, analizowany, wszystkie znaki ze zbioru tego pliku są tłumaczone na pewien zestaw tokenów, z którymi następnie pracujemy.
Faza analizowania analizuje te tokeny. Na podstawie tej analizy tworzona jest pewna struktura gramatyczna, na podstawie której następnie zostanie wygenerowany kod bajtowy.
Na koniec Zend Engine go wykonuje. Wynik jest zwracany klientowi.
Mówimy o dużych obciążeniach. Jeśli za każdym razem będziesz powtarzał ten schemat działań, wszystko będzie działać bardzo powoli. Kiedy nasz tłumacz otrzymuje jednocześnie kilkaset lub tysiące żądań, prędkość po prostu nie istnieje.
Ale są rozwiązania. Są znane od dawna.
Jak osiągnąć przyspieszenie?
Najprostszym, najtańszym i dobrze przetestowanym rozwiązaniem jest buforowanie kodu bajtowego. Zamiast przechodzić przez fazę analizowania, po prostu buforujemy nasz kod bajtowy. Istnieją do tego specjalne rozszerzenia - są one dobrze znane każdemu, kto pracował z PHP - są to APC, eAccelerator, Xcache i tak dalej. Zend Engine po prostu wykonuje kod bajtowy.
Drugą opcją jest profilowanie kodu, identyfikacja wąskich gardeł. Możemy przepisać coś jako rozszerzenia PHP (będzie to rozszerzenie w C/C++), skompilować to i używać jako modułów.
Trzecia opcja jest bardziej globalna - zapomnij o PHP i napisz wszystko od nowa. Generalnie ta opcja ma prawo żyć, ale tylko w przypadku, gdy nie ma wystarczającej ilości kodu PHP. W dużych, dużych projektach (albo takich, które istnieją już dość długo) zwykle gromadzi się tego sporo i przepisanie wszystkiego na nowo zajmie dużo czasu. Wymagania biznesowe nie pozwolą Ci na to. Generalnie napisanie czegoś w PHP np. na serwer front-end nie zajmuje dużo czasu, bo jest to prosty język. Umożliwia szybkie wykonywanie czynności, które zajmują więcej czasu w językach niskiego poziomu.
Istnieje alternatywna opcja, która ostatnio stała się powszechna, a mianowicie skompilowanie gdzieś PHP w coś szybszego.
Skompilujemy coś?
Przez słowo „kompilacja” mam na myśli tłumaczenie kodu skryptu PHP na coś innego, na jakiś inny kod.
W tym przypadku może być dwojakiego rodzaju.
Kod natywny to rodzaj pliku binarnego, który można wykonać na maszynie fizycznej.
Kod nienatywny. Możesz skompilować kod bajtowy, który można wykonać na innej maszynie wirtualnej, na przykład na JVM.
Jak skompilować kod natywny z PHP?
Kompilator Roadsend. Jego kontynuacją jest Raven. Istnieje również PHC (jest to kompilator PHP Open Source). Ostatnio pojawił się także HipHop (Facebook).
Przedstawię krótki przegląd tego, co można zrobić w przypadku kodu innego niż natywny. Z tego co wiem są 3 możliwości pracy. To jest generowanie kodu bajtowego dla Java i generowanie kodu bajtowego dla .Net: Quercus, Project Zero, Phalanger. Kompilacji do kodu obcego nie będę rozważał, bo z niego nie korzystamy. Wróćmy do kompilacji do kodu natywnego.
Moim zdaniem najstarszym kompilatorem jest Roadsend. Zaczęto go rozwijać dość dawno temu, bo w 2002 roku. Pierwotnie była to aplikacja komercyjna. Został zamknięty, dopiero w 2007 roku został wydany w formacie Open Source. Istnieje bardzo złożony schemat kompilacji: dla języka Scheme używany jest określony kompilator Bigloo, po czym generowany jest kod natywny. Ten kompilator nie korzysta z silnika Zend.
Możemy wygenerować oddzielny plik wykonywalny lub wygenerować moduł dla Apache. Możliwe jest również wygenerowanie pliku binarnego, który będzie działał jako serwer WWW. Ale to nie działa. Nie wiem dlaczego, ale w ogóle na mnie to nie działa.
O ile wiem, prace nad Roadsend obecnie nie trwają. Ewoluował w projekt Raven, który został całkowicie przepisany w C++. Jako kompilator używa LLVM do generowania kodu.
Na chwilę obecną wszystko wygląda bardzo obiecująco.
Ale wciąż jest w budowie. Nawet w dokumentacji znajdują się wskazówki, że nie będziemy generować plików binarnych. Czekać.
Byłoby smutno, gdybyśmy nie mieli PHC. To jest kompilator OpenSource. Jest rozwijany od 2005 roku. Jedna z jego wad: wykorzystuje wbudowane SAPI. Nie porzucamy maszyny Java, Zend Engine. Zasadniczo tłumaczy kod PHP na kod modułu rozszerzenia PHP. Następnie kompiluje się, ale w procesie wykonania ponownie uczestniczy Zend Engine.
Przykład użycia PHC
Bardzo podobnie do tego, jak pracujemy na przykład z konwencjonalnymi kompilatorami, gcc. Pierwszy pokazuje, że jest jeden plik binarny, możemy też po prostu wygenerować kod w C. Ponieważ po wygenerowaniu tego kodu użyto tego samego gcc, możemy użyć tych flag, które są przeznaczone do optymalizacji i innych rzeczy.
Mówiliśmy o aplikacji działającej w wierszu poleceń.
Aby uruchomić aplikację internetową, należy wykonać kilka kroków, jest to dość skomplikowane. Najpierw musisz wygenerować rozszerzenie, następnie skompilować kod, a następnie w jakiś sposób (dynamicznie lub statycznie) go połączyć.
Kluczowe zalety PHC
Zasadniczo używamy tego samego PHP, jesteśmy w pełni kompatybilni. Wszystkie inne rozszerzenia są obsługiwane. Używamy wszystkiego, co skompilowaliśmy. Całkiem niezła dokumentacja.
Nawiasem mówiąc, jedną z dodatkowych zalet PHC jest to, że możesz wygenerować pracę XML naszego skryptu w oparciu o konstrukcję XML, czasami może to być przydatne.
Minusy
Moim zdaniem jest to gorszy plik binarny, ponieważ nadal jest zależny od Zend Engine. Istnieje również pewna złożoność w zakresie łączenia projektów internetowych.
Główna rzecz
Do tego raportu prawdopodobnie by nie doszło, gdyby nie pojawił się HipHop, czyli rozwiązanie od Facebooka. Jego twórcy również zgromadzili dużą ilość kodu PHP i długo zastanawiali się, co z nim zrobić.
Jak rozumiem, po odrzuceniu możliwości przepisania wszystkiego, zdecydowano się napisać jakiś tłumacz (w tym przypadku na kod C++). Projekt jest stosunkowo młody, oficjalnie ukazał się dopiero w lutym tego roku. Kod PHP jest tłumaczony na kod C++, a następnie generowany przy użyciu standardowych narzędzi w systemie operacyjnym. Jednak na razie obsługiwany jest tylko system operacyjny Linux.
Jeszcze wczoraj zapytałem przedstawiciela Facebooka o tę decyzję. Powiedział, że obecnie 100% kodu PHP jest kompilowane poprzez HipHop. Kod nie działa w czystej postaci poprzez interpreter PHP. Po raz kolejny twórcy zapowiedzieli znaczne zmniejszenie obciążenia procesora.
Podstawowa funkcjonalność HipHop
Bezpośrednio generuje sam plik binarny, który można wykonać w wierszu poleceń. Istnieje taka opcja uruchomienia go jako serwera strumieniowego. Istnieje również oddzielny wbudowany debuger. Może debugować skrypty zarówno lokalnie, jak i zdalnie (będzie działać jako serwer).
Proces montażu jest dość nietrywialny. Jest opis, ale nie wszędzie jest on gromadzony. W tej chwili, jak powiedziałem, wszystko jest zmontowane dla Linuksa, a początkowo wszystko było „szyte na miarę” dla wersji 64-bitowej. Chociaż 32 bity są teraz obsługiwane eksperymentalnie. Ale udało mi się to zmontować i trochę załatać - w sumie to wszystko zrobiło, bo domyślnie nie jest zmontowane.
Ponadto mają własne wersje libcore i moim zdaniem jest kilka bibliotek, które również wymagają załatania. Generalnie proces montażu nie jest taki prosty.
Na wyjściu po asemblerze otrzymujemy pewien plik hphp, będący tłumaczem naszego kodu PHP na C++. Jeśli spojrzymy na flagi, jest ich całkiem sporo. Podkreśliłem tutaj kilka podstawowych, których możesz potrzebować.
Plik w formacie HDF możemy wykorzystać jako plik konfiguracyjny (config), określający różne dyrektywy. Możemy tam ustawić poziom błędu i inne rzeczy (HDF to wszystko, co jest dostępne w ustrukturyzowanej formie). Możemy również pobrać samą konfigurację z bazy danych lub użyć jej bezpośrednio w wierszu poleceń.
Podczas kompilacji ustalamy poziom rejestrowania: pokazuj wszystkie błędy lub wyświetlaj także ostrzeżenia, dodatkowe informacje lub ogólnie prowadź pełny dziennik wszystkiego, co się dzieje.
Bardzo użyteczną dyrektywą jest input_list=FILE, która pozwala nam określić listę skryptów, które chcemy skompilować. Warto również wspomnieć o dyrektywie takiej jak lazy-bind. Możemy określić wszystkie pliki projektu - te, które zostaną skompilowane.
Przykład uruchomienia kompilacji skryptu PHP
Zainstalowany został trzeci poziom logowania, są tam dość ogólne informacje o czasie, widać ile czasu to trwało. W rzeczywistości scenariusz jest dość prosty. To jest zwykłe „Hello, World”, właśnie zrobiłem zrzut ekranu.
Najcięższym plikiem jest plik binarny naszego „programu”, jego rozmiar wynosi 28 MB. Zasadniczo nasz „Hello, World” waży 28 MB. Chciałem zauważyć, że oprócz standardowej linii „Echo „Hello, World!”, ten plik binarny zawiera znacznie więcej. Jest to pełnoprawny serwer WWW, pełnoprawny serwer do administracji.
Co my robimy?
Mamy „Hello…” w C++, które wykonuje funkcję składającą się z jednej linii „echo „Hello, World”. Dodatkowo ładowanych jest wiele rzeczy innych firm. Jak widzimy, jest to pełnoprawny plik w C++.
Oto wynikowy program. Zawiera już sporo różnych kluczy do różnych konfiguracji, ale wspomnę tylko o kilku z nich.
To jest --mode, to jest tryb uruchamiania naszego programu. Możemy go uruchomić bezpośrednio (z wiersza poleceń) lub w trybie serwera WWW lub w trybie pełnoprawnego demona. Jest jeszcze kilka opcji, ale są one nieistotne.
config jest używany w tym samym formacie. Nie dałem wskazówek, bo jest ich dużo. HipHop jest dostarczany z dokumentacją. Nie ma tego na stronie wiki, ale wraz z dystrybucją dołączona jest dokumentacja, w której wszystko jest jasno opisane. Nawet nie spodziewałem się, że opis będzie tak szczegółowy, co pozwala na dość elastyczną konfigurację rozwiązania.
Aby działać w trybie serwera, możemy określić port. Do administracji wykorzystywany jest osobny port, na który można wysyłać niektóre żądania umożliwiające zarządzanie serwerem. Jeśli mamy uruchomiony serwer debugujący, wskazujemy host i port, do którego „powiążemy” w celu debugowania.
Uruchom przykład
Przykładowo do rozgłaszania określiliśmy port 9999. Wykonując proste żądania http, możemy albo otrzymać statystyki, albo w jakiś sposób zarządzać serwerem, albo uzyskać dodatkowe informacje. Ogólnie rzecz biorąc, jest to bardzo wygodne.
Możliwość uzyskania informacji o statusie
Możliwe jest otrzymanie statusu serwera ustawionego w różnych wbudowanych formatach (xml, json, html). Zasadniczo dostarczane są informacje o samym głównym procesie serwera i procedurach obsługi - wątkach przetwarzających żądania.
Dodatkowe statystyki
W rzeczywistości dostępnych jest wiele statystyk. Ponieważ HipHop natywnie współpracuje z memcache i SQL w postaci MySQL, dostarcza szczegółowych informacji o wszystkich operacjach, które są z nim wykonywane.
Pełne statystyki pamięci
Jest tu bardzo przydatna funkcja - Statystyki aplikacji. Wykorzystując dodatkowe funkcje samego HipHopa w PHP, możemy w naszych skryptach pisać statystyki, które następnie otrzymujemy poprzez regularny dostęp do http.
Debugowanie
Jak już powiedziałem, możliwe jest użycie wbudowanego „debugowania” do debugowania skryptów. Jest to bardzo wygodne, ponieważ interpreter hphpi działa podobnie do tego, co skompilowaliśmy. Istnieje różnica w „zachowaniu” skryptów, gdy są wykonywane w standardowym PHP i przy użyciu skompilowanych danych. Aby debugować to, co zostało skompilowane, Facebook napisał osobny interpreter.
W pierwszym przypadku uruchamiamy kod z przełącznikiem „-f” i sprawdzamy, jak zachowa się plik; wszystkie dane wyjściowe trafiają na standardowe wyjście. Możemy też uruchomić go w trybie debugowania i przejść do interaktywnego debugera. Jest bardzo podobny do standardowego GDB: możesz także ustawiać punkty przerwania, uruchamiać, wprowadzać wartości zmiennych, śledzić i nie tylko.
Jedna z dodatkowych funkcji
Mamy program, który okazał się po kompilacji. Może być używany jako serwer RPC. Uruchamiamy żądania przez http i wywołując funkcję params, możemy przekazać parametr jako tablicę json lub jako oddzielny parametr. Będziemy mieć zwrócony json, który zwraca wyniki tych funkcji. Jest to bardzo wygodne – niezbędna funkcjonalność jest wbudowana już od samego początku.
Wady hiphopu
W tej chwili HipHop nie obsługuje konstrukcji językowych i funkcji, takich jak eval(), create_function() i preg_replace() z /e, chociaż wszystkie są analogiczne do eval(). Jednak moim zdaniem w najnowszych wersjach nadal można włączyć eval() poprzez konfigurację. Ale nie zaleca się tego robić. Ogólnie rzecz biorąc, używanie eval() jest złe.
Główne zalety hiphopu
Oczywiście główną zaletą jest wsparcie ze strony Facebooka. Działa i jest dość aktywnie rozwijany. Wokół tego projektu tworzy się społeczność programistów. Napisano zupełnie nową implementację PHP.
Jak już mówiłem, zaletą jest to, że generowany jest kod natywny. Wzrost wydajności zapewniany jest poprzez zmniejszenie kosztów obciążenia procesora (testy to potwierdzają).
Jest dość elastyczny w konfiguracji. Byłem mile zaskoczony, że istnieje sporo opcji dostosowywania. Myślę, że wynika to z faktu, że projekt faktycznie działa. Wszystko, co jest używane, jest zwiększane.
Jak już wspomniałem, HipHop zapewnia całkiem sporo dodatkowych funkcji. Należą do nich wykorzystanie jako serwera RPC, administracja, różne statystyki i wiele więcej. Nawiasem mówiąc, istnieje również API do pracy z innymi językami.
Dla tego rozwiązania napisano całkiem dobrą dokumentację. Kolejna zaleta: jest to rozwiązanie, które faktycznie jest gotowe do zastosowania w produkcji (przykład: Facebook).
Minusy
Główną wadą jest to, że obecnie obsługiwana jest raczej ograniczona liczba modułów. Na przykład podczas pracy z bazą danych możemy używać tylko funkcji do pracy z MySQL. Nie ma tutaj obsługi PostgreSQL.
Jest też coś takiego jak złożoność montażu, o której już wspomniałem. Występują problemy z budowaniem na systemach 32-bitowych. Myślę jednak, że wkrótce zostanie to naprawione. Na razie używana jest tylko kompilacja z PHP 5.2. Wersja 5.3 nie jest jeszcze obsługiwana, ale będzie obsługiwana zgodnie z obietnicą.
Czego nie należy się spodziewać po kompilacji w ogóle, a po HipHopie w szczególności?
Kompilacja w żaden sposób nie przyspieszy powolnych zapytań SQL w bazie danych. Jeśli wąskim gardłem jest baza danych, to ją skompiluj lub nie kompiluj, to nic nie da.
Kompilacja nie przyspiesza ładowania statycznego, tylko ładowanie dynamiczne. To znacznie utrudnia debugowanie. Wiele osób jest prawdopodobnie przyzwyczajonych do tego, że w PHP wszystko jest dość łatwe do debugowania. Nie będzie to już miało miejsca podczas kompilacji. Chociaż, jak zauważyłem, Facebook maksymalnie uprościł ten proces, bez niego kompilacja za każdym razem byłaby jeszcze trudniejsza.
Nie spodziewaj się, że będzie to jakiś „złoty środek”, który rozwiąże wszystkie Twoje problemy. W rzeczywistości kompilacja rozwiązuje dość wąski zakres problemów. Jeśli tak, to może pomóc.
Jakie problemy rozwiązuje kompilacja?
Zmniejsza obciążenie procesora, ponieważ podczas aktywnej pracy z PHP i dużej liczby żądań obciążenie go znacznie wzrasta. Oczywiście chciałbym przeprowadzić pewne testy.
Testowanie
Pierwszy test (najprostszy) to dość kosztowna operacja, której wykonanie zajmuje dość dużo czasu. W testach starałem się abstrahować i nie wysyłać żądań przy użyciu jakiegoś zewnętrznego zasobu.
Obciążenie spada całkowicie na procesor. Test pokazał, że HipHop „wygrał” ze wszystkimi: działa prawie półtora razy szybciej niż standardowy kompilator PHP. PHC przeszło ten test bardzo wolno.
Do drugiego testu wydajności użyłem oficjalnego skryptu PHP, który można pobrać z SVN. Wykonuje szereg funkcji wykonujących sortowanie, przypisywanie, sumowanie – operacji dość kosztownych z matematycznego punktu widzenia.
HipHop znów był na prowadzeniu. Co więcej, w przypadku standardowego PHP różnica czasu jest około 3-krotna. PHC wypadło tutaj lepiej, ale było o połowę gorsze niż HipHop.
PHP jest używany głównie do wątków obsługujących żądania http - warto o tym pamiętać.
Kilka standardowych konfiguracji (Apache z PHP, Nginx z fpm-php i wtyczka APC do buforowania kodu). Jako piąta opcja - HipHop.
Szczerze mówiąc, testy przeprowadzałem nie na serwerze, a na laptopie. Liczby oczywiście mogą nie w pełni odpowiadać rzeczywistości, ale w tym przypadku wyniki są normalne. Warto zauważyć, że wraz ze wzrostem obciążenia wzrasta jednocześnie liczba żądań i całkowita liczba żądań. Następny jest RPS. Przetestowaliśmy standardową stronę zawierającą 10 prostych dodatków. Zasadniczo jest to testowanie PHP jako interpretera.
Pytanie od publiczności: Jakie są liczby w komórce - sekundy?
Aleksiej Romanenko: To jest fps.
Tutaj możemy stwierdzić, że wraz ze wzrostem liczby jednoczesnych żądań HipHop zachowuje się bardzo dobrze.
Można zauważyć, że stosowanie APC jest standardową praktyką. Pokazuje, że dodaje np. Apache wzrost wydajności około 2 razy. Dzieje się tak również w przypadku Nginx. Ale to, że Nginx jest powolny, nie oznacza, że ten pakiet jest gorszy. Tylko konkretny test. Jeśli naprawdę tu przetestujemy, Apache „umrze” przy powolnych żądaniach.
Prawdopodobnie chcemy zrozumieć, czy tego potrzebujemy, czy nie.
Kiedy warto pomyśleć o kompilacji?
Najprawdopodobniej jest to potrzebne, gdy widzimy, że naszym wąskim gardłem jest procesor. Jeśli jesteśmy ograniczeni procesorem i używamy PHP jako standardowego interpretera, prawdopodobnie warto rozważyć, czy część projektu można skompilować.
W niektórych przypadkach, gdy aplikacja wymaga autonomii do działania, ta metoda raczej nie będzie odpowiednia.
Zmniejszenie liczby serwerów. Gdy serwerów jest dużo, to zmniejszając produktywność o 2 razy, z grubsza rzecz biorąc, zmniejszamy również ich liczbę o połowę. Gdy jest to jeden serwer to nie ma sensu, ale gdy jest ich 100-200 to chyba ma to sens.
Głównym powodem, dla którego Facebook zaczął korzystać z HipHopa, jest obecność dużej ilości kodu PHP, którego nie ma jak przepisać (albo nie ma nikogo, albo jest to po prostu drogie). Zwiększenie produktywności o 2 razy jest już dobre.
Prawdopodobnie wszystko. Czekam na pytania.
Pytania i odpowiedzi
Pytanie od publiczności: Cześć. Proszę, powiedz mi, czy masz inne przykłady udanych wdrożeń Hiphopu, poza Facebookiem. Czy chciałbyś przenieść np. stronę RBC do HipHop? Aleksiej Romanenko: Zacznę od drugiego. Strona internetowa RBC jest trudna do przetłumaczenia. Jeśli chodzi o pomyślne wdrożenie. Sam skompilowałem moduł PHP, skompilował się pomyślnie. Ponadto, o ile wiem, tablica PHP Bunty kompiluje się pomyślnie. Wiele organizacji już korzysta z kompilacji. Dalsze testy wykażą, na ile zasadne będzie wykorzystanie tego projektu. Pytanie od publiczności: Czy możesz podać przykład organizacji, która z tego korzysta? Aleksiej Romanenko: Szczerze mówiąc, nie powiem ci teraz, ale to jest Zachód. Z tego co wiem nikt tu tego nie używa. Pytanie od publiczności: Jaka jest różnica w czasie wykonywania, poza brakiem obsługi niektórych funkcji, o których wspomniałeś. Jak niebezpieczne jest tłumaczenie projektu „na żywo”? Aleksiej Romanenko: Różnica polega na tym, że każdy skompilowany program może ulec awarii. Być może pojawią się pewne problemy, które nie zostały jeszcze zidentyfikowane. W rzeczywistości istnieje wiele różnic w „zachowaniu” samego PHP. Nie uwzględniłem ich, ponieważ bardziej szczegółowe informacje można znaleźć w dokumentacji. Zespół Facebooka napisał własny interpreter, który w zasadzie w 99,9% odpowiada temu, który będzie działał w formie skompilowanej. Lepiej przetestować swój kod nie za pomocą standardowego interpretera PHP, ale, jak powiedziałem, za pomocą hphpi dla PHP.
