Początkowo chciałem zrobić standardowe podsumowanie ostatniej konferencji PHPCon Poland. Po chwili zastanowienia uznałem, że tak naprawdę PHPCon Poland wyznacza trendy na następny rok na naszym polskim rynku PHP.
W moim mniemaniu liczą się obecnie tylko 2 frameworki – Symfony 2 oraz Zend Framework 2. Cała reszta nie jest warta uwagi. Jeśli Twoim zdaniem Sf2 lub ZF2 są za duże na Twój projekt – wykorzystaj tylko poszczególne komponenty jakich dostarczają, albo napisz coś własnego małego… i użyj komponentów od dużych braci.
Jednym z powodów przejścia GoldenLine na Symfony było wsparcie jakie daje firma, która stoi za frameworkiem, znajomość frameworku przez rynek (programistów) oraz jego dojrzałość rozumiana przez pryzmat mnogości komponentów, gotowych elementów. To prawda, że są to wielkie kobyły, bez włączonego opcache ani rusz, ale taki jest rynek…
Z powodu wejścia tak sporych frameworków między innymi zmienia się PHP jaki znamy. Do jądra nie tylko dochodzą nowe bajery, ale również trwa ciągła optymalizacja wydajności i zarządzania zasobami.
HHVM
Odważniejsi mogą spróbować HHVM, który „zastąpił” HipHopa i staje się coraz bardziej dojrzały. W tym momencie już 27 narzędzi/frameworków da się w pełni uruchomić z wykorzystaniem HHVM (m.in. laravel, doctrine2, composer, phpunit, twig). Wystarczy PHP w wywołaniu zastąpić HHVM i nic więcej nie trzeba robić co pokazał Mariusz Gil.
HHVM przyspiesza composera ponad 5x. Czas wywołań testów na standardowym bench.php są oszałamiające, HHVM potrzebuje tylko 0,26 s, gdzie te same operacje PHP (5.5.9) bez żadnego wsparcia wykonywał przez 1,44 s.
Ale najważniejszą kwestią jest architektura aplikacji, pomyślenie w odpowiednim momencie o cache’u, bazie danych, zewnętrznych API, czy odpowiednim zastosowaniu Redisa. Dopiero w takim momencie możemy pomyśleć o HHVM, czy czekać na PHP-NG, które będzie domyślnym silnikiem w PHP 7.0.
xhprof i aktualizacje
Ale po co w ogóle coś usprawniać? Badania pokazały, że jeśli coś trwa mniej niż 100 ms nasz mózg uważa że jest to natychmiastowa operacja. Zacznijmy optymalizować, jeśli żądania trwają powyżej 100 ms.
Wtedy można skorzystać z xhprof, młodszego, lepszego brata xdebug’a, z którego naprawdę prosto się korzysta i równie prosto instaluje (np. w połączeniu z xhgui).
Należy również pamiętać o aktualizacjach samego PHP. Przejścia na PHP 5.6 jeszcze nie zalecam z powodu zbyt młodego wieku, ale najnowsza wersja PHP 5.5 to obowiązek. To nie tylko nowe możliwości (np. generatory, finally, password_hash), ale również zwiększona szybkość.
Testy jednostkowe
Żeby móc rozpocząć jakiekolwiek optymalizacje czy refactoring kodu należy posiadać najpierw w aplikacji testy jednostkowe. Podstawowym problem zawsze wydaje się na początku brak czasu i brak budżetu, ale jak kolejny raz podkreślił Michelangelo van Dam tak nie jest. Testy jednostkowe to same plusy:
- natychmiastowy feedback w przypadku błędu
- test piszemy raz, korzystamy z niego przy każdym wdrożeniu
- o wiele prościej dokonać zmian w kodzie (refactoring)
- prościej analizować kod aplikacji (debug)
Pisząc unit tests należy tylko pamiętać, aby testować jak najmniejsze jednostki kodu (smallest unit-of-code). Powinniśmy testować warunek po warunku (condition by condition), a nie do końca skupiać się na liniach kodu w metodzie.
Testy powinny nam przetestować przede wszystkim logikę aplikacji, a nie same dane. Jeśli posiadamy integrację z zewnętrznymi API (np. płatności), również powinniśmy przetestować punkty styku, ewentualnie wirtualizując odpowiedzi drugiej strony.
Przełamuj standardowe myślenie
Jeśli tworzysz aplikację, która ma być duża, staraj się myśleć niestandardowo. Zastanawiasz się czy skorzystać z bazy relacyjnej? A może NoSQL? Wybierz obie i użyj w zależności od potrzeb. Pamiętaj tylko, aby Twoja aplikacja nie operowała na ActiveRecord lub podobnych cudach, ale niezależnych modelach, które mogą być podpięte pod dowolne źródło danych.
Ja zawsze kompiluję główne narzędzia na serwerach (jak PHP, nginx). Jeśli nie lubisz brudzić się w kompilacjach, pamiętaj aby po zainstalowaniu oprogramowania z paczek wyłączyć nieużywane przez Ciebie moduły. To naprawdę potrafi odciążyć web server.
Patrz co lata po Sieci, szczególnie jeśli korzystasz z wirtualizowanych maszyn, co dzisiaj staje się standardem. Opóźnienia na sieci mogą mocno spowolnić końcowe działanie aplikacji, jak również niepotrzebne dane które zwracamy do Użytkownika. Staraj się w miarę możliwości pregenerować dane dla Użytkownika, jeszcze przed jego zapytaniem. Staraj się stworzyć aplikację, aby dla końcowego użytkownika wydawała się naprawdę real-time (< 100ms).
Korzystaj z Redisa, uzupełniających go o memcache(d). Marcin Wójcik nie żałuje, nie żałuj i Ty. Może naprawdę nie potrzebujesz frameworka? Pozbycie się go, usunięcie autoloadera (nawet SPL) może spowodować mocne przyspieszenie aplikacji/API.
Ale pamiętaj kod musi być najpierw funkcjonalny, dopiero po tym profiluj, optymalizuj, refaktoruj. Zawsze korzystałeś np. z Net_POP3? Może to zewnętrzna biblioteka jest problemem, a nie Twój kod (pamiętaj o xhprof).
I na sam koniec – jeśli Twój system musi być bardzo wydajny to najważniejsza jest architektura.
Mam nadzieję, że taka forma (spisania notatek) Wam odpowiadała. Do zobaczenia za rok!