TTFB - poprawa czasu odpowiedzi

[Mattpl]

Witam, rozkładam już ręce bo brakuje mi pomysłów na optymalizacje czasu odpowiedzi, który w ostatnim okresie uległ pogorszeniu. 2-3 tygodnie temu oscylował w granicach 0.8s wcześniej udało się wyciągnąć 0.5s a teraz to 1.2s. Mimo optymalizacji przeróżnych parametrów dla bazy/ apacha php'a  ta wartość stoi w miejscu

- Mysql - MariaDb 10.1 , przetestowałem kilka konfiguracji, używałem mysqltuner'a etc. 

- Php  w wersji 7.0 - php-fpm + opcache
- Apache 2.4 + ngix na revers_proxy + HTTP2
Wszystko aktualne.  Wydaje mi się że ten zestaw powinien działać sensownie i dosyć szybko.

Serwerownia kylos.pl, 32gb ramu, ssd. Baza spora i tu obstawiałem problem ale dorzuciłem jej ramu do wykorzystania, zwiększyłem cache i niestety nic to nie dało. Zainstalowałem Munina w piątek, niestety to moje pierwsze analizy i jedynie co rzuciło mi się w oczy to spore wykorzystanie pamięci przez cache.  WP na tym samym serwerze bez problemów, skrypty ładują się szybko więc wszystkie znaki na niebie przekonują mnie do samego skryptu / bazy.

Miałby ktoś chwilę rzucić okiem chociażby na munina i może zauważy wąskie gardło ewentualnie potwierdzić moje przypuszczenia że to strona.

Pozdrawiam 
 

Edytowane 17 Września 2018 przez Mattpl

[theqkash]

System jest na konkretnym CMS czy jakiś autorski twór?

[Mattpl]

Autorski i było już kilku Devów  więc każdy zostawił coś od siebie ;/

[Poziomecki]

Cache

[Mattpl]

jest  

[theqkash]

Myślę, że xhprof mógłby Ci tu pomóc. 

[Mattpl]

Dzięki za wskazówkę, w takim wypadku zabieram się za kolejne analizy 

[bybunny]

Odpal jeżeli możesz htop lub top w konsoli i powiedz mi ile pamięci ram jest wykorzystywane przez bazę danych. 

mysqltuner to fajne narzędzie lecz nie zawsze służy odpowiednią radą gdy na serwerze masz aplikacje różnego typy, Zresztą by zweryfikować wyniki mysqltuner potrzeba przynajmniej tygodnia obserwacji. Inna sprawa to czym testujesz odpowiedź serwera, równie dobrze problem może być ruch na sieci w DC który powoduje opóźnienie a sam serwer ma się bardzo dobrze. 

[Mattpl]

48 minut temu, SiXwishlist napisał:

Odpal jeżeli możesz htop lub top w konsoli i powiedz mi ile pamięci ram jest wykorzystywane przez bazę danych. 

mysqltuner to fajne narzędzie lecz nie zawsze służy odpowiednią radą gdy na serwerze masz aplikacje różnego typy, Zresztą by zweryfikować wyniki mysqltuner potrzeba przynajmniej tygodnia obserwacji. Inna sprawa to czym testujesz odpowiedź serwera, równie dobrze problem może być ruch na sieci w DC który powoduje opóźnienie a sam serwer ma się bardzo dobrze. 

Dzięki za dołączenie do tematu :) Ogólnie według DA zarezerwowane jest dla mysqld 11.47 GB. Mysqltunera oczywiście używałem w dłuższych odstępach czasu i oczywiście zawsze sugerował zwiększenie pewnych parametrów które uprzednio były zmieniane przy jego sugestii. Testuje pingdoomtools z lok. Szwajcaria, Pagespeed ins.. i webpagetest lok. Warszawa i Berlin

 

według top

i iotop,

[bybunny]

Do testu proponuje używać tej witryny: https://performance.sucuri.net/ , sprawdza kilka lokalizacji jednocześnie i ładnie pokazuje co się dzieje z TTFB. Z tego co napisałeś wynika że baza siedzi w pamięci, pójdziemy więc dalej. Pokaż co masz w apache i jakiego MPM używasz? To dość istotne informacje zanim ugryziemy pozostała część konfiguracji serwera.

[Mattpl]

ok, ogólnie jest to Apache z ngixem na reverse proxy - wcześniej był sam apach 2.4 - ta sama sytuacja w obu wypadkach.

Cytuj

Server MPM:     event
  threaded:     yes (fixed thread count)
    forked:     yes (variable process count)
Server compiled with....
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=256
 -D HTTPD_ROOT="/etc/httpd"
 -D HAVE_SYSTEMD
 -D SUEXEC_BIN="/usr/sbin/suexec"
 -D DEFAULT_PIDLOG="/var/logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"
 

 

