Skocz do zawartości
Mattpl

TTFB - poprawa czasu odpowiedzi

Rekomendowane odpowiedzi

Napisano (edytowane)

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 przez Mattpl

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

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

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

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

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

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

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

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

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

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. 

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
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

top.png.fd8ff84de16e59d295cdc1745d033508.png

i iotop,

iotop.png.d53d26486039fa64df8a1e269b8ca4b7.png

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

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.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
Napisano (edytowane)

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 ttfb.png.9e98cf906e0fcc383b2e80808c02a99c.png

Edytowane przez Mattpl

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

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.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
Napisano (edytowane)

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 przez Mattpl

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

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?

 

main_server_customer_test_page.png

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
Napisano (edytowane)

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.httpd.thumb.png.1473a352c961db895fa134bd23d49c9c.png

Edytowane przez Mattpl

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
Napisano (edytowane)
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 przez Adam Szendzielorz

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

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

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

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

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

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

 

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
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?

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
Napisano (edytowane)

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 przez Mattpl

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
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 :D 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 :-)

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
Napisano (edytowane)

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 przez Mattpl

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
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 ... 

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się

  • Przeglądający   0 użytkowników

    Brak zarejestrowanych użytkowników, przeglądających tę stronę.

×

Powiadomienie o plikach cookie

Korzystając z forum, wyrażasz zgodę na: Warunki użytkowania, Regulamin, Polityka prywatności.