Michal Mizera

Michal Mizera właściciel, NetGlob
PUI

Temat: nginx vs apache

Mariusz Gronczewski:
cóźż, ucz się lub znajdź kogoś obeznanego w tym, taki serwerek powinien uciągnąć taki ruch bez większego problemu


:) W pierwszym poscie napisalem ze szukam kogos takiego. Mam nawet jakies tam fundusze na to przeznaczone. Wiec jak ktos ma ochote sobie dorobic, to zapraszam na prv ktorego podalem w pierwszym moim poscie :)

Ja tym czasem, douczam sie i jakos malo z tego wychodzi :)
Maciej Natan Milaszewski

Maciej Natan Milaszewski Kierownik dzialu IT
/ sys administrator

Temat: nginx vs apache

A nie mozesz zrobic - wyklikac sobie haproxy i dwa nody apachowe i php fast-cgi i zyskasz skalowalnosc predkosc i rozwiazanie problemu
Adam Tomasz K.

Adam Tomasz K. Zaawansowana
modyfikacja
rzeczywistości.

Temat: nginx vs apache

Sławomir Lipowski:
Adam Tomasz Kajer:
(...)
Powinno zadziałać mniej więcej takie coś:

<Directory "/var/www">
AllowOverride None
</Directory>

<Directory "/var/www/1/2">
AllowOverride All
</Directory>

ale sprawdź. :-) Tu można też się zastanawiać czy to dużo pomoże, w końcu coś i tak ma przeszukiwać. Kwestia organizacji webaplikacji i testów czy takie wybiórcze włączanie .htaccess coś daje.

A czy ma szansę działać coś w rodzaju:

Directory "/var/www">
AllowOverride None
</Directory>

<Directory "/var/www/1/2">
AllowOverride All
</Directory>

Directory "/var/www/1/2/3">
AllowOverride None
</Directory>

Jeśli tak, to czy można wykluczyć jakoś wszystkie podkatalogi?

A co Ciebie powstrzymuje aby to sprawdzić samemu? Trochę ciekawości i zaangażowania. :-)
Adam Tomasz K.

Adam Tomasz K. Zaawansowana
modyfikacja
rzeczywistości.

Temat: nginx vs apache

Michal Mizera:
Adam Tomasz Kajer:
Michal Mizera:
Panowie, piszecie tu takie straszne zeczy :)

