Nowości z php.internals – apc

Kolejna porcja nowości z wewnętrznej grupy dyskusyjnej deweloperów Php. Tym razem tematem przewodnim jest APC czyli Alternative PHP Cache. Dla przypomnienia powiem tylko, że APC jest rozszerzeniem do Php dzięki któremu bez zmian w kodzie można przyśpieszyć swoje skrypty o 300-400%.

Dzieje się tak dzięki temu, że APC zachowuje w pamięci skompilowaną postać skryptu po pierwszym wykonaniu i przy każdym następnym uruchomieniu skrypt nie musi być od nowa parsowany.

Jeden z deweloperów zaproponował defaultowe dołączenie APC do dystrybucji Php i zintegrowanie jego kodu z kodem języka (trunkiem). Ten ruch był już uzgodniony i miało to zostać zrealizowane przy okazji tworzenia Php6. Niestety nie ma już Php6, powstała więc propozycja aby w najbliższej wersji (5.4 ?) przeprowadzić to połączenie.

Doszło do dyskusji i okazało się, że część osób nie chce takiego połączenia. Jako powody wymieniali m.in to, że trudny błąd w APC może zastopować wydawanie kolejnych wersji języka, oraz to, że istnieją również inne rozszerzenia alternatywne do APC i nieuczciwym było by promować tylko wybrane.

Natomiast zwolennicy tego rozwiązania argumentowali, że dołączenie APC nie jest przeszkodą dla używania alternatywnych rozszerzeń, poza tym dzięki temu, że będzie rozwijane w corze, będzie pod większą uwagą deweloperów.

Nasuwa się jeszcze jeden plus w integracji – APC będzie rozprowadzane w standardowej dystrybucji i dzięki temu każdy będzie mógł korzystać z przyśpieszenia bez oglądania się na hosterów czy mają zainstalowane odpowiednie rozszerzenie.

Koniec końców wyłoniły się trzy możliwe rozwiązania:

  • zintegrować i domyślnie wyłączyć
  • zintegrować i domyślnie włączyć
  • nie integrować

