Time to first byte - 10 sekund co około 2/3 minuty

[Fizyda 34]

Brakuje mi już pomysłu czym może być spowodowane tak duże opóźnienie do pierwszego byte'u podczas wczytywania stron, czas ten wynosi średnio około 10 sekund i występuje co kilka minut, około 2/3 minut.

 

Początkowo myślałem że to problem z SSL, ale do stron statycznych jest wszystko w porządku, więc zająłem się php-fpm, tutaj też okazało się ok. W tej chwili podejrzewam Wordpressa, ale problem dotyczy czystej instalacji bez pluginów.

Totalnie zgłupiałem i nie wiem w czym może tkwić problem. Może ktoś coś podpowiedzieć, nakierować gdzie szukać problemu.

 

Dodam jeszcze, że powiedzmy w przedziale czasu N gdzie jest to czas pomiędzy jednym długim wczytywaniem strony, a kolejnym strona wczytuje się w przeciągu 1 do 2 sekund.

 

Próbowałem instalować WP Super Cache oraz W3 Total Cache, nic nie pomogły.

 

PS. Sprawdziłem czas wykonywania się skryptu i wychodzi na to, że to on wykonuje się tyle czasu, początkowo myślałem że to problem z tym że php musi wystartować bo nie był używany przez N czasu i to właśnie tworzy opóźnienie.

[Gość mariaczi]

Jak z zapytaniami do bazy - one Ci nie opóźniają przetwarzania.

[MaTyyy 2]

Czas wypuszczenia strony do klienta sprawdzałeś? Wygląda mi na cache po prostu, dlatego tak szybko Ci ładuje co 1-2 minuty, a resztę podaje od nowa i po prostu zamula.

 

Sprawdź querki i I/O

[Fizyda 34]

Jak z zapytaniami do bazy - one Ci nie opóźniają przetwarzania.

 

Też już tak myślałem, ale zapytań jest coś w okolicach 22-27, nie pamiętam w tej chwili. Problem nie leży raczej w tym że baza zamula bo phpmyadmin działa przyzwoicie.

 

Przykład obciążenia z phpmyadmina, pierwszy szczyt żądanie do strony obsłużone w normalnym czasie, drugi i trzeci w ramach 10sekundowego ładowania strony, czwarty również w normalnym czasie.

 

EDIT:

Test z pingdom

 

Czas wypuszczenia strony do klienta sprawdzałeś? Wygląda mi na cache po prostu, dlatego tak szybko Ci ładuje co 1-2 minuty, a resztę podaje od nowa i po prostu zamula.

 

Sprawdź querki i I/O

Cache żadnego nie instalowałem, strona stoi na VPS SSD1 OVH którego obciążenie to 1-7% generowane przez serwer TS3.

Edytowano Sierpień 25, 2016 przez Fizyda (zobacz historię edycji)

[Fizyda 34]

W końcu udało mi się złapać odpowiedni moment na WebPagetest, oto wynki:

[likufanele 77]

Jaki webserwer? Jaka wersja PHP?

 

Trochę to wygląda jakby Wordpress próbował dzwonić gdzieś do domu, ale nie może się połączyć więc następuje timeout. Sprawdź coś może w tym kierunku.

[Fizyda 34]

Jaki webserwer? Jaka wersja PHP?

 

Apache 2.4.10, PHP 5.6.24 (fpm) na Debian Jessie.

 

 

Trochę to wygląda jakby Wordpress próbował dzwonić gdzieś do domu, ale nie może się połączyć więc następuje timeout. Sprawdź coś może w tym kierunku.

 

Nie powinien używać dziwnych portów więc nie powinien mieć problemu, wszystkie funkcjonalności typu pobieranie pluginów czy szablonów działają bez zastrzeżeń, więc połączenie z wordpress.org jest.

Jak mogę to dla pewności sprawdzić? Może nie jak tylko czym.

[MaTyyy 2]

W logach tego nie będzie? Powinno być jeżeli dostaje cokolwiek timeouta.

[Gość Spoofy]

eh..... weź sobie zaloguj albo przez php albo po stronie mysql'a wszystko jak leci + zbadaj iopsy na serwerze i będziesz znał odpowiedź.

[Fizyda 34]

Dla pewności jeszcze dziś przejrzałem logi apache, niestety nic nie widać z wyjątkiem 10 sekundowego opóźnienia pomiędzy żądaniem do root, a kolejnych zasobów ze strony.

W logach php też nic, włączałem wcześniej slowlog i ustawiłem nawet na 1 sekundę by mieć porównanie pomiędzy normalnym żądaniem a wydłużonym i nie ma między nimi żadnej różnicy.

 