Ja mam inny problem, nie znam sie :) a potrzebuje optymalizacji serwera. Stworzylem taki maly wortalik spolecznosciowy o wycieczkach rowerowych (http://rwm.org.pl) i jak przychodzi "Dzien Sądu" czytaj relacja na zywo z Harpagana, to za kazdym razem zabija mi maszyne.

W przeciagu 1.5 roku bylo okolo 5.5 mln odslon... taki ruch mniej wiecej generuje.

Ilość stron w roku dużo nie mówi w kontekście tego co piszesz. Jaki ruch jest w "dzień sądu" (w przybliżeniu), ile requestów na minutę/sekundę. Jakie masz łacze, są filmy w flv, duże pliki (foty). Masa innych pytań... o bazę chociażby. Optymalizacji może być masa albo i wcale. Najważniejsze jeszcze pytanie co to znaczy "zabija maszynę"?

okolo 70 reqestow na sekunde jest w "dniu sadu". Na codzien, 30 reg/sek. 75,78% z tego to select.

Łacze, symertyczne 2 mbpsy wpiete w światlowód tasku. W nocy 23:30 - 11:00 symetryczne 8 mbpsow. Usluga realizowana przez JarSat.

Nie ma duzych filmow, najwiekszy plik ma kilka megabajtow (filmiki z aparatow jak ktos na wyceiczce kreci). Głownie zdjecia po kilkaset kilo i miniaturki (w relacjach jest okolo 120 000 zdjec)

Zabija, znczy procki swiruja na 100%, load wskakuje na +40 a wyswieltenie strony graniczy z cudem.

Mozesz pytac o co chcesz, na to co wiem odpowiem, co nie wiem zapytam sie osoby ktora pisala strone i tez odpowiem.

Jak świrują procki to odpal program top, htop i obserwuj co obciąża procesor. Zapisz użycie pamięci (free -m), zaobserwuj czy nie korzysta mocno z pamięci swap, co z I/O dysków?

Jak znajdziesz przeciążający system proces to można szukać odpowiedzi dlaczego ten proces tak przeciąża system. Czy to jego wina czy danych (ilości, formy,...), w tym momencie może być niezbędne stworzenie testu. Przykładowo stwierdzisz, że to apache, musisz stworzyć test badający obciążenie serwera wraz ze wzrostem ilości zapytań, itd...
Michal Mizera

Michal Mizera właściciel, NetGlob
PUI

Temat: nginx vs apache


Jak świrują procki to odpal program top, htop i obserwuj co obciąża procesor. Zapisz użycie pamięci (free -m), zaobserwuj czy nie korzysta mocno z pamięci swap, co z I/O dysków?

Jak znajdziesz przeciążający system proces to można szukać odpowiedzi dlaczego ten proces tak przeciąża system. Czy to jego wina czy danych (ilości, formy,...), w tym momencie może być niezbędne stworzenie testu. Przykładowo stwierdzisz, że to apache, musisz stworzyć test badający obciążenie serwera wraz ze wzrostem ilości zapytań, itd...


Zawsze na szczycie TOP sa procesy apache. Czasami nawet 4 sztuki. Merginalnie jeden z nich potrafi nawet 40% procka zrzerac. Pamieci nigdy wiecej niz 8% nie widzialem przy apachu. Potem pojawia sie mysql, ale nie wiecej niz 10% procka i 5% pamieci. Czasami jakis proftpd wskoczy na chwile, ale to tak 5% cpu i troche pamieci, potem smieci po 1% - 0%

brit mizera # free -m
total used free shared buffers cached
Mem: 3968 3684 284 0 161 2327
-/+ buffers/cache: 1194 2774
Swap: 7817 13 7804

memcache ma zarezerwowane 2 Gb ramu, choc puki co go nie uzywamy, bo nie umiemy :)

kilka rzeczy mozna wywnioskowac tez stad:
http://netglob.com.pl/mrtg
user: mrtg
pass: mrtg777

nie widac momentu przeciazenia, bo ostatni trwajacy okolo 6h byl w pazdzeirniku. Koljeny bedzie za 2 miesiace (kolejna edycja Live z Harpagan39). Stad cala burza. Potem mamy prowadzic Live z eliminacji mistrzostw swiata w jezdzie rowerem na orientacje MTBO. Chcialbym sie przygotowac za wczasu na te ewentualnosci.

Piszesz o stres testach, uzylem kiedys czegos, nie pamietam, ale pamietaqm wynik. Chodzilo o zasymulownie 10 userow klikajacych na strone glowna. Odslaniajac zwykla strone html dochodzil do 1600 odslon na minute i zaczely pojawiac sie straty. Dla joomli i wordpressa wynik bylo okolo 1200 - 1400 na minute. Dla strony glownej rwm... 98 :/ dla strony live-a 270, forum 180.
Wiem ze softa do stres testu instalowalismy lokalnie na maszynie i mozna nim bylo tez odpytywac obce serwery. Jak sie nazywal, nie pamietam, a szkoda bo bym go teraz z nowymi prockami wyprubowal.

Temat: nginx vs apache

Adam Tomasz Kajer:

(...)
A co Ciebie powstrzymuje aby to sprawdzić samemu?

Brak czasu. Zakładałem, że kilka osób, które już to wiedzą/sprawdzały odpowie, że się nie da i będzie pozamiatane...
Trochę ciekawości i zaangażowania. :-)

