Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Ogromny "Load Time" na VPS. Od 3sec do nawet 40sec. Jak to naprawić?
Forum PHP.pl > Forum > Serwery WWW
piotrlis
Witam. Żeby nie przedłużać, napiszę tylko, że z problemem sam próbuje się uporać od 3 dni i dopiero teraz postanowiłem skorzystać z Waszej pomocy.

Moja konfiguracja:

VPS:
OVH SSD3 (2core, 8gb ram, 40gb ssd, debian7), Apache2, mysql, php5, memcache, mpm_prefork

Co na nim mam: Stronę korzystającą z PHP oraz JS, coś na wzór tej strony lub tej (obie działają na skryptach, które już testowałem, u mnie ładują się pół minuty, tutaj sekundę albo mniej)

Jaki jest problem: Load time, lub też po naszemu, czas ładowania, jest ogromny. Czasami, sporadycznie, wynosi on 3 Sekundy ale średnio jest on wyższy niż 10 a czasami dochodzi do 40-50s. Testowałem również inne skrypty i problem występuje na każdym, a sprawdziłem kilkanaście. Sprawdzany tutaj http://tools.pingdom.com/fpt

Skrypt korzysta z MongoDB i NodeJS, ale nawet gdy nie są jeszcze zainstalowane to i tak piekielnie "muli".

Czego już próbowałem:

instalacja memcache (tak, dodałem rozszerzenie do php.ini), rozszerzenie ramu dla PHP do 2gb, konfiguracja mpm_prefork, sprawdzanie różnych skryptów w celu przetestowania (ten sam problem), wyrzucenie wszystkich grafik ze skryptu
Czyli spędziłem 3 dni na testowaniu wszystkiego co znalazłem w google na ten temat, bez skutku sad.gif


Jeśli ktoś ma jakiekolwiek pomysły, co z tym "fantem" zrobić, byłbym bardzo wdzięczny za pomoc i nie zawaham się odwdzięczyć stawiając piwko (czteropak!) specool.gif

/edit

mam wrażenie, że skonfigurowanie KickAssCacheApc trochę pomogło, tak więc cała wina zamulania musi leżeć po stronie błędnie ustawionego cache'owania

/edit2

jednak kickass nie jest dobrym rozwiązaniem, bo przy każdym odświeżeniu strony wylogowuje mnie z niej
ohm
jakiś proces zżera ci zasoby? Być może za dużo operacji wykonujesz, lub za dużo VPSów na dedyku. Ogólnie potrzebna byłaby dokładniejsza analiza.
piotrlis
jak sprawdzam na tej stronie, którą podałem, to jedynym problemem jest słabe cacheowanie strony

gdy użyłem ww. metody tj KickAssCache, to czas ładowania spadł z kilku/kilkunastu sekund do mniej niż sekundy, z czego wnioskuje, że to właśnie brak poprawnego Cache'owania jest tutaj do naprawy
niestety na dłuższą metę to u mnie nie działa, bo przy użyciu tej metody przy każdym odświeżeniu następuje wylogowanie ze strony

vps mam tylko jeden, o parametrach podanych w pierwszym poście
Pyton_000
Co do vps-ów to chodziło o ilość na jednej fizycznej maszynie u Twojego hostingodawcy.

Poza tym trzeba sprawdzić Co tak na prawdę muli. Baza czy PHP, bo nie sądzę żebyś miał taki ruch żeby zamulić serwer.
Przy takim serwerze powinno śmigać.

Sprawdź w htop co zabiera Ci pamięć i procesor podczas wykonywania skryptu.

Pokaż też ustawienia apache
piotrlis
po wejściu w htop i odpaleniu strony nawięcej procesora (1%) zżerał sam htop, reszta procesów nawet nie dochodziła do 0.2%.

co zauważyłem, strona muli tylko przed zalogowaniem się za pośrednictwem Steam. gdy już uda się zalogować, wszystko działa błyskawicznie, podstrony ładują się w mgnieniu oka

tak mam ustawione apache2

http://pastebin.com/cmbgf9cx
athabus
Coś mi się wydaje, że masz podobny problem jak ja miałem (ten steam mi tutaj podchodzi) - tj. strona w czasie wykonywania skryptu łączy się z inną stroną i pobiera z niej jakieś dane/próbuje się wielokrotnie autoryzować etc.
Na szybko możesz sprawdzić netstatem czy w czasie wykonywania skyptu uruchamiają się jakieś połączenia do innych serwerów. Ale najlepsze rozwiązanie podpowiedział mi kolega w wątku wyżej - tj. po prostu użyć profilera xdebuga na serwerze i potem webgrindem prześledzić gdzie skrypt "utyka" - u mnie od razu problem wyskoczył jak na dłoni.
Raczej nie szukałbym problemu w serwerze i obciążeniu, bo trudno mi sobie wyobrazić zwykły skrypt, który wykonuje się 30s na mocnym vps, a który nie wykonuje żadnych poważnych operacji na dużych zbiorach danych.
piotrlis
Dzięki za odpowiedź.
Użyłem wymienionych przez Ciebie narzędzi, i gdy testuje index.php zalogowany to wszędzie jest ~0.00, ale na niezalogowanym wygląda to tak:

https://gyazo.com/9cf734c86afc02aab39fd62d5e000d67

A funkcja z '83.99' tak:

https://gyazo.com/58c0aa512867984c725ca2bbc6313f3f

Co ciekawe, plik userInfo.php istnieje, nie wiem dlaczego webgrind uważa, że nie dry.gif
athabus
No to już chyba masz na 100% odpowiedź, że coś nie działa w kwestii autoryzacji na Steam wnosząc po nazwie pliku. Albo serwery się nie dogadują (np. coś jest blokowane) albo funkcja zawiera jakiś błąd do poprawy typu się zapętla gdy jesteś niezalogowany i wysyła x żądań. Nie znam kompletnie ani skryptu ani Steam, więc tu już nie pomogę.

Co do webgrinda to pewnie pobrałeś plik wygenerowany przez profiler xdebug z serwera i analizujesz lokalnie? Jeśli tak, to nie widzi pliku, bo go na komputerze nie ma, ale to nic nie szkodzi - po prostu otwórz ten plik i zanalizuj w czym może być problem. W każdym razie teraz już na 99% masz taki problem, że Twój serwer czeka na jakieś dane od Steam i nie jest to problem wydajności, tylko oczekiwania na odpowiedź.
piotrlis
To jest bardzo dziwne, ale problem występuje chyba tylko na OVH. Kolega ma vps na digital ocean, dałem mu ten sam skrypt i u niego strona ładuje się od razu...

Prawda, mógłbym zmienic hosting, ale to chyba nie jest dobre rozwiązanie, bo ovh jest dobry, tylko właśnie nie rozumiem dlaczego tak muli na niezalogowanym :/

EDIT
sam przeszedłem na digital ocean (darmomy vps próbny) i jest dobrze.
może to coś z firewallem ovh?
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.