Franciszek Krasowski: Zastanawialiście się kiedyś nad tym, czym jest PHP-PM? Jak działa? Jak wypada w porównaniu do innych popularnych rozwiązań? Czy jest wystarczająco stabilny? Franciszek Krasowski odpowie na wszystkie te pytania (a także na te, których jeszcze nie zadaliście).

1. PHP-PM
Hit czy kit?
Franciszek Krasowski
PHP developer

2. Agenda
• Trochę teorii
• PHP-PM - Co to jest?
• PHP jako serwer
• Zastosowania PHP-PM
• Użycie PHP-PM
• Benchmarki
• Podsumowanie

4. PPM – według twórców

5. PHP jako serwer

6. Podejście „klasyczne”

7. Podejście w PHP-PM

8. Istotne informacje
• Workery mimo wszystko nie są stabilne
• Spore wycieki pamięci
• Resetowanesą po x czasu (konfigurowalne)
• Reset również po x requestachobsłużonych przez worker
• debug mode odświeża workery przy każdej zmianie

10. ReactPHP

11. ReactPHP -> swoole?

12. PHP-cgi + PCNTL

13. Symfony components

14. Zastosowania?

15. Zastosowania
• Wymaga abstrakcji Request-Response
• Nie działa na „czystym” PHP
• Działa bezproblemowo z Symfony (włącznie z 4.1)
• Laravel
• Drupal, Zend i CakePHP -> teoretycznie obsługiwane, ale zalecana ostrożność
• NIE działa z Wordpressem

16. Jak uruchomić?

17. Docker
• 3 gotowe obrazy:
• nginx + pm
• pm standalone
• pm jako entrypoint

18. Lokalnie
• Wymagania:
• phpX-cgi -> X >=5.6.0
• PCNTL -> wyklucza postawienie na Windows
• Możliwości:
• git clone php-pm/php-pm
• composer require php-pm/php-pm
• + dodatkowy adapter

19. Istotne parametry
• --bridge=HttpKernel -> bridge konwertującyrequest z ReactPHPdo PSR7
• --workers=8 -> ilość równoległych workerów
• --debug=0 -> live reload workerów przy zmianie kodu (+ verbose)
• --logging=1 -> logowanie na stdOut
• --static-directory="" -> katalog z statycznymiplikami
• --bootstrap=Symfony -> Klasa do boostrapowania frameworka (dla Laravela ->
laravel)
• --cgi-path -> ścieżka do php-cgi

20. Benchmarki

21. Co będzie testowane?
• Wszystko skonteneryzowane
• PHP-PM + nginx (szybszy)
• FPM + nginx
• Apache server
• Baza z php 7.2.8 dla wszystkich kontenerów
• Kod wewnątrz kontenerów
• Symfony + Laravel
• Kod można znaleźć: https://gitlab.com/Franek.krasowski/php-pm-uszanowanko

22. Na czym będzie testowane?
• i5-4690k 4,2GHz-> 4 rdzeniowy
• 24GB RAM
• Ubuntu 17.04
• Docker 18.03.1
• Docker Compose 1.22.0
• Siege 4.0.2

23. PPM + nginx fpm + nginx apache
siege –c1 –t1m –b http://localhost:8x/

24. PPM + nginx fpm + nginx apache
siege –c10 –t1m –b http://localhost:8x/

25. PPM + nginx fpm + nginx apache
siege –c100 –t1m –b http://localhost:8x/

26. Zestawienie
• PPM maksymalnie 5x szybszy
• Przy większym obciążeniu traci
przewagę
• PPM czasem potrafi zjeść całą
pamięć828,4
1316,91
1396,26
164,88
653,26
7 09,46
160,95
635,76
559,43
0
200
400
600
800
1000
1200
1400
1600
1 10 100
Requests/s
Concurency
PHP-PM FPM Apache

28. PPM + nginx fpm + nginx apache
siege –c1 –t1m –b http://localhost:8x/api/test_entities.json

29. PPM + nginx fpm + nginx apache
siege –c10 –t1m –b http://localhost:8x/api/test_entities.json

30. PPM + nginx fpm + nginx apache
siege –c100 –t1m –b http://localhost:8x/api/test_entities.json

31. Zestawienie
• PPM średnio około 3x szybszy
• Nie traci przewagi przy większym
zrównolegleniu
122,58
315,88
308,4
38,31
137,73
106,56
37
131,53
100,07
0
50
100
150
200
250
300
350
1 10 100
Requests/s
Concurency
PHP-PM FPM Apache

32. PPM + nginx fpm + nginx apache
siege –c1 –t1m –b http://localhost:9x/

33. PPM + nginx fpm + nginx apache
siege –c10 –t1m –b http://localhost:9x/

34. PPM + nginx fpm + nginx apache
siege –c100 –t1m –b http://localhost:9x/

35. Zestawienie
• Gorzej w porównaniu do Symfony
• Duża losowość wyników
15,67
115,27
128,29
16,43
113,42
134,78
16,03
88,02
138,31
0
20
40
60
80
100
120
140
160
1 10 100
Requests/s
Concurency
PHP-PM FPM Apache

36. PPM + nginx fpm + nginx apache
siege –c10 –t10h –b http://localhost:8x/

37. Zestawienie
• PPM
• ponad 4x szybszy od FPM-a
• 2x od Apache
• PPM – zgubił 3 requesty w 10h,
Apache i FPM żadnego
• PPM -> najdłuższy maksymalny czas
requesta(1,04s)
1341,76
313,81
597,69
0
200
400
600
800
1000
1200
1400
1600
PHP-PM FPM Apache
Requests/s

38. Uruchomienie na serwerze z Rancherem
• Bieda serwery nie dały rady
obsłużyć requestów
• Wynik równy, ograniczony
możliwościami serwerów
• Requestobsługiwany nawet do
40s
• Większe obciążenie -> mniej
requestów/s

39. Podsumowanie
• Szybszy od klasycznego rozwiązania (chociaż stwierdzenie 15x szybszy to
przesada)
• Pamięciożerny
• „Gubi” niektóre requesty
• Potrafi się zamulić
• Duża apka (?)
• Hit czy kit?

40. Pytania?

41. Dziękuje za uwagę!