... i wolnego czasu ... :( Jak tylko się znajdzie, to z wrodzonej ciekawości i dociekliwości to sprawdzę.

konto usunięte

Temat: nginx vs apache

Na pierwszy rzut oka śmierdzi mi galeria. Pliki statyczne są chyba serwowane przez coś serverside no i miniatury wyglądają na generowane w locie.

Obaczcie panowie
http://rwm.org.pl/relacje/?&mode=galeria&id=1688

Michale, jak to z tym jest?Peter K. edytował(a) ten post dnia 15.02.10 o godzinie 01:50

konto usunięte

Temat: nginx vs apache

Poza tym, Michał... postaw to na nowo:) "Wieszakowi" daj w dziub, zleć komuś konkretnemu, albo użyj jakiegoś open source'a. Dziura na dziurze. Jak chcesz, mogę Ci zdalnie odciążyć serwer w kilka momentów :)Peter K. edytował(a) ten post dnia 15.02.10 o godzinie 02:14
Michal Mizera

Michal Mizera właściciel, NetGlob
PUI

Temat: nginx vs apache

Peter K.:
Na pierwszy rzut oka śmierdzi mi galeria. Pliki statyczne są chyba serwowane przez coś serverside no i miniatury wyglądają na generowane w locie.

Obaczcie panowie
http://rwm.org.pl/relacje/?&mode=galeria&id=1688

Michale, jak to z tym jest?Peter K. edytował(a) ten post dnia 15.02.10 o godzinie 01:50

Miniaturka jak i zdjecie jest obrabiane w czasie dodwania i zapisywane na dysku. Katalogi sa po 10k plikow. Czyli zdjecie ne 105 542 bedzie w katalogu /zdjecia/11/ a jego minitura w katalogu /miniatury/11/

Miniatury sa pobierane z dysku, w locie twozyly sie kiedys, dawno dawno temu.

System wywala w galerii 12 fotek danego usera galeri, nastepne sie przewija. Dodajac zdjecie, rownierz nie wyswietlaja sie wszystkie miniaturki danej galerii, a ostatnie 8em. Reszta jest dostepna po kliknieciu w link, tak by nie trzeba bylo za duzo miniturek naraz wyswietalc (czasami w jednej galeri jest kilka tysiecy fotek).

Co do napisania od poczatku, wiem, zdaje sobie z tego sprawe ale wieszak tego nie poczyni, a nie znam nikogo kto by mogl. Pozatym, jest to portal spolecznosciowy, ja na nim nie zarabiam, wrecz przeciwnie, dokladam i utrzymuje go a co za tym idzie, wylozeniu ... tysiecy zl na przepisanie tego... narazie pozostaje w swerze mazen. Moze kiedys. Mam jeszcze mase pomyslow o co to wzbogacic, ale nie ma komu tego pisac... szkoda. Ja w miare swoich mozliwosci bede to powoli robil.

Na dzis, temat jest taki, ze trzeba to zoptymalizowac od strony softow na serwerze, technologia opteronow w tym wydaniu sie juz konczy i bardziej nie ma juz co unowoczesniac sprzeta. Jak okaze sie ze sie nie da, znowu trzeba bedzie zmieniac platforme, a to kolejne koszty... nie male zreszta.

Wiem ze kazdy za swoja prace pragnie otrzymac wynagrodzenie, fundesze takie jakie sa, takie sa. Lokalne jednostki niechca wesprzec projektu.

Ja, ja chce jezdzic rowerem i dobrze sie bawic :)

konto usunięte

Temat: nginx vs apache

Michal Mizera:

Miniaturka jak i zdjecie jest obrabiane w czasie dodwania i zapisywane na dysku. Katalogi sa po 10k plikow. Czyli zdjecie ne 105 542 bedzie w katalogu /zdjecia/11/ a jego minitura w katalogu /miniatury/11/

Miniatury sa pobierane z dysku, w locie twozyly sie kiedys, dawno dawno temu.

Ale serwis zdjęcie wypluwa chyba przez php. Alokuje bez sensu pamięć na załadowanie i wypchanie tego do użytkownika. Powinien być zaserwowany jako statyczny plik bez użycia php.

