Długi czas odpowiedzi serwera (VPS)

[KulawyMo 2]

Witam,

 

jest to mój pierwszy post na forum więc liczę na pewna wyrozumiałość Jestem teraz na etapie konfiguracji serwera www na VPS pod jedną stronę na Wordpressie (z zaznaczeniem - traktuję to jako naukę, żadne zlecenie) i mam mały problem z czasem odpowiedzi po wywołaniu strony. Strona nie jest duża, zawiera 25 requestów, kilka obrazków, wtyczki ograniczone do minimum. Nie jest to również strona upubliczniona - jest na niej jeden user (ja) więc wysoka oglądalność to nie powód. Zresztą według pingdoma zawartość witryny ładuje się szybko (odpowiedzi są ok).

 

Każde narzędzie do pomiaru odpowiedzi jest bezlitosne - główny adres odpowiada dopiero po 4-5 sekundach:

 

 

 

Szukam przyczyny tak długiej odpowiedzi. Poniżej podstawowe informacje:

 

system - centos 7

wirtualizacja - virtuozzo (homecloud)

lokalizacja - Piaseczno

webserver - apache + nginx proxy

jakie PHP - event, 7.0.1 instalowane razem z Plesk

slowlog nic nie wykazuje

 

Konfiguracja VPS - 2x2Ghz, 2 GB RAM

CPU odpoczywa, RAM załadowany do poziomu 700 MB (włączając aktywny panel Plesk w tle)

 

Co wykonałem:
- odchudziłem apache'a z kilku modułów

- aktywowałem gzipa

- wgrałem do Wordpressa wtyczki do cache'owania (W3 Total cache)

- zmieniałem szablony, różnice nie były zbyt duże +/- 1s

- optymalizowałem serwer baz danych na bazie skanu i raportu MySQLtuner

 

Zmiany nie przyniosły jednak przełomu, choć malutką poprawę widać. Co możecie jeszcze w tym przypadku zaproponować? Nie liczę, że ktos zrobi wszystko za mnie, szukam tylko tropu jak zbadać co się dzieje z serwerem w tych kilku sekundach i dlaczego to tyle trwa.

 

Pozdrawiam

 

 

 

[WireBoot 3]

Przede wszystkim uruchom proces php strony za pomocą strace i sprawdzaj jakie elementy najdłużej przetwarza, które moduły wordpressa najbardziej go obciązają.

 

Czasami z serwera już nic nie wyciśniesz, a trzeba brać się za optymalizację samego skryptu.

[HaPe 242]

Dla w3 total cache włącz jeszcze po stronie serwera apcu oraz opcache i przy okazji aktywuj dla nich wsparcie w module.

[bybunny 540]

Z doświadczenia bazując na 240 serwerach dedykowanych + ponad 900 wirtualnych typu VPS/Cloud w odniesieniu do PLESK - apache + nginx proxy to nie jest dobre połączenie jeżeli chodzi o panel Plesk. Wszystko pięknie wygląda ale jak zacznie się ruch to ten twój VPS wywróci się na plecy. Bez zbędnych zabawek wordpress + apache (odpowiednia konfiguracja) + php 7 + Plesk - czas ładowania strony 1.39s

[KulawyMo 2]

Przede wszystkim uruchom proces php strony za pomocą strace i sprawdzaj jakie elementy najdłużej przetwarza, które moduły wordpressa najbardziej go obciązają.

 

Czasami z serwera już nic nie wyciśniesz, a trzeba brać się za optymalizację samego skryptu.

 

Dzięki za sugestię, sprawdziłem strace'a ale nie odnotowałem jakichś drastycznie złych wyników związanych z domeną, którą odpytuję. Mam za to masę takich śmieciowych logów, które nie wiem jak traktować:

 

 

