Długi czas odpowiedzi serwera - presta 1.6.1.9

[Jacup]

Cześć! Prowadzę sklep oparty na presta 1.6.1.9 (właściwie to prowadzę go po kimś innym). W sklepie jest ~800 produktów. 

Od jakiegoś czasu sklep zaczął dość wolno chodzić - wciąż szukam przyczyny. Mógłby ktoś mnie trochę naprowadzić?

Nie chcę robić reklamy, więc nie wrzucam całych testów z GTmetrixa. Co mogę sprawdzić w pierwszej kolejności( i ew. jak?)

 

Robiąc teraz po godzinie 20 jest w miare ok, ale w południe czas oczekiwania (pierwsza linia w waterfall GTmetrixa) trwa nawet 12sekund, reszta po kilka ms. Wina po stronie serwera (stoi na OVH)?

 

 

 

 

Edited October 24, 2017 by Jacup
zalaczniki edit (see edit history)

[hakeryk2]

Musisz wykonać testy poprzez ustawienie profilowania czasu wykonywania się poszczególnych modułów oraz zapytań SQL. Aby to zrobić udaj się pliku \config\defines.inc.php i zmień wartość define('_PS_DEBUG_PROFILING_', false); na true. Oczywiście zrób to na trybie serwisowym ponieważ wtedy gdy wrócisz na podstronę produktu na dole pod stopką pojawi się pełna lista w jakim czasie jaki moduł się wykonał i ogólny czas wykonywania skryptu oraz ogólne bardzo ważne informacje. Możesz wkleić tutaj screena z tego, bez dumpów bazy danych.

Ponadto wspomniałeś o godzinach że raz działa tak, a raz tak i skoro to OVH to jaki pakiet? VPS czy wspóldzielony?  Miałem ostatnio podobną sytuację, że również czasy oczekiwania na wygenerowanie podstrony wynosiły po 10-12 sekund i zacząłem już czytać wszystkie logi, robić przegląd całego serwera a okazało się, że winę ponosił serwer matka usługodawcy, no bo przecież ruch był średni, nic nie zmieniałem a serwer zaczął powoli działać. Zgłosiłem ticket na hosting i otrzymałem odpowiedź, że pracują nad usunięciem awarii.

 

W httaccess też chyba nie dodałeś expires header dla różncych rodzajów plików. Przykładowy wartości które warto wkleić do htaccess jeśli ich tam nie masz.

 

<IfModule mod_expires.c>
	ExpiresActive On
	ExpiresByType image/gif "access plus 1 month"
	ExpiresByType image/jpeg "access plus 1 month"
	ExpiresByType image/png "access plus 1 month"
	ExpiresByType text/css "access plus 1 week"
	ExpiresByType text/javascript "access plus 1 week"
	ExpiresByType application/javascript "access plus 1 week"
	ExpiresByType application/x-javascript "access plus 1 week"
	ExpiresByType image/x-icon "access plus 1 year"
	ExpiresByType image/svg+xml "access plus 1 year"
	ExpiresByType image/vnd.microsoft.icon "access plus 1 year"
	ExpiresByType application/font-woff "access plus 1 year"
	ExpiresByType application/x-font-woff "access plus 1 year"
	ExpiresByType application/vnd.ms-fontobject "access plus 1 year"
	ExpiresByType font/opentype "access plus 1 year"
	ExpiresByType font/ttf "access plus 1 year"
	ExpiresByType font/otf "access plus 1 year"
	ExpiresByType application/x-font-ttf "access plus 1 year"
	ExpiresByType application/x-font-otf "access plus 1 year"
</IfModule>

<IfModule mod_headers.c>
	Header unset Etag
</IfModule>
FileETag none
<IfModule mod_deflate.c>
	<IfModule mod_filter.c>
		AddOutputFilterByType DEFLATE text/html text/css text/javascript application/javascript application/x-javascript font/ttf application/x-font-ttf font/otf application/x-font-otf font/opentype
	</IfModule>
</IfModule>

<ifModule mod_gzip.c>
	mod_gzip_on Yes
	mod_gzip_dechunk Yes
	mod_gzip_item_include file .(html?|txt|css|js|php|pl)$
	mod_gzip_item_include handler ^cgi-script$
	mod_gzip_item_include mime ^text/.*
	mod_gzip_item_include mime ^application/x-javascript.*
	mod_gzip_item_exclude mime ^image/.*
	mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifModule>

 

Edited October 24, 2017 by hakeryk2 (see edit history)

[Jacup]

Cześć, odpisuje dopiero teraz, problemem wydawały się być boty, które zawalały łącze. Boty zostały wyeliminowane, podejrzewam że problemem będą albo grafiki, albo połączenie z bazą danych. Co do grafik, przy wgrywaniu skaluje je do max 700px, przy czym rozmiar zazwyczaj wynosi 50-100kb. Jest też masa starych zdjęć, które mogą zajmować więcej ale kiedyś nie stanowiło to problemu i strona śmigała dobrze.