Osobiście zastanawiam się czy przypadkiem wp_cron nie zamula strony, ale to by było bezsensu ponieważ w3 total cache powinien temu zapobiec, poza tym jest to czysty (prawie) wordpress i w cron są tylko domyślne zadania. Prawie czysty ponieważ mam na nim swoje pluginy i styl i dobrze wiem jak one działają, dodatkowo problem występuje nawet z wyłączonymi pluginami i stylem.

[bybunny 540]

Tu masz odpowiedź.

...trona stoi na VPS SSD1 OVH.....

Dla porównania strona oparta o wordpress nienależąca sama w sobie do lekkich bo trochę tych modułów posiada + nabitą skórkę ,postawiona na usłudze współdzielonej razem z tysiącami innych stron First Bite wynosi 0.595

First Bite 0.367s - podobnie opakowany wordpress na VPS-e od aruba który można powiedzieć że ledwo "zipie" bo strona ma kilka tysięcy wejść dziennie nie wspomnę już jak trafi na wykop.

 

Przejrzał bym config samego apache bo tam jest problem pomijając już że to VPS który może działać różnie.

Edytowano Sierpień 27, 2016 przez SiXwishlist (zobacz historię edycji)

[Fizyda 34]

Tu masz odpowiedź.

 

 

Dla porównania strona oparta o wordpress nienależąca sama w sobie do lekkich bo trochę tych modułów posiada + nabitą skórkę ,postawiona na usłudze współdzielonej razem z tysiącami innych stron First Bite wynosi 0.595

 

First Bite 0.367s - podobnie opakowany wordpress na VPS-e od aruba który można powiedzieć że ledwo "zipie" bo strona ma kilka tysięcy wejść dziennie nie wspomnę już jak trafi na wykop.

 

Przejrzał bym config samego apache bo tam jest problem pomijając już że to VPS który może działać różnie.

 

Jutro zerknę, ale czy możliwe byłoby że problem jest tylko z worpdressem a inny skrypt działa poprawnie?

[bybunny 540]

Masz na myśli inne skrypty wykorzystujące apache/php?

[Fizyda 34]

Masz na myśli inne skrypty wykorzystujące apache/php?

 

Tak dokładnie tak, mam jeszcze phpMyAdmina i z nim nie ma problemów.

 

Ja już naprawdę siedziałem nad problemem 2 dni zanim napisałem posta, w tym czasie szukałem rozwiązania w google, ale żadne nie pasowało. Objawy były czasami podobne, ale problem leżał gdzie indziej.

Konfigurację również przewertowałem, zarówno apache jak i php. Wiele w niej względem preinstalowanej konfiguracji nie zmieniałem, doszedł jedynie modsecurity, zmiana mpm na event włączenie rewrite, natomiast w php doinstalowany był mysql, w php.ini kilka zmian dotycząca zablokowania paru funkcji no i w obu przypadkach ukrycie informacji o wykorzystywanym sofcie na serwerze.

 

Dziś może spróbuję jeszcze przerzucić całą stronę na hosting współdzielony dosłownie copy - paste, jak będzie działał ok to znaczy że konfiguracja, a jak nie to może aktualizacja wordpressa nie przeszła poprawnie (aktualizacja automatyczna, dzień po instalacji wyszła nowa wersja).

Edytowano Sierpień 28, 2016 przez Fizyda (zobacz historię edycji)

[bybunny 540]

Dalej twierdzę że to konfiguracja. phpMyAdmin masz zainstalowany w katalogu tam gdzie strona czy tylko dowiązany po vhoscie? Zmieniłeś MPM na event i tu masz już rozwiązanie:

 

"The big difference is that it uses a dedicated thread to deal with the kept-alive connections, and hands requests down to child threads only when a request has actually been made (allowing those threads to free back up immediately after the request is completed)."

 

To jest to twoje 10s by rozpocząć nowy proces i go przetrzymać tak długo jak masz w konfiguracji Apache. Do chwili kiedy proces działa ten czas spada ale jak wygaśnie potrzebuje ponownie tych 10s by go utworzyć.

[Fizyda 34]

SiXwishlist dzięki wielkie za zainteresowanie tematem i próbę pomocy .

Dalej twierdzę że to konfiguracja. phpMyAdmin masz zainstalowany w katalogu tam gdzie strona czy tylko dowiązany po vhoscie?

Na vhoscie.

Zmieniłeś MPM na event i tu masz już rozwiązanie:

Worker działa identycznie, prefork również. Gdyby tak było problem dotyczyłby również stron statycznych, a one się wczytują w mgnieniu oka. Sprawdzam pod rożnymi przeglądarkami oraz na drugim komputerze.