Na dzis, temat jest taki, ze trzeba to zoptymalizowac od strony softow na serwerze, technologia opteronow w tym wydaniu sie juz konczy i bardziej nie ma juz co unowoczesniac sprzeta. Jak okaze sie ze sie nie da, znowu trzeba bedzie zmieniac platforme, a to kolejne koszty... nie male zreszta.

Serwis ma straszne dziury, które pozwalają go zdalnie skasować kilkoma akordami klawiszy. Moim zdaniem nie opłaca się tego optymalizować i rzeźbić w przysłowiowym gównie.

Rozejrzyj się, który darmowy system oferuje taką funkcjonalność której potrzebujecie. Może koledzy na "programiści www" coś doradzą. Ja się nie znam na dotępnych rozwiązaniach
Wojciech O.

Wojciech O. Operator
magnetowidów/telewiz
ja Polsat - w
poszukiwaniu n...

Temat: nginx vs apache

Niekoniecznie. Michał pochodź trochę po stronie i sprawdź co Ci wypluwają logi oraz top/inne narzedzie monitorujące obciężenie. Będziesz wiedział, który fragment kodu zapycha serw. I później można optymalizować ten fragment. Oprócz tego sprawdź czy nie ma problemów z odczytem z DB.
Michal Mizera

Michal Mizera właściciel, NetGlob
PUI

Temat: nginx vs apache

Dogrzebalem sie do tego stress testu... i:

siege --time=60s -c 100 http://rwm.org.pl

Lifting the server siege... done.
Transactions: 769 hits
Availability: 100.00 %
Elapsed time: 60.45 secs
Data transferred: 6.55 MB
Response time: 6.35 secs
Transaction rate: 12.72 trans/sec
Throughput: 0.11 MB/sec
Concurrency: 80.84
Successful transactions: 769
Failed transactions: 0
Longest transaction: 14.84
Shortest transaction: 0.00

teraz cos na wordpress:
siege --time=60s -c 100 http://about.rwm.org.pl

Lifting the server siege... done.
Transactions: 969 hits
Availability: 100.00 %
Elapsed time: 60.19 secs
Data transferred: 7.27 MB
Response time: 5.36 secs
Transaction rate: 16.10 trans/sec
Throughput: 0.12 MB/sec
Concurrency: 86.29
Successful transactions: 603
Failed transactions: 0
Longest transaction: 14.33
Shortest transaction: 0.02

i cos bez baz danych i php:
siege --time=60s -c 100 http://mizera.pl

Lifting the server siege... done.
Transactions: 11957 hits
Availability: 100.00 %
Elapsed time: 59.59 secs
Data transferred: 19.42 MB
Response time: 0.00 secs
Transaction rate: 200.65 trans/sec
Throughput: 0.33 MB/sec
Concurrency: 0.63
Successful transactions: 11957
Failed transactions: 0
Longest transaction: 0.15
Shortest transaction: 0.00

aktualne obciazenie prockow w ruchu:
2 x apache 77% oraz 20% pamiec odpwoeidnio 11% i 3% poza tym mysql 2% procka i 1.5% pamieci, przy takim obciazeniu wlaczylem stress test.

Jak widac strona glowna rwm, niewiele ustepuje stronie glownej wordpressa.

Zeby obraz byl pelny, podam jeszcze test dla galeri pelnej zdjec:
Lifting the server siege... done.
Transactions: 503 hits
Availability: 100.00 %
Elapsed time: 60.27 secs
Data transferred: 49.94 MB
Response time: 9.81 secs
Transaction rate: 8.35 trans/sec
Throughput: 0.83 MB/sec
Concurrency: 81.91
Successful transactions: 503
Failed transactions: 0
Longest transaction: 21.54
Shortest transaction: 0.00

Wnioski.... hmm.. galeria wypada lepiej niz glowna, to moze jeszcze live:

Lifting the server siege... done.
Transactions: 395 hits
Availability: 100.00 %
Elapsed time: 60.02 secs
Data transferred: 11.86 MB
Response time: 11.19 secs
Transaction rate: 6.58 trans/sec
Throughput: 0.20 MB/sec
Concurrency: 73.62
Successful transactions: 395
Failed transactions: 0
Longest transaction: 28.19
Shortest transaction: 0.01

i chyba ostatnie potrzebny test, to test przywolania zdjecia:

siege --time=60s -c 100 http://rwm.org.pl/relacje/?pobierz-zdjecie,105995

Lifting the server siege... done.
Transactions: 3977 hits
Availability: 100.00 %
Elapsed time: 59.96 secs
Data transferred: 6.16 MB
Response time: 0.99 secs
Transaction rate: 66.33 trans/sec
Throughput: 0.10 MB/sec
Concurrency: 65.77
Successful transactions: 3977
Failed transactions: 0
Longest transaction: 3.92
Shortest transaction: 0.00

"z tego co sie doczytalem to chodzi o usatwienie tego mpm_worker lub mpm_prefork i odpowiendich limitow dla nich. Macie wypracowane jakies ich wartosci ?"

Temat: nginx vs apache

Gdy używasz mpm_worker + phpa przez fastcgi to generalnie tuning jest głównie dla plików statycznych, jeżeli chodzi o liczbe procesów phpa, ja zwykle ustawiam ją na liczba_rdzeni x2 gdy baza jest na innym serwerze lub po prostu na liczbe rdzeni gdy baza jest na tym samym serwerze (teoria jest taka że gdy baza jest na innym serwerze i jeden proces na danym rdzeniu zajmuje sie czekaniem na powrót requestu z bazy, drugi proces może tobić coś innego)

Co do samego wordpressa, plugin wp-cache jest bardzo pomocny, potrafi skrócić czas ładowania strony o połowę albo więcej dla stron zcachowanych (jest też wp-supercache ale dosyć skomplikowany w konfiguracji)
Michal Mizera

Michal Mizera właściciel, NetGlob
PUI

Temat: nginx vs apache

Mariusz Gronczewski:
Gdy używasz mpm_worker + phpa przez fastcgi to generalnie tuning jest głównie dla plików statycznych, jeżeli chodzi o liczbe procesów phpa, ja zwykle ustawiam ją na liczba_rdzeni x2 gdy baza jest na innym serwerze lub po prostu na liczbe rdzeni gdy baza jest na tym samym serwerze (teoria jest taka że gdy baza jest na innym serwerze i jeden proces na danym rdzeniu zajmuje sie czekaniem na powrót requestu z bazy, drugi proces może tobić coś innego)

Czy fakt ze mamy ispOmege jest istotny w tym temacie ?

Co do samego wordpressa, plugin wp-cache jest bardzo pomocny, potrafi skrócić czas ładowania strony o połowę albo więcej dla stron zcachowanych (jest też wp-supercache ale dosyć skomplikowany w konfiguracji)

wordpress jest malo obciazajacy, to blog zmian jakie uskuteczeniamy na stronie. Odwiedzalnosc zedu 10 odslon dziennie. Podalem jako przyklad porownawczy.
Michal Mizera

Michal Mizera właściciel, NetGlob
PUI

Temat: nginx vs apache

a wiec prace ida naprzod. Po odpaleniu fastcgi okazalo sie ze cos sie z sesjami stalo. Zamiast prcesy odpalac sie jako apache odpalaja sie jako userzy vu1001 itd.... coprawda oni nalaza do grupy apacha... ale cos sie kitrasi.

Nie mniej jednak, sprawy ida do przodu. :)
Michal Mizera

Michal Mizera właściciel, NetGlob
PUI

Temat: nginx vs apache

i sesje udalo sie naprostwac.

Zrobilismy kolejny strestest, dociazylismy sie na 3 minuty i zakonczylismy test. Jednak 5 minut po zakonczeniu testu top wciaz pokazuje mase procesow obciazajacych:

12430 vu10002 20 0 130m 8600 3456 R 19 0.2 0:01.99 php-cgi
12471 vu10002 20 0 130m 8716 3316 R 18 0.2 0:00.66 php-cgi
10796 vu10002 20 0 130m 9.9m 4688 R 17 0.3 0:12.75 php-cgi
12310 vu10002 20 0 130m 9916 4500 R 17 0.2 0:02.07 php-cgi
12204 vu10002 20 0 130m 8688 3460 R 17 0.2 0:06.22 php-cgi
12335 vu10002 20 0 130m 9152 3952 R 17 0.2 0:02.10 php-cgi
12397 vu10002 20 0 130m 9.9m 4656 R 17 0.2 0:02.70 php-cgi
12327 vu10002 20 0 194m 9.9m 4640 R 16 0.2 0:03.66 php-cgi
4340 mysql 20 0 1021m 197m 5188 S 16 5.0 3:38.05 mysqld
12133 vu10002 20 0 130m 10m 4824 R 16 0.3 0:03.58 php-cgi
12360 vu10002 20 0 194m 8856 3480 R 16 0.2 0:02.09 php-cgi
12054 vu10002 20 0 138m 31m 16m R 16 0.8 0:05.97 php-cgi
12221 vu10002 20 0 128m 8660 3504 R 15 0.2 0:05.74 php-cgi
12417 vu10002 20 0 128m 8828 3472 R 15 0.2 0:01.43 php-cgi
11471 vu10002 20 0 193m 8228 3556 S 15 0.2 0:07.90 php-cgi
12412 vu10002 20 0 129m 8432 3232 S 15 0.2 0:01.42 php-cgi
12201 vu10002 20 0 193m 8468 3544 S 14 0.2 0:05.69 php-cgi
12454 vu10002 20 0 130m 8364 3264 R 12 0.2 0:00.37 php-cgi
12355 vu10002 20 0 129m 8488 3284 S 11 0.2 0:02.93 php-cgi
12331 vu10002 20 0 127m 7852 3448 S 11 0.2 0:02.15 php-cgi
11495 vu10002 20 0 127m 8200 3544 S 9 0.2 0:07.31 php-cgi
12422 vu10002 20 0 193m 7888 3444 S 8 0.2 0:02.16 php-cgi
11524 vu10002 20 0 128m 8816 3512 R 8 0.2 0:07.30 php-cgi
12263 vu10002 20 0 130m 9968 4640 R 8 0.2 0:03.18 php-cgi
9755 vu10002 20 0 130m 9.9m 4720 R 7 0.2 0:15.65 php-cgi
9572 vu10002 20 0 130m 10m 5216 R 6 0.3 0:16.74 php-cgi
12447 root 20 0 21064 3036 1136 S 6 0.1 0:01.85 htop
12356 vu10002 20 0 130m 9880 4504 R 5 0.2 0:03.12 php-cgi
12466 vu10002 20 0 127m 8096 3096 R 5 0.2 0:00.16 php-cgi
12387 vu10002 20 0 129m 8176 3508 S 5 0.2 0:02.93 php-cgi
12392 vu10002 20 0 130m 9896 4648 R 3 0.2 0:01.58 php-cgi
7591 vu10007 20 0 133m 28m 19m S 1 0.7 0:03.41 php-cgi
12434 vu10002 20 0 193m 7872 3448 S 1 0.2 0:01.45 php-cgi
11375 vu10002 20 0 129m 9324 4624 S 1 0.2 0:09.85 php-cgi
7592 vu10007 20 0 131m 22m 16m S 1 0.6 0:03.24 php-cgi

wedlug licznika gosci, wzrosl ich poziom do okolo 2560 sztuk w trakcie testu. Strona odswierzala sie okolo 15 sek. Nie gubil sie ale zamulal.

Kawalek krotkiego testu:

Benchmarking http://rwm.org.pl (be patient)
Finished 59 requests

Server Software: Apache
Server Hostname: http://rwm.org.pl
Server Port: 80

Document Path: /
Document Length: 29642 bytes

Concurrency Level: 10
Time taken for tests: 30.069 seconds
Complete requests: 59
Failed requests: 51
(Connect: 0, Receive: 0, Length: 51, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 0
Total transferred: 1764659 bytes
HTML transferred: 1749260 bytes
Requests per second: 1.96 [#/sec] (mean)
Time per request: 5096.441 [ms] (mean)
Time per request: 509.644 [ms] (mean, across all concurrent requests)
Transfer rate: 57.31 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.4 0 1
Processing: 3829 4823 336.3 4855 5439
Waiting: 3829 4823 336.3 4855 5439
Total: 3830 4823 336.1 4855 5439

Percentage of the requests served within a certain time (ms)
50% 4852
66% 4974
75% 5026
80% 5057
90% 5275
95% 5417
98% 5425
99% 5439
100% 5439 (longest request)

Co moga robic te procesy po tym jak test sie zakoczyl, i czemu zdychaja pomalu przez 20 minut a nie gina odrazu ?

Temat: nginx vs apache

Michal Mizera:

Co moga robic te procesy po tym jak test sie zakoczyl, i czemu zdychaja pomalu przez 20 minut a nie gina odrazu ?
Zdychają pomału bo serwer wykorzystuje je ponownie jak przyjdzie nowe żądanie, czyli zamiast startować nowy wykorzystuje już instniejący.
Mógłbyś wkleić config fastcgi jakiego używasz ?
Michal Mizera

Michal Mizera właściciel, NetGlob
PUI

Temat: nginx vs apache

Mariusz Gronczewski:
Michal Mizera:

Co moga robic te procesy po tym jak test sie zakoczyl, i czemu zdychaja pomalu przez 20 minut a nie gina odrazu ?
Zdychają pomału bo serwer wykorzystuje je ponownie jak przyjdzie nowe żądanie, czyli zamiast startować nowy wykorzystuje już instniejący.
Mógłbyś wkleić config fastcgi jakiego używasz ?


<IfModule mod_fcgid.c>
AddHandler fcgid-script .php .php5
IPCConnectTimeout 20
DirectoryIndex index.php
</IfModule>

to chyba tylko tyle tego.

Temat: nginx vs apache

Spróbuj po IfModule dodać

MaxProcessCount 8

i przejechac ponownie testem
Michal Mizera

Michal Mizera właściciel, NetGlob
PUI

Temat: nginx vs apache

Po wprowadzeniu tej linijki:

Benchmarking http://rwm.org.pl (be patient)
Finished 285 requests

Server Software: Apache
Server Hostname: http://rwm.org.pl
Server Port: 80

Document Path: /
Document Length: 17034 bytes

Concurrency Level: 10
Time taken for tests: 30.010 seconds
Complete requests: 285
Failed requests: 20
(Connect: 0, Receive: 0, Length: 20, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 0
Total transferred: 4929054 bytes
HTML transferred: 4854669 bytes
Requests per second: 9.50 [#/sec] (mean)
Time per request: 1052.982 [ms] (mean)
Time per request: 105.298 [ms] (mean, across all concurrent requests)
Transfer rate: 160.40 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.4 0 3
Processing: 460 1036 169.0 1034 1652
Waiting: 460 1036 169.5 1033 1652
Total: 460 1036 169.0 1034 1652

Percentage of the requests served within a certain time (ms)
50% 1033
66% 1091
75% 1118
80% 1162
90% 1234
95% 1303
98% 1416
99% 1591
100% 1652 (longest request)

konkluzje:

ten sam czas, czyli 30 sek
przed wprowadzeniem tej linijki bylo:

----------------------------------------
przed:
Benchmarking rwm.org.pl (be patient)
Finished 59 requests

po:
Benchmarking http://rwm.org.pl (be patient)
Finished 285 requests
----------------------------------------
przed:
Complete requests: 59
Failed requests: 51

po:
Complete requests: 285
Failed requests: 20
--------------------------------------
przed:
100% 5439 (longest request)

po:
100% 1652 (longest request)



Wyślij zaproszenie do