Ja popieram opcje nr.1 a jakie jest Wasze zdanie ?

  1. Konradzik says:

    Ja uważam, że to powinien być standard i wewnętrzny mechanizm języka o którym programista nie musi nawet wiedzieć. Pech chciał, że tych rozwiązań cachujących pojawiło się kilka i wątpię żeby ktoś miał teraz sumienie je po prostu zabić.

    Niestety opcja ‘dodać i wyłączyć’ nie współgra, moim zdaniem, z Twoim argumentem ‘każdy będzie mógł korzystać z przyśpieszenia bez oglądania się na hosterów’ – myślisz że APC zostanie dodane jako rozszerzenie które można włączyć z poziomu skryptu?

    I czym jest ‘trudny błąd w APC’? Brzmi ciekawie, a nie wiem o co chodzi.

  2. batman says:

    Moim zdaniem “podstawowa” dystrybucja PHP powinna posiadać tylko i wyłącznie sam silnik. Wszystkie udziwnienia w postaci PDO, APC, DOM, SPL, itp powinny być osobnymi modułami, które można doinstalować wedle uznania. Jeśli do core’a napcha się przeróżnych funkcjonalności, to rozwój języka będzie jeszcze wolniejszy, niż jest to obecnie. Trzeba czekać na wszystkie zespoły, aż zakończą prace nad swoim kodem, przetestują go, poprawią błędy, itd. Jeden błąd w jednym module może spowodować przesunięcie wydania nowej wersji języka.

  3. Moim skromnym zdaniem, dodatki typu APC są troszkę inszą inszością i nie powinny być kategoryzowane jak PDO/Phar i inne. Od niego zależy wydajność kodu, a co za tym idzie, jeśli biorą pod uwagę integrację ( która właśnie będzie wygląda jak ta z PDO – zapewne ) powinni raczej przemyśleć wdrożenie wykorzystywanych mechanizmów znanych z wszystkich bibliotek optymalizujących opcode’y do samego ZendEngine – ponieważ to NIE TYLKO keszowanie. W skład optymalizacji wchodzi znacznie więcej działań ze strony np. APC. Keszowanie zaś, jako dodatek mogło by być realizowane w momencie wykrycia przez CORE ‘jakiegoś’ rozszerzenie realizującego np. współdzielenie pamięci (vide APC/SHM), bądź inne metody przechowywania binarek. Warto również zwrócić uwagę na to, że wspomniane APC umożliwia eksport binarnych opcode’ów do pliku, oraz ich odczyt – co jest dobrze znane z javy i działa tam zupełnie natywnie. To nie jest TYLKO kolejna rzecz do zgapienia z tego języka, a jedynie implementacja mechanizmów od lat sprawdzających się w świecie oprogramowania Enterprise, które kurcze ciężko ignorować.

  4. PS. php -C file.php mogło by dać nam wynikowy file.php.bin zawierający zoptymalizowane opcody przez ZE i już z samego silnika poprawnie interpretowany przez wszystkie SAPI! :)

  5. Wojciech Soczyński says:

    @batman: gdyby wszystko przenieść do opcjonalnych rozszerzeń to obawiam się, że php by straciło na popularności, dzięki temu, że jest dużo rzeczy w podstawowej paczce to jest pewien standard – code base pod który mogą wszyscy kodować.

    Programując w pythonie najbardziej irytuje mnie właśnie to, że za każdym razem muszę sobie coś doinstalowywać, chociażby taką pierdołę jak driver mysql-a. Jest co najmniej 3 różne wersje tego drivera i niektóre z nich trzeba kompilować przy użyciu np gcc i ściągać biblioteki – zupełnie niewygodne (a dla początkującego niewykonalne).

    Poza tym dzięki temu, że dużo rzeczy jest w standardzie to ludzie nie tworzą od nowa rozszerzeń, które realizują to samo.

    @konradzik: poważny błąd w apc to np. zawieszanie garbage collectora sesji http://bugs.php.net/bug.php?id=51382 , co do włączania apc to jest opcja apc_enabled w php_ini która jest php_ini_all tzn, że może zostać włączona z poziomu skryptu a nawet htaccess-a

  6. Zyx says:

    Batman -> tak, i będzie jak z Eclipsem, którego po wydaniu każdej nowej wersji x.y nie da się używać, bo 99% pluginów nie jest jeszcze do niej dostosowanych, z pluginem do PHP na czele. Nie wspomnę już o tym, że byłby to kolejny świetny argument, żeby nowych wersji NIE wprowadzać na hostingi: “a jak mamy wprowadzić, jak nam rozszerzenie x nie działa/nie jest jeszcze do końca przetestowane itp. itd.” Java też mogłaby być rozpowszechniana bez biblioteki standardowej, bo i po co? Jak komuś potrzebne, niech sobie doinstaluje :).

    Właśnie teraz jest taka sytuacja z wszelkiego rodzaju akceleratorami – wychodzi PHP 5.5 i jedyne, co można zrobić, to sobie popatrzeć, jakie to fajne, bo twórcom akceleratorów jeszcze z 5 miesięcy zejdzie, zanim dodadzą i przetestują obsługę nowych elementów języka. Choćby z tego powodu przynajmniej jeden akcelerator powinien być dostępny standardowo, tym bardziej że stopniowo zaczynają pojawiać się biblioteki, które kwestię wydajności opierają właśnie na akceleratorach i systemach cache przez nich oferowanych (np. Doctrine 2).

    Ostatnia rzecz to kwestia dostępności. Na Linuksie dodanie jakiegoś rozszerzenia z PECL to nie problem, ale większość programistów koduje pod Windowsem, gdzie można się pochlastać, próbując coś skompilować samodzielnie, zaś dostępność binarek czasami pozostawia sporo do życzenia.

  7. Wojciech Soczyński says:

    @zyx: zgadzam się z tobą w 100% – trzeba być po prostu realistą ;), podejście batmana wydaje mi się nazbyt idealistyczne

  8. Adam says:

    Opcji apc.enabled nie da się ustawić w .htaccess, w tym wypadku trzeba użyć apc.cache_by_default. W dokumentacji PHP przez długi czas był błąd, poprawili dopiero w wersji 3.0.12 APC.

  9. batman says:

    Może moje podejście jest nieco wyidealizowane, co nie zmienia faktu, że pakowane wszystkiego do core’a powoduje, że wydanie nowej wersji opóźnione jest przez błąd w jednym z modułów, który nie ma nic wspólnego z resztą języka.
    Co do Eclipse, to nie miałem jeszcze żadnych problemów z przesiadką na nowszą wersję. Wszystkie pluginy działały jak należy. Poza tym skoro zapowiadana jest nowa wersja, to zawczasu można przygotować nową wersję plugina.

  10. @zyx: “Nie wspomnę już o tym, że byłby to kolejny świetny argument, żeby nowych wersji NIE wprowadzać na hostingi: „a jak mamy wprowadzić, jak nam rozszerzenie x nie działa/nie jest jeszcze do końca przetestowane itp. itd.””

    @zyx: “Ostatnia rzecz to kwestia dostępności. Na Linuksie dodanie jakiegoś rozszerzenia z PECL to nie problem”

    Albo jest problem, albo go nie ma. Decydujemy w pierwszej kolejności, gdzie trafiają nasze aplikacje. Dodanie rozszerzenia na hostingu, zwłaszcza takim ‘dla mas’, to ZAWSZE jest problem i to bez względu na to którą ścieżką pójdzie PHP. Zwróć uwagę proszę na hostingi oferujące możliwość instalacji django czy railsów – to te bardziej świadome, bardziej zaawansowane – oni nie mają problemów z aktualizacjami pythona czy rubiego.

    Jeśli chodzi zaś o Eclipse potwierdzam. Problemów brak :)

  1. There are no trackbacks for this post yet.

Leave a Reply

Notify me of followup comments via e-mail. You can also subscribe without commenting.