Dodam jeszcze dla jasności że nie mówię tutaj o pierwszym żądaniu po restarcie serwera, bo to ma prawo zamulić, lecz o kolejnych.

Jeśli nadal podejrzewamy konfigurację apache/php to może jeszcze być problem z proxy_fcgi. Ale tutaj nie ma co konfigurować bo zwyczajnie brak pliku conf dla modułu. Natomiast php pod vhosty podpinam w następujący sposób:

<FilesMatch "\.php$">
       SetHandler "proxy:unix:/var/run/php5-fpm-user.sock|fcgi://localhost/"
</FilesMatch>

Edit:

 

Podpiąłem vhosta z wp pod domyślny socket php-fpm (na którym działa phpmyadmin) tak gdybym skopsał tutaj konfigurację, niestety nie ma żadnej różnicy.

 

Nawiązując jeszcze do:

 

To jest to twoje 10s by rozpocząć nowy proces i go przetrzymać tak długo jak masz w konfiguracji Apache. Do chwili kiedy proces działa ten czas spada ale jak wygaśnie potrzebuje ponownie tych 10s by go utworzyć.

Strona z wp potrafi zamulić jeśli np używam ją przez kilka minut z przerwami kilku sekund między kolejnymi żądaniami.

 

Edytowano Sierpień 28, 2016 przez Fizyda (zobacz historię edycji)

[bybunny 540]

Nie jestem wstanie wnikać w twoją konfigurację serwera/VPS-a bo nie mam aż tyle czasu. Podejrzewam że wszystko sprowadza się do 2GB pamięci i niestety jednego rdzenia CPU ale opierając o dobrą konfigurację według mojej opinii można genialnie wykorzystać. Apache dostaje zadyszki a MPM event i prefork nie działają identycznie.

Sprawdź zawartość:

<IfModule event.c>
    StartServers          
    MinSpareThreads      
    MaxSpareThreads     
    ThreadsPerChild      
    MaxClients          
    MaxRequestsPerChild   
</IfModule>

i

pm.max_children = 
pm.start_servers = 
pm.min_spare_servers = 
pm.max_spare_servers = 
pm.max_requests = 

Znajdziesz tam odpowiedź

[Fizyda 34]

StartServers                     2
MinSpareThreads          25
MaxSpareThreads          75
ThreadLimit                      64
ThreadsPerChild          25
MaxRequestWorkers         150
MaxConnectionsPerChild   0

pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
;pm.max_requests = 500

Wartości domyślne, nie zajmowałem się nimi bo serwer jeszcze nie jest "oddany" dla użytkowników, korzystam z niego na razie tylko ja. Wydaje mi się że domyślne opcje nie powinny być aż tak tragiczne by problemy były z jednym userem korzystającym z serwera.

[Fizyda 34]

Rozwiązanie:

 

Udało mi się zlokalizować problem, tak jak podejrzewałem wina była po stronie WP, choć nie do końca ponieważ problem wystąpił w WP przez chyba nietypową konfigurację serwera.

 

Problemem było to że WordPress po coś sam siebie odpytuje, powodowało to błąd:

stream_socket_client(): unable to connect to ssl://www.my-addr.com:443 (Connection timed out)

wywołania:

WP_Http->post()
 wp-includes/class-http.php:576
wp_remote_post()
 wp-includes/http.php:187
spawn_cron()
 wp-includes/cron.php:333
wp_cron()
 wp-includes/cron.php:360
do_action('init')
 wp-includes/plugin.php:524

Jak widać jest to w core, ma to związek z cron'em wordpressa, nie mam pojęcia po co i o co chodzi. Problemem było to że WP nie mógł połączyć się z serwerem ponieważ jak przypuszczam nie dało się ustalić adresu ip serwera lub z jakiegoś powodu nie dało się zroutować połączenia wychodzącego z adresu ip X na adres ip serwera na którym pracował WP czyli też X.

Wystarczyło dodać do /etc/hosts na sztywno www.my-add.com czyli:

127.0.0.1    www.my-addr.com

Myślę że przeszłoby też ustawienie własnego DNS'a który obsługiwałby dodatkowo sieć wewnętrzną i zwracał adresy IP nie publiczne tylko prywatne. W tedy problem też nie powinien wystąpić.

 

Nie powinno być też problemu w momencie gdyby serwer miał publiczne IP, w moim przypadku jest on za NATem. Może ktoś ma pomysł jak rozwiązać ten problem bardziej automatycznie, tak by nie trzeba było dodawać każdej obsługiwanej domeny do hosts? Już nie chodzi mi o pracę tylko o zaśmiecanie pliku.

Edytowano Wrzesień 7, 2016 przez Fizyda (zobacz historię edycji)

[ksk 67]

Postawić lokalny serwer DNS ?