19837      0.000060 <... epoll_wait resumed> {}, 25, 100) = 0
19889      0.000031 <... epoll_wait resumed> {}, 25, 100) = 0
19837      0.000015 epoll_wait(20,  <unfinished ...>
19875      0.000024 <... epoll_wait resumed> {}, 25, 100) = 0
19889      0.000024 epoll_wait(20,  <unfinished ...>
19875      0.000012 epoll_wait(20,  <unfinished ...>
19805      0.058974 <... poll resumed> ) = 0 (Timeout)
19805      0.000081 semop(1409029, {{0, -1, SEM_UNDO}}, 1) = 0
19805      0.000071 semop(1409029, {{0, 1, SEM_UNDO}}, 1) = 0
19805      0.000043 semop(1409029, {{0, -1, SEM_UNDO}}, 1) = 0
19805      0.000039 semop(1409029, {{0, 1, SEM_UNDO}}, 1) = 0
19805      0.000037 semop(1409029, {{0, -1, SEM_UNDO}}, 1) = 0
19805      0.000038 semop(1409029, {{0, 1, SEM_UNDO}}, 1) = 0
19805      0.000038 poll([{fd=16, events=POLLIN}], 1, 3000 <unfinished ...>
24059      0.040655 <... epoll_wait resumed> {}, 25, 100) = 0
20119      0.000038 <... epoll_wait resumed> {}, 25, 100) = 0
24059      0.000020 epoll_wait(20,  <unfinished ...>
20119      0.000019 epoll_wait(20,  <unfinished ...>
19837      0.000076 <... epoll_wait resumed> {}, 25, 100) = 0
19837      0.000028 epoll_wait(20,  <unfinished ...>
19889      0.000012 <... epoll_wait resumed> {}, 25, 100) = 0
19875      0.000031 <... epoll_wait resumed> {}, 25, 100) = 0
19889      0.000023 epoll_wait(20,  <unfinished ...>
19875      0.000012 epoll_wait(20,  <unfinished ...>
24059      0.099951 <... epoll_wait resumed> {}, 25, 100) = 0
20119      0.000019 <... epoll_wait resumed> {}, 25, 100) = 0
24059      0.000026 epoll_wait(20,  <unfinished ...>
20119      0.000010 epoll_wait(20,  <unfinished ...>
19837      0.000039 <... epoll_wait resumed> {}, 25, 100) = 0
19837      0.000030 epoll_wait(20,  <unfinished ...>
19889      0.000041 <... epoll_wait resumed> {}, 25, 100) = 0
19875      0.000017 <... epoll_wait resumed> {}, 25, 100) = 0
19889      0.000028 epoll_wait(20,  <unfinished ...>
19875      0.000013 epoll_wait(20,  <unfinished ...>
24059      0.099984 <... epoll_wait resumed> {}, 25, 100) = 0

Za namową SiXSwishlist wyłączyłem nginx na rzecz apache'a z PHP 7.0.1. Zmiany na minus nie widać, czas ładowania witryny dalej się waha od 3 do 7-8 sekund,

[bybunny 540]

Więc teraz jeszcze musisz ustawić odpowiednio apache bo na standardowej konfiguracji nadaje się pod witryny oparte jedynie o czysty html. Co do W3 Total cache nie jestem zwolennikiem takich rozwiązań bo doskonale wiem że bez tego śmiga również dobrze pozostawiając wolne zasoby które będą potrzebne gdy ruch wzrośnie. Pewnie mi się oberwie za to ale mam to w czterech literach. gzip jak najbardziej tak, pomyśl jeszcze o pagespeed. Da dodatkowego kopa. Również używamy pagespeed tyle że do przechowywania danych wykorzystujemy pod montowane niezależne storage.
Skoro o konfiguracji Apache wspomniałem sprawdź KeepAlive czy jest ON bo wygląda jak by nie było lub posiada za niski czas. Co do samej usługi, sam zobaczysz ale nie oczekuj że posiadasz rakietę. Raczej zwykły samolocik w korporacyjnych barwach co przekłada się na "Wait" zaznaczony na żółto.