Publicité
Publicité

Contenu connexe

Publicité

Plus de The Software House(20)

Publicité

PHP-PM. Hit czy kit?

  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
  3. PPM – według twórców
  4. PHP jako serwer
  5. Podejście „klasyczne”
  6. Podejście w PHP-PM
  7. 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
  8. ReactPHP
  9. ReactPHP -> swoole?
  10. PHP-cgi + PCNTL
  11. Symfony components
  12. Zastosowania?
  13. 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
  14. Jak uruchomić?
  15. Docker • 3 gotowe obrazy: • nginx + pm • pm standalone • pm jako entrypoint
  16. 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
  17. 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
  18. Benchmarki
  19. 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
  20. 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
  21. PPM + nginx fpm + nginx apache siege –c1 –t1m –b http://localhost:8x/
  22. PPM + nginx fpm + nginx apache siege –c10 –t1m –b http://localhost:8x/
  23. PPM + nginx fpm + nginx apache siege –c100 –t1m –b http://localhost:8x/
  24. 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
  25. PPM + nginx fpm + nginx apache siege –c1 –t1m –b http://localhost:8x/api/test_entities.json
  26. PPM + nginx fpm + nginx apache siege –c10 –t1m –b http://localhost:8x/api/test_entities.json
  27. PPM + nginx fpm + nginx apache siege –c100 –t1m –b http://localhost:8x/api/test_entities.json
  28. 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
  29. PPM + nginx fpm + nginx apache siege –c1 –t1m –b http://localhost:9x/
  30. PPM + nginx fpm + nginx apache siege –c10 –t1m –b http://localhost:9x/
  31. PPM + nginx fpm + nginx apache siege –c100 –t1m –b http://localhost:9x/
  32. 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
  33. PPM + nginx fpm + nginx apache siege –c10 –t10h –b http://localhost:8x/
  34. 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
  35. 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
  36. 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?
  37. Pytania?
  38. Dziękuje za uwagę!
Publicité