Problemy z szyboscia strony, konfiguracja apache dla VPS Opcje

[soska66]

Sluchajcie, zapomnijcie o moim pierwszym poscie w tym temacie. Chce ugryzc istote problemu z innej strony

Czy mozecie pomoc w rozszyfrowaniu gdzie leza bledy konfiguracyjne na serwerze VPS? Zrobilem test strony za pomoca serwisu loadimpact.com i juz przy tescie na 20 klientow, strona siada calkowicie, opoznienie wg statystyki wynosi ponad 20s. Co jest nie tak?

Serwer ma 512mb ramu.
Na VPSsie jest zainstalowany Apache 2.2.3, PHP5, MySQL 5
PHP laczy sie z MySQL poprzez PDO, permanent connection jest wlaczone.
Doinstalowalem APC (Alternative PHP cache), ktory zwiekszyl liczbe request per seconds dla strony glownej z 20 do 70.

Ustawienia Apache

[HTML] pobierz, plaintext 
# prefork MPM
<IfModule mpm_prefork_module>
    StartServers          10
    MinSpareServers       10
    MaxSpareServers      20
    MaxClients          100
    MaxRequestsPerChild   1500
</IfModule>
[HTML] pobierz, plaintext 

MaxClients wydaje sie i tak za duzy (wg wzoru, MaxClients = (dostepna pamiec / wielkosc procesu Apache (u mnie kolo 15mb) ) bo powinien byc ustawiony na okolo 30, biorac pod uwage wolne zasoby. Ale i tak zmienianie tej wartosci a takze wylaczenie APC w zasadzie nie zmienia wynikow testu i przy 20 klientach strona siada. Serwer sie nie wiesza, ale opoznienia sa ogromne... strony w zasadzie nie da sie otworzyc podczas testu

Co przoczylem? Co jest nie tak?

Ten post edytował soska66 27.05.2010, 12:24:00

[jaslanin]

1. Czasami problemem jest to że korzystając z cacherów np. APC, PHP jest wykonywane na prawach apache.
2. Czasami jego wady są zaletami, przy włączonym np. przy "apc.stat = false", jak zmienisz plik to cache się nie zaktualizuje ale za to szybciej będzie działało. Przy wordpresie nie można mieć z kolei włączonego "apc.include_once_override"
3. Raczej zużycie pamięci jest mniejsze, bo nie trzeba za każdym razem parsować kodu tylko od razu jest on przetwarzany na op-code.
4. APC cachuje każdy plik osobno, jeżeli 2 klientów używa jednego pliku, to używają jednego zcachowanego pliku (op-code). Odnośnie konfiguracji shared memory można poczytać np. tu: http://www.imminentweb.com/technologies/tu...php-performance

Ten post edytował jaslanin 27.05.2010, 14:05:13

[soska66]

1. Czasami problemem jest to że korzystając z cacherów np. APC, PHP jest wykonywane na prawach apache.
2. Czasami jego wady są zaletami, przy włączonym np. przy "apc.stat = false", jak zmienisz plik to cache się nie zaktualizuje ale za to szybciej będzie działało. Przy wordpresie nie można mieć z kolei włączonego "apc.include_once_override"
3. Raczej zużycie pamięci jest mniejsze, bo nie trzeba za każdym razem parsować kodu tylko od razu jest on przetwarzany na op-code.
4. APC cachuje każdy plik osobno, jeżeli 2 klientów używa jednego pliku, to używają jednego zcachowanego pliku (op-code). Odnośnie konfiguracji shared memory można poczytać np. tu: http://www.imminentweb.com/technologies/tu...php-performance

Dzieki za odnosniki i pomoc... poczytam i pobawie sie konfiguracja

Takie pytanie, ab pokazuje mi w wynikach testu

[HTML] pobierz, plaintext 
Complete requests:      100
Failed requests:        23
   (Connect: 0, Length: 23, Exceptions: 0)
 
[HTML] pobierz, plaintext 

Failed request, Length... o co chodzi? Jest jakas wartosc, ktora okresla max wielkosc zapytania?

Robie ponowne testy serwera. Upgradowalem go do 1024mb ramu i zainstalowalem APC. Wyglada na to, ze dzieki cachowaniu php, zaleznosc MaxClients od dostepnej pamieci RAM nie jest juz tak scisla jak wychodzi ze wzoru. Ustawilem MaxClients na 200, czyli toretycznie o wiele za duzo niz powinno byc przy okolo 700mb wolnej pamieci, a mimo to, przy tescie na 250 klientow, caly czas pozostaje wolne ponad 200mb ramu.

Kilka dni temu robilem test na serwerze z 512mb ram i bez zainstalowanego APC... MaxClients wynosilo 150 - serwer padl calkowicie przy tescie na 100 klientow

Ten post edytował soska66 27.05.2010, 17:56:46