Apache + PHP. Optymalizacja serwera

[shibby 54]

Witajcie

 

Długi czas używałem standardowego zestawu czyli Apache2 (prefork) + mod_php5. Z czasem doszedł do tego suPHP. Całość działała dobrze i stabilnie ostatnimi czasy zaczęło być to niewystarczające, tzn zbyt wolne. Zacząłem więc szukać sposobów optymalizacji serwera Apache2. Czytałem trochę o ruid2, co już powinno dać widoczne efekty względem suPHP. Zaciekawił mnie też pakiet php5-fpm. Zrobiłem kilka testów i wyniki są zadowalające. Pytanie: jakie waszym zdaniem pakiety będą najlepiej ze sobą działać zarówno pod względem wydajności jak i stabilności:

 

1) apache2-mpm-prefork czy mpm-worker?

 

2) mod_php5 czy fastcgi+php5-fpm? A może jeszcze coś innego?

 

3) jeżeli fpm to czy istnieje szansa ożenienia go z suphp lub ruid2? Z tego co czytałem to nie, ale wolę się upewnić. Jeżeli faktycznie nie da rady to co innego użyć by skrypty uruchamiały się z uprawnieniami właściciela (np. sklep Sote).

 

Na jakie jeszcze moduły do Apache2 warto zwrócić uwagę przy optymalizacji? APC? Eaccelerator?

Wszelkie rady mile widziane.

 

Pozdrawiam

[Łukasz Ostrowski 593]

3) jeżeli fpm to czy istnieje szansa ożenienia go z suphp lub ruid2? Z tego co czytałem to nie, ale wolę się upewnić. Jeżeli faktycznie nie da rady to co innego użyć by skrypty uruchamiały się z uprawnieniami właściciela (np. sklep Sote)

Tworzysz pule i w nich określasz właściciela z jakim będą wykonywane skrypty, nie bardzo wiem do czego Ci tu suphp lub ruid

[Gość patrys]

Są tylko dwie sensowne konfiguracje Apache z PHP:

1. Apache 2.4 event + FPM w dynamic najlepiej.

2. Apache 2.4 prefork + mod+php + ruid2.

[maniektme 99]

Są tylko dwie sensowne konfiguracje Apache z PHP:

1. Apache 2.4 event + FPM w dynamic najlepiej.

2. Apache 2.4 prefork + mod+php + ruid2.

 

Mógłbyś uzasadnić? Nie to, że się czepiam, ale jestem zwyczajnie ciekawy jak to "zmierzyłeś"?

[krk 2]

a może nginx + php fpm ?

[Gość patrys]

@maniektme: nie mam benchmarku, a doświadczenie przy masie serwerów w naprawdę przedziwnych konfiguracjach.

Pod takie zastosowania współdzielone te dwie opcje są najlepsze + jeszcze dochodzi opcja z mod_fcgid i własnymi konfiguracjami .ini per user.

Rozwiązania w oparciu o forkowanie procesów na mod_fastcgi czy suphp są straszne.

 

W przypadku gdy mamy jeden serwis na serwerze to możemy użyć mod_php bez ruid2 + dostawić Nginx/Varnish i cieszyć się z wydajności

 

 

[shibby 54]

wiedziałem, że będą propozycje przejścia nginxa Ja nie widzę powodu przechodzenia na inny serwer. Apache znam, nginixa nie. Apache jest kompatybilny z każdą stroną (mam tu przede wszystkim na myśli htaccess) a w nginxie trzeba wszystko przerabiać by zechciało to działać. Nie mam czasu uczyć się nginxa od zera a na apache pracuję od wielu lat i po prostu jego konfiguracja jest mi bardzo dobrze znana.

 

Ponadto Apache +PHP-FPM wychodzi w testach tak samo wydajnie jak nginx z fpm.

Apache2 + php5-fpm

 

# ab -n1000 -c60 -k http://localhost/bench.php
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software: Apache/2.2.22
Server Hostname: localhost
Server Port: 80

Document Path: /bench.php
Document Length: 498 bytes