i config dla Event:

  StartServers             6
    MinSpareThreads         32
    MaxSpareThreads        128
    ThreadsPerChild         64
    ServerLimit             32
    MaxRequestWorkers     2048
    MaxConnectionsPerChild   10000

Sprawdziłem też z Twojego urla - First Byte zaczyna się od 1.698s także jeszcze gorzej. 

Tak jak pisałem na przestrzeni jakiś 2-3 tygodni się pogorszyła sprawa 

Edytowane 17 Września 2018 przez Mattpl

[bybunny]

Masz duży ruch skoro używasz event? Raczej bym poszedł w prefork. Mimo że zdania są podzielone. Co do połączenie apache z nginx to sam odpowiedziałeś sobie na pytanie bo wąskim gardłem jest apache.  MinSpareServers i MaxSpareServers powinno być ustawione na zasadzie że obie wartości mają być sumą ServerLimit. Dodaj 128 do 64 i umieść tę wartość w ServerLimit. I oczywiście przeładuj serwer. Aczkolwiek i tak jest ona mała biorąc pod uwagę że masz 32GB RAM.

[Mattpl]

dziennie ok 5-6 tys. UU więc niewiele, szukałem  info na temat czy event/prefork/worker i gdzieś przeczytałem że w sumie event jest najbardziej elastyczny dlatego tak też ustawiłem, nie mam problemu z tym aby przejść na prefork. Wartości właśnie zmieniłem, przeładowałem, kolejne pomiary i sytuacja bez zmian

 

dla prefork mam coś takiego w configu

Cytuj

<IfModule mpm_prefork_module>
    StartServers          5
    MinSpareServers       5
    MaxSpareServers      10
    ServerLimit         450
    MaxRequestWorkers   450
    MaxConnectionsPerChild   10000
</IfModule>
 

za Twoją radą wówczas dla prefork server limit wynosi 15 ale w tym configu przydałoby się zapewne zwiększenie wartości.

//

Ok, ustawiony prefork, w configu dałem

MinSpareServers       350
    MaxSpareServers      450
    ServerLimit         800

 

czasy bez zmian.

Edytowane 17 Września 2018 przez Mattpl

[bybunny]

Ciekawe, skoro jesteś na prefork zrobimy małe doświadczenie. Dodaj do konfiguracji ustawienia jak poniżej, pożre tobie pamięć RAM ale powinno dać kopniaka:

 

Timeout 100
KeepAlive On
MaxKeepAliveRequests 200
KeepAliveTimeout 5

StartServers      5
MinSpareServers   200
MaxSpareServers   800
ServerLimit      1000
MaxClients       1000
MaxRequestsPerChild  10000
 

Poniżej test pierwszej z brzegu witryny opartej na wordpress na usłudze współdzielonej gdzie należy pamiętać że serwer masz do własnej dyspozycji, prawda?

 

[Mattpl]

Procesów oczywiście od groma, ale czasy bez zmian ;/ httpd-mpm.conf wleciał conf dla prefork i httpd-default.con wleciała reszta, reload i restart httpd były.

Edytowane 17 Września 2018 przez Mattpl

[bybunny]

coś gdzieś się zatyka, czy w logach masz jakieś błędy że np php ma czkawkę?

[Adam Szendzielorz]

6 minut temu, Mattpl napisał:

Procesów oczywiście od groma, ale czasy bez zmian ;/ httpd-mpm.conf wleciał conf dla prefork i httpd-default.con wleciała reszta, reload i restart httpd były.

 

Ja bym zaczął od złapania childa php-fpm stracem z parametrem -T. Tam zobaczysz ile sam PHP się wykonuje i ew. które syscalle trwają najdłużej (np. połączenia z bazą danych). Czyli:

 

strace -T -p PID

 

Ewentualnie strace -T -ttt -p PID będzie troszkę bardziej łatwiejsze do znalezienia w tym gąszczu 

Edytowane 17 Września 2018 przez Adam Szendzielorz

[Mattpl]

sprawdzałem i nic, zarówno dla php5.6 i php7 pusty error log

[bybunny]

testujesz tylko witrynę która jest na autorkim skrypcie tak? jak napisał Adam warto zmienić konfigurację php-fm w stosunku do pojedynczej witryny aczkolwiek powinien pojawić się błąd w logach że jest taki problem

[Mattpl]

ok miałem kilka pidów dla php-fpm7 akurat z tej wersji korzystam przy tym serwisie, odpaliłem i jest dosyć obszernie 

https://pastebin.com/eY9viNea

 

-- dokładnie, WP na tym serwerze nie ma problemów - TTFB na poziomie 0.184 secs

 