Zrobiłem profiling, załączam pliki ze strony głównej oraz panelu logowania admina.

 

Jeśli chodzi o htaccess to tylko fragment kodu dot. gzipa nie był u mnie w pliku, reszta identyczna.

 

 

 

 

[hakeryk2]

Kolego najpierw usuń zdjęcie z profilowania panelu admina - nie potrzebuje tego a ponadto podałeś swój adres logowania do admina.

Druga sprawa - te liczby są absolutnie astronomiczne - 50 sekund na stronę główną? Spróbuj zmienić na "Nigdy nie kompiluj szablonów" w Wydajności i powyłączaj Memcached jeśli w ogóle masz włączony lub cacheFS czy tam system plików na dole. Coś tutaj jest definitywnie nie tak. Zrób zrzut ustawień z zakładki w panelu Admina -> Parametry zaawansowane -> Wydajność -  (całej)  tym razem nie podawaj w screenie URL do adresu panelu admina.

[Piotr K.]

Odpal klon sklepu na dobrym serwerze i porównaj wyniki, jak będzie dalej taki syf to masz namieszane po stronie sklepu, jak wyniki będę w miarę normalne to serwer jest jaki jest...

[Jacup]

Przesyłam screen z ustawień wydajności.

Wczoraj strona mi całkowicie siadła, padł error w stylu: "User x already has more than 'max_user_connections' active connections"

Baza danych jest przyczyną? jakaś optymalizacja zapytań potrzebna?

 

 

 

Edited November 23, 2017 by Jacup (see edit history)

[Piotr K.]

Wyłącz ten cache na dole. Co to za sklep i ile masz odwiedzin dziennie w sklepie? sto? tysiąc? milion? Bo serwer nie wyrabia.

[Jacup]

Sklep z elektronarzędziami, kraftdele.info.

W listopadzie średnio 1700 wizyt dziennie.

W zeszłym miesiącu sklep nawiedziły boty, w jeden dzień 100 tyś wizyt i strona całkowicie padała.

Edited November 23, 2017 by Jacup (see edit history)

[hakeryk2]

Co do "User x already has more than 'max_user_connections' active connections" to konfiguracja serwera nie daje rady.  Należy zwiększyć to w ustawieniach serwera ale to raczej zgłoś się do hostingodawcy.

Co do ustawień to to co @Piotr K. wspomniał i tak jak przypuszczałem - wywal na amen cache na samym dole "użyj pamięci podręcznej" na NIE. Jest to potężny zamulacz. Wyłącz również opcję minimalizuj HTML ponieważ nie jest do końca wydajna i lepiej skorzystać z mod_pagespeed od Google.

[Jacup]

Cache wyłączone, po weekendzie także spróbuje z tym mod_pagespeed. 

[Jacup]

Powyższe zmiany nie przyniosły efektów, jest godzina godzina 7 rano a strona wyrzuca po minucie ładowania błąd '504 Gateway Time-out'.  Pingdom, GTmetrix wyrzucają błąd connection error (1 request).

[hakeryk2]

Musiałbyś to zlecić komuś do sprawdzenia (raczej za kasę) ponieważ coś wydaje mi się, że problem jest bardziej złożony i lista rzeczy do sprawdzenia jest spora.

Przygotuj dane do panelu admina, do FTP, do obsługi serwera i załóż wątek w zleceniach na forum.
Możesz też podesłać mi te dane na PW i spróbuję coś zobaczyć.

[Jacup]

Prawdopodobnie będę zmieniać serwer na mocniejszy, na infolinii ovh powiedzieli mi że wykorzystuje przydzielone zasoby w ponad 90%. A poranny error 504 spowodowany był pracami technicznymi w ovh. Aktualnie strona chodzi, najdłużej czeka się na odpowiedź serwera, jak już załapie to zawartość się ładuje dobrze.

 

Swoją drogą, od jakiegoś miesiąca same problemy z tym ovh. Raz padły serwery, raz łącze za słabe, co chwile coś.

[hakeryk2]

Proponuję przenieść się na własny VPS (sam polecam webh.pl) bo ostatnio się poprawili i często mam czasy od 200 ms do 1000ms (w zależności od rozgrzania cache) ale ogólnie jest ok.

Tak czy siak - powinieneś pomyśleć nie tylko nad hostingiem ale i optymalizacją wszystkich modułów, cache (zarówno presty, przeglądarki i serwera). Sprawdzić czy coś nie jest bottleneckiem itp. Czasami takie zabiegi wystarczają by przyspieszyć serwis bez konieczności zmiany hostingu.