Concurrency Level: 60
Time taken for tests: 538.743 seconds
Complete requests: 1000
Failed requests: 916
(Connect: 0, Receive: 0, Length: 916, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 0
Total transferred: 688880 bytes
HTML transferred: 498880 bytes
Requests per second: 1.86 [#/sec] (mean)
Time per request: 32324.552 [ms] (mean)
Time per request: 538.743 [ms] (mean, across all concurrent requests)
Transfer rate: 1.25 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.7 0 4
Processing: 7909 31911 3693.4 31734 43134
Waiting: 7909 31911 3693.4 31734 43134
Total: 7911 31912 3693.2 31734 43134

Percentage of the requests served within a certain time (ms)
50% 31734
66% 33151
75% 34035
80% 34551
90% 36194
95% 37533
98% 38924
99% 40270
100% 43134 (longest request)

nginx + php5-fpm (postawiony na tej samej maszynie) na porcie 8080:

 

# ab -n1000 -c60 -k http://localhost:8080/bench.php
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software: nginx/1.2.1
Server Hostname: localhost
Server Port: 8080

Document Path: /bench.php
Document Length: 499 bytes

Concurrency Level: 60
Time taken for tests: 540.470 seconds
Complete requests: 1000
Failed requests: 109
(Connect: 0, Receive: 0, Length: 109, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 0
Total transferred: 654883 bytes
HTML transferred: 498883 bytes
Requests per second: 1.85 [#/sec] (mean)
Time per request: 32428.201 [ms] (mean)
Time per request: 540.470 [ms] (mean, across all concurrent requests)
Transfer rate: 1.18 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 5.2 0 28
Processing: 15370 32018 3669.1 31967 43897
Waiting: 15370 32018 3669.2 31967 43897
Total: 15373 32020 3670.0 31967 43925

Percentage of the requests served within a certain time (ms)
50% 31967
66% 33120
75% 34103
80% 34713
90% 36325
95% 37921
98% 39407
99% 41318
100% 43925 (longest request)

 

Plik bench.php użyty do testów: http://www.php-benchmark-script.com/

Gdzie tu przewaga nginx`a?

[Pan Kot 1535]

Stary ty widzisz co w ogóle testujesz?

 

Zrób sobie głupi plik phpinfo i wtedy testuj, a nie odpalasz skrypt php który w najbliższym czasie się nie skończy i mierzysz liczbę requestów...

 

Poza tym tak, nginx + php-fpm to obecnie najbardziej wydajne rozwiązanie jakie udało mi się uzyskać. W szczególności przy dobrej optymalizacji.

[PapaSmerf 497]

W dodatku testuje gałąź 2.2... Można rozmawiać przy 2.4, ale 2.2?

[shibby 54]

Archi, tak doskonale wiem co testuję i mam w tym cel. Nie widzę sensu testowania "statycznego" pliku. Równie dobrze idąc twoją logiką mógłbym testować czysty plik index.html. Tylko co taki test pokaże? Wydajność serwera www a nie wydajność serwera jeżeli chodzi o strony php a przecież mi o takie strony chodzi.

 

pedro84 - To jest najnowsza wersja w stabilnym wydaniu Debiana wheezy. Trafi do niej Apache2.4 to będę taki testował. Rozwiązań produkcyjnych nie testuję na pakietach z wydania rozwojowego.

 

 

[tym 205]

To po co zadajesz pytania skoro wiesz najlepiej?

[Misiek08 285]

@tym - no właśnie tak samo straciłem chęć. To tak jakby testować <?php sleep(10); ?> i płakać na forum, że nginx + php-fpm wcale nie jest taki szybki, bo "Time per request" to 10+ sekund...

[Pan Kot 1535]

Archi, tak doskonale wiem co testuję i mam w tym cel. Nie widzę sensu testowania "statycznego" pliku. Równie dobrze idąc twoją logiką mógłbym testować czysty plik index.html. Tylko co taki test pokaże? Wydajność serwera www a nie wydajność serwera jeżeli chodzi o strony php a przecież mi o takie strony chodzi.

 

pedro84 - To jest najnowsza wersja w stabilnym wydaniu Debiana wheezy. Trafi do niej Apache2.4 to będę taki testował. Rozwiązań produkcyjnych nie testuję na pakietach z wydania rozwojowego.

 

 

 

http://www.apache.org/dist/httpd/Announcement2.4.html

 

A teraz powtórz, że apache 2.4 to wersja developerska.

 

I testuj dalej ilość requestów na skrypcie sleep(100);

 

Aha, i zaskoczę Cię. W wheezy nie ujrzysz 2.4. Do końca jego życia.

Edytowano Luty 7, 2014 przez Archi (zobacz historię edycji)

[krk 2]

 

 

Aha, i zaskoczę Cię. W wheezy nie ujrzysz 2.4. Do końca jego życia.

 

czemu ?

[igor_s 30]

Bo taka jest polityka Debiana. Samemu trzeba skompilowac lub skorzytac z nieoficjalnych repo.

[tym 205]

Czizys co za poziom. Powinno sie otworzyc newbiewht...

[PapaSmerf 497]

pedro84 - To jest najnowsza wersja w stabilnym wydaniu Debiana wheezy. Trafi do niej Apache2.4 to będę taki testował. Rozwiązań produkcyjnych nie testuję na pakietach z wydania rozwojowego.

To skompiluj sobie ze źródełka i dopiero wtedy można porównywać. Poza tym, testuj jakieś phpinfo() i wtedy zobaczysz różnicę.

 

Nginx + PHP-FPM zje Apacza na śniadanie. Przy 2.4 wyniki są zbliżone (różnice akceptowalne), ale na Apaczu będzie większe zużycie pamięci.

[shibby 54]

a ja myślałem, że na tym forum są ludzie rozumni i na poziomie...

 

@Archi - pokaż mi gdzie ja napisałem, że apache2.4 jest wersją developerską? Kłania się czytanie ze zrozumieniem. Napisałem, że używam paczek tylko ze stabilnego wydania debiana. Obecne stabilne wydanie debiana to Wheezy a w nim jest tylko Apache2.2. Paczka 2.4 jest w wydaniu jessie (testing). Dlatego napisałem, że nie testuję paczek rozwojowych (paczek z jessie) na wydaniu produkcyjnym. To, że Apache2.4 nie trafi do Wheezy to wiem ale przyjdzie taki dzień, że jessie stanie się wydaniem stable i wtedy przeskoczę na apache2.4. Tak więc nie wiem w czym ty widzisz problem.

 

@pedro84 - a co ja mam zobaczyć na phpinfo? To, że nginx szybciej wyświetla jedną funkcję? No to brawo. Ale jak to się ma do rzeczywistości, w której strony php posiadają bardzo rozbudowane skrypty. Tak więc specjalnie chciałem przetestować rozbudowany skrypt bo on tak naprawdę powinien pokazać faktyczną wydajność serwera przy realnym obciążeniu. Ponadto wielokrotnie tu czytałem, żeby testować na realnym środowisku np. stawiając wordpressa, dlatego testowałem bogaty w wyliczenia "benchmark" php a nie phpinfo czy echo "hello world".

 

Ponadto zamiast odbiegać od tematu, może do niego wrócimy. Pytanie wyraźnie tyczyło optymalizacji Apache a nie nginxa.

Pozdrawiam

 

 

[malu 460]

Jeżeli mówisz, że nie masz problemu z wydajnością serwera www to po co chcesz go optymalizować? : ) W końcu trudno mieć problemy z requestami http, jeżeli serwer zabijają Ci te do PHP. Ale skoro już pytasz to wpisz sobie nazwę MPM apache jaki używasz i w dokumentacji wszystko znajdziesz, nie dostaniesz gotowych reguł, to chyba oczywiste.

Już dostałeś odpowiedź, że najwydajniejszy sposób działania apache to mpm-event. Bez znaczenia jaką gałąź wybierzesz. Z tym, że w gałęzi 2.2 jest oznaczony jako "experimental". To jeżeli mówimy o pure http.

Jeżeli chcesz badać wydajność PHP to najwydajniejsze będzie mod_PHP bez żadnych dodatków typu mod_ruid2. Jednak skrypty będą działały wtedy z UID/GID serwera http, każdy myślący człowiek wie jakie będzie to miało skutki.

Wszystko zależy od tego jaki masz ruch i jakie jest środowisko serwera. (Czy jest w jakikolwiek sposób współdzielone czy to pomiędzy różne strony czy też użytkowników serwera).

W przypadku gałęzi 2.2 masz dwa wyjścia:
prefork + mod_php + ruid2 // itk + mod_php (Mniej problemów sprawia ruid2)
worker + fastcgi + fpm (Tu problem w Twoim przypadku bo mod_fastcgi nie ma w repo Debiana, a fcgid nie ma możliwości użycia zewnętrznego procesu PHP.)

W przypadku gałęzi 2.4:
event + proxy_fcgi + fpm

Edytowano Luty 10, 2014 przez malu (zobacz historię edycji)

[Misiek08 285]

a ja myślałem, że na tym forum są ludzie rozumni i na poziomie...

 

[...]

 

@pedro84 - a co ja mam zobaczyć na phpinfo? To, że nginx szybciej wyświetla jedną funkcję? No to brawo. Ale jak to się ma do rzeczywistości, w której strony php posiadają bardzo rozbudowane skrypty. Tak więc specjalnie chciałem przetestować rozbudowany skrypt bo on tak naprawdę powinien pokazać faktyczną wydajność serwera przy realnym obciążeniu. Ponadto wielokrotnie tu czytałem, żeby testować na realnym środowisku np. stawiając wordpressa, dlatego testowałem bogaty w wyliczenia "benchmark" php a nie phpinfo czy echo "hello world".

 

Ponadto zamiast odbiegać od tematu, może do niego wrócimy. Pytanie wyraźnie tyczyło optymalizacji Apache a nie nginxa.

Pozdrawiam

No jak widać poszerzasz grono tych nierozumnych bez poziomu. Jak chcesz testować różnice pomiędzy preforkiem, fastcgi, czy np. wydajność MPM to nie możesz dać skryptu wykonującego się 2-3 sekundy.

 

Sprawdzasz wtedy nie wydajność Apache'a, a PHP'a. Wtedy nie szukaj problemów z ww. tylko optymalizuj wszystko w php.ini, dorzucaj APC, eAcceleratory itd.

 

Nie możesz (tak, zabraniam) testowania wydajności serwera na skryptach typu benchmarki wykonujące w sumie milion lub miliard wyliczeń. Jeżeli chcesz przetestować wydajność całej platformy (Apache + PHP + baza +? cache) to robisz plik PHP, który wyświetla wynik jakiegoś zapytania z bazy + pobiera coś z cache (memcached czy inne tego typu historie). Nie benchmarki...

[shibby 54]

fastcgi jest w gałęzi debiana ale apt-get go nie widzi. Można natomiast go ściągnąć i ręcznie zainstalować przez dkpg. Takie rozwiązanie działa jak bajka.

 

Zaktualizowałem debiana do jessie by przetestować Apache2.4. Testuję #ab -n100000 -c200 http://localhost/infos.php

Oto kilka pomiarów (infos.php to phpinfo()

 

Apache2.4 (prefork) + mod_php

 

Server Software: Apache/2.4.7
Server Hostname: localhost
Server Port: 80

Document Path: /infos.php
Document Length: 81775 bytes

Concurrency Level: 200
Time taken for tests: 86.842 seconds
Complete requests: 100000
Failed requests: 8940
(Connect: 0, Receive: 0, Length: 8940, Exceptions: 0)
Total transferred: 8195589938 bytes
HTML transferred: 8177489938 bytes
Requests per second: 1151.52 [#/sec] (mean)
Time per request: 173.684 [ms] (mean)
Time per request: 0.868 [ms] (mean, across all concurrent requests)
Transfer rate: 92161.88 [Kbytes/sec] received

 

Apache2.4(prefork) + fastcgi + php-fpm

 

Server Software: Apache/2.4.7
Server Hostname: localhost
Server Port: 80

Document Path: /infos.php
Document Length: 78732 bytes

Concurrency Level: 200
Time taken for tests: 25.671 seconds
Complete requests: 100000
Failed requests: 10250
(Connect: 0, Receive: 0, Length: 10250, Exceptions: 0)
Total transferred: 7891288581 bytes
HTML transferred: 7873188581 bytes
Requests per second: 3895.50 [#/sec] (mean)
Time per request: 51.341 [ms] (mean)
Time per request: 0.257 [ms] (mean, across all concurrent requests)
Transfer rate: 300200.63 [Kbytes/sec] received

 

Nginx + php-fpm

 

Server Software: nginx/1.2.1
Server Hostname: localhost
Server Port: 8080

Document Path: /infos.php
Document Length: 78098 bytes

Concurrency Level: 200
Time taken for tests: 9.759 seconds
Complete requests: 100000
Failed requests: 97576
(Connect: 0, Receive: 0, Length: 97576, Exceptions: 0)
Non-2xx responses: 74233
Total transferred: 2040164714 bytes
HTML transferred: 2025142015 bytes
Requests per second: 10246.49 [#/sec] (mean)
Time per request: 19.519 [ms] (mean)
Time per request: 0.098 [ms] (mean, across all concurrent requests)
Transfer rate: 204145.81 [Kbytes/sec] received

 

Nginx w tym suchym teście najszybciej ale to co mnie najbardziej interesuje to widoczna przepaść między apache z mod_php a php-fpm.

 

[shibby 54]

 

Sprawdzasz wtedy nie wydajność Apache'a, a PHP'a. Wtedy nie szukaj problemów z ww. tylko optymalizuj wszystko w php.ini, dorzucaj APC, eAcceleratory itd.

 

dokładnie o optymalizację PHP mi chodzi. Nie mam na serwerze stron statycznych by skupiać się na optymalizacji samego serwera www. Widzę, że będę musiał po prostu postawić na tym serwerze jedną z moich wymagających stronek i porównać wyniki na rzeczywistym bycie. Wtedy wyniki powinny być najbardziej zbliżone do tego co chcę uzyskać.

[Misiek08 285]

Widzę, że powoli zaczynasz rozumieć ideę testów wydajności serwera www jako całości...

 

Postaw kopię takiej stronki, która normalnie działa i sprawdź. Tylko nie oczekuj wtedy już 10k req/s, ale z 300-500 myślę, że spokojnie wyciągniesz na jakiejś ciężkiej krowie.

[shibby 54]

kończąc temat.

 

trochę pomęczyłem się by każda stronka działała na różnych pulach fpm (z prawami danego usera) ale udało się i przyznam, że działa to bardzo ładnie. Widać znaczącą przewagę między tym rozwiązaniem a suPHP

[Miłosz 2311]

fastcgi jest w gałęzi debiana ale apt-get go nie widzi.

 

 

A dodałeś do wpisów repo non-free?