[Adam Szendzielorz]

1 minutę temu, Mattpl napisał:

ok miałem kilka pidów dla php-fpm7 akurat z tej wersji korzystam przy tym serwisie, odpaliłem i jest dosyć obszernie 

https://pastebin.com/eY9viNea

 

-- dokładnie, WP na tym serwerze nie ma problemów - TTFB na poziomie 0.184 secs

 

 

Zrób jeszcze raz to samo ale z -ttt - przy czym wyizoluj tylko ten jeden konkretny request, który jesteś pewien, że trwał te >1 sek

4 minuty temu, Mattpl napisał:

ok miałem kilka pidów dla php-fpm7 akurat z tej wersji korzystam przy tym serwisie, odpaliłem i jest dosyć obszernie 

https://pastebin.com/eY9viNea

 

 

Na pewno wszystkie syscalle rejestrujesz? Coś na moje oko za dużo tych lstatów. Za każdym requestem jest tak samo?

[Mattpl]

przy -ttt 

https://pastebin.com/YDjM6RWX

 

Nie wiem czy o to chodziło, odpalam strace i muszę go przerwać ctrl+c bo danych jest naprawdę dużo, przy każdym wykonaniu 

// dobra widzę chyba że jednak to nie ten PID dla zapytania z serwisu o TTFB

 

Coś dziwnego znalazłem  w Da ustawione dla domeny mam pierwsze php na 7.0 i odpalając plik phpinfo z domeny jest wersja 7.0 ale zatrzymując proces z php5.6 strona pada na pysk z errorem 

ERR_TOO_MANY_REDIRECTS

 

Ok już chyba wiem co jest

Na autorskim skrypcie (php70) jest sekcja z artykułami pobiera przy pomocy API z WP (php56) artykuły, podejrzewam że przy każdym request jest wykonywane zapytanie do WP. Zaraz wyłączę sekcję i zobaczę czy coś da.

 

Edytowane 17 Września 2018 przez Mattpl

[Adam Szendzielorz]

Teraz, Mattpl napisał:

przy -ttt 

https://pastebin.com/YDjM6RWX

 

Nie wiem czy o to chodziło, odpalam strace i muszę go przerwać ctrl+c bo danych jest naprawdę dużo, przy każdym wykonaniu 

 

O to, tylko musiałbyś w jakiś sposób wyizolować jeden konkretny request, inaczej to jest jeden wielki miks z którego niewiele wynika

Najlepiej jakbyś na kilka sekund np. przyblokował wszystkie skrypty (np. ustawił wymaganą autoryzację na stronie), odpalił straca i sam wszedł na stronę dokładnie jeden raz.

 

Można też inaczej - np. ustawić pm.max_requests = 1 w PHP-FPM (uwaga przy dużym ruchu bo może trochę trzepnąć serwer  i odpalić strace  dla parent procesu PHP-FPM przez:

 

strace -T -ttt -ff -o plikzlogiem -p PID

 

Tylko uwaga bo zapisze się wiele plików (pod nazwami plikzlogiem.PID). Potem tylko organoleptycznie znaleźć wśród nich ten właściwy i wszystko będzie widać;) Łatwiej jednak sposobem nr 1 :-)

[Mattpl]

Jak wyżej pisałem, udało się znaleźć  gdzie jest błąd - jest w sekcji z artykułami która jak teraz widać jest pobierana z WP przy każdym zapytaniu. Usunięcie sekcji  oczywiście sytuacje zmieniło diametralnie, ttfb = 215ms, teraz task dla programisty aby to poprawić.

 

 Bardzo dziękuje Wam za pomoc!

 

// Jeszcze pytanie  o https://performance.sucuri.net/ ,

pokazuje przy każdym teście realne wyniki czy odświeża co jakiś czas? Widże ttfb na poziomie 3s gdzie inne narzędzia pokazują 150-210ms

Edytowane 17 Września 2018 przez Mattpl

[Mion]

W dniu 17.09.2018 o 15:01, Poziomecki napisał:

Cache

 

W dniu 17.09.2018 o 15:05, Mattpl napisał:

jest  

Cache cachowi nie równe. Żle zaimplementowane cache  może być problematyczny lub nieoptymalny.

Kolejna sprawa i to bardzo ważna to indeksowania kolumn w tabelach i tu podobnie mamy dwa warianty - indeksy mogą pomóc lub pogorszyć wydajność, a to zależny od ich samych i typów operacji, jakie wykonuje serwer bazodanowy.

 

 

Do tego dochodzi jeszcze kwestia samych ustawień bazy danych np czy cały indeks sidzi w pamięci ram lub nawet cala baza w RAM ...