  |
|
| ° Forum ° Odpowiedz ° Rejestracja ° Szukaj ° | |
| Numizmatyka - monety ° Internetowa Auto gie³da ° |
 |
Forum / php / Testowanie strony - apache bench (ab) |
| Autor | Wiadomo¶æ |
| lamer
|
Posted: 19 Lut 2010 18:02:23 Hej Postanowiłem sprawdzić jak działa moja strona przy użyciu ab. Wrzuciłem stronę na 3 hostingi: 1) tani współdzielony hosting - 50 zł/rocznie - linuxpl.com 2) RPS1 od OVH - 1,2 GHz (kupiony wczesniej dlatego gorszy proc) 3) RPS1 od OVH - 1,6 GHz Puściłem b -n20 -c6 http://strona.com.pl/TEST Wyniki: 1) 124.85 req/s 2) 7.9 req/s 2) 15 req/s Teraz info z cat proc/cpuinfo: 1) processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 67 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ stepping : 3 cpu MHz : 3000.000 cache size : 1024 KB bogomips : 5999.65 processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 67 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ stepping : 3 cpu MHz : 3000.000 cache size : 1024 KB bogomips : 5999.65 czyli: 12000 bogomips 2) processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 22 stepping : 1 cpu MHz : 1200.022 cache size : 512 KB bogomips : 2400.04 3) processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 28 stepping : 2 cpu MHz : 1596.090 cache size : 512 KB bogomips : 3192.18 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 28 stepping : 2 cpu MHz : 1596.090 cache size : 512 KB bogomips : 3160.47 Nie wiem czy cos mi to nie klamie, bo procesor powinien byc 1-rdzeniowy, tak jak w przypadku 2) ;/ Idea RPS polega na tym, ze nie maja swojego dysku- korzystaja z jakiegos po sieci. Czy brak dysku robi taka roznice czy jednak procesor? A moze mozna jakos zoptymalizowac system, zeby te RPSy byly szybsze? lamer |
| Lemat
|
Posted: 19 Lut 2010 18:19:23 Hej
Postanowiłem sprawdzić jak działa moja strona przy użyciu ab. Wrzuciłem stronę na 3 hostingi: 1) tani współdzielony hosting - 50 zł/rocznie - linuxpl.com 2) RPS1 od OVH - 1,2 GHz (kupiony wczesniej dlatego gorszy proc) 3) RPS1 od OVH - 1,6 GHz Puściłem b -n20 -c6 http://strona.com.pl/TEST Wyniki: 1) 124.85 req/s 2) 7.9 req/s 2) 15 req/s Teraz info z cat proc/cpuinfo: 1) processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 67 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ stepping : 3 cpu MHz : 3000.000 cache size : 1024 KB bogomips : 5999.65 processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 67 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ stepping : 3 cpu MHz : 3000.000 cache size : 1024 KB bogomips : 5999.65 czyli: 12000 bogomips 2) processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 22 stepping : 1 cpu MHz : 1200.022 cache size : 512 KB bogomips : 2400.04 3) processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 28 stepping : 2 cpu MHz : 1596.090 cache size : 512 KB bogomips : 3192.18 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 28 stepping : 2 cpu MHz : 1596.090 cache size : 512 KB bogomips : 3160.47 Nie wiem czy cos mi to nie klamie, bo procesor powinien byc 1-rdzeniowy, tak jak w przypadku 2) ;/ Idea RPS polega na tym, ze nie maja swojego dysku- korzystaja z jakiegos po sieci. Czy brak dysku robi taka roznice czy jednak procesor? A moze mozna jakos zoptymalizowac system, zeby te RPSy byly szybsze? lamer za małe masz -n niektóre serwery używają softu typu eaccelerator i pierwsze requesty trwają długo - bo musi się skrypt skompilować a kolejne już idą szybko, bo skompilowany kod jest dociągany z kesza. Dlatego n bym polecał zrobić 1000 następnie jest istotne gdzie puściłeś AB. Jeżeli puściłeś go z domu to masz narzut w postaci ruchu sieciowego z Francją. następnie jest istotne co oprócz AB dany serwer robił. Bo jeżeli obsługiwał naszą-klasę to nic dziwnego, że czasy będą inne niż na "pustej" maszynie. następnie jest istotne skomplikowanie samego skryptu oraz to, czego oprócz proca i pamięci dany skrypt używał. W celu zrobienia miarodajnych testów powinno się robić takie testy jak przy benchmarkach dla pecetów czyli - operacje stałoprzecinkowe, zmiennoprzecinkowe, alokacja pamięci, czytanie z dysku małych plików, czytanie z dysku dużego pliku etc. I wynik testu powinien być średnią tych składowych. |
| lamer
|
Posted: 19 Lut 2010 18:40:50 za małe masz -n
niektóre serwery używają softu typu eaccelerator i pierwsze requesty trwają długo - bo musi się skrypt skompilować a kolejne już idą szybko, bo skompilowany kod jest dociągany z kesza. Dlatego n bym polecał zrobić 1000 Jak jest większe to czekam dłużej na wyniki ;/ następnie jest istotne gdzie puściłeś AB. Jeżeli puściłeś go z domu to
masz narzut w postaci ruchu sieciowego z Francją. Wbiłem na każdy serwer po SSH i puściłem z niego. Za każdym razem kopia witryny była na jakiejś domence hostowanej na tym serwerze. następnie jest istotne co oprócz AB dany serwer robił. Bo jeżeli
obsługiwał naszą-klasę to nic dziwnego, że czasy będą inne niż na "pustej" maszynie. Top pokazuje, że nic się tam nie dzieje. Odpaliłem jako root na tych RPS. następnie jest istotne skomplikowanie samego skryptu oraz to, czego oprócz
proca i pamięci dany skrypt używał. Bardzo prosta stronka pisana wieki temu jeszcze- wypluwanie HTML z PHP, łączenie z bazą (bazy nie instalowałem nigdzie, więc error) przy pomocy mysql_connect, kilka include. W celu zrobienia miarodajnych testów
powinno się robić takie testy jak przy benchmarkach dla pecetów czyli - operacje stałoprzecinkowe, zmiennoprzecinkowe, alokacja pamięci, czytanie z dysku małych plików, czytanie z dysku dużego pliku etc. I wynik testu powinien być średnią tych składowych. Niby tak, ale mi chodzi, że strony ładnie chodziły i dlatego testuje na prawdziwej stronie, która wisi w sieci już parę lat. Odpaliłem też na localhoście, Windows XP, procesor 2-rdzeniowy i wynik mam: 2 req/s. Zainstalowałem FastCGI i nadal 2 req/s. lamer |
| lamer
|
Posted: 19 Lut 2010 18:48:02 też na localhoście, Windows XP, procesor 2-rdzeniowy i wynik mam: 2 req/s.
Zainstalowałem FastCGI i nadal 2 req/s. Postawiłem bazę i mam 140 req/s. Chyba timeouty są za długie. lamer |
| lamer
|
Posted: 19 Lut 2010 19:32:37 Postawiłem bazy też na serwerach 1-3. Wyniki w ich przypadku bez zmian, może szybciej o 5%. lamer |
| Lemat
|
Posted: 19 Lut 2010 19:54:35 Postawiłem bazy też na serwerach 1-3. Wyniki w ich przypadku bez zmian,
może szybciej o 5%. no dobra, to daj -n 1000 i pokaż wyniki |
| lamer
|
Posted: 20 Lut 2010 10:34:36 Postawiłem bazy też na serwerach 1-3. Wyniki w ich przypadku bez zmian,
może szybciej o 5%. no dobra, to daj -n 1000 i pokaż wyniki -n1000 -c6 1) Shared hosting: Requests per second: 187.93 [#/sec] (mean) 2) RPS 1,2 GHz: Requests per second: 8.38 [#/sec] (mean) 3) RPS 1,6 GHz: Requests per second: 16.21 [#/sec] (mean) Uzycie procka (top) po wykonaniu testow: 1) Cpu(s): 39.1%us, 5.6%sy, 1.3%ni, 50.2%id, 2.0%wa, 0.5%hi, 1.3%si, 0.0%st Widac jacys inni uzytkownicy korzystaja z komputera teraz, a mimo to serwer ladnie wyrabial w tescie. 2) Cpu(s): 0.7% us, 0.7% sy, 0.0% ni, 98.0% id, 0.7% wa, 0.0% hi, 0.0% si 3) Cpu(s): 0.2% us, 0.3% sy, 0.0% ni, 99.5% id, 0.0% wa, 0.0% hi, 0.0% si lamer |
| max
|
Posted: 24 Lut 2010 10:03:37 Czyli jednak dysk nie jest problemem. Procesor w tym RPSie przeciez nie taki zly, wiec dlaczego wyniki dla PHP sa tak beznadziejne? lamer Są atomy dwu rdzeniowe wiec pewnie taki masz. To php to jest jak uruchamiane ? moduł apache czy CGI fastCGI ? Sprawdził bym czy rzeczywiście apache nic nie zapisuje, na pewno logi. Może sa jakos inaczej skompilowane PHP i apache ? |
| max
|
Posted: 24 Lut 2010 10:06:02 Sprawdził bym czy rzeczywiście apache nic nie zapisuje, na pewno logi.
Może sa jakos inaczej skompilowane PHP i apache ? Przy okazji mozesz opublikować kompletny kod to zrobie testy na moim RPS w ovh i na dedyku w ovh i na jeszcze innych serwerach. I je Ci tu podam |
| lamer
|
Posted: 24 Lut 2010 15:35:14 SÄ… atomy dwu rdzeniowe wiec pewnie taki masz.
To php to jest jak uruchamiane ? moduł apache czy CGI fastCGI ? Nie wiem jak to sprawidzić. Gdzieś w httpd.conf będzie taka informacja? lamer |
| lamer
|
Posted: 24 Lut 2010 16:11:24 Requests per second: 19.70 [#/sec] (mean) Wedlug: grep cores /proc/cpuinfo toto ma tylko 1 rdzen. lamer |
| max
|
Posted: 24 Lut 2010 18:12:27 SÄ… atomy dwu rdzeniowe wiec pewnie taki masz.
To php to jest jak uruchamiane ? moduł apache czy CGI fastCGI ? Nie wiem jak to sprawidzić. Gdzieś w httpd.conf będzie taka informacja? lamer funkcja phpinfo() Ci to powie |
| max
|
Posted: 24 Lut 2010 18:59:35 Requests per second: 19.70 [#/sec] (mean) Wedlug: grep cores /proc/cpuinfo toto ma tylko 1 rdzen. lamer [I] najtanszy dedyk z OVH bogomips : 2400.46 ---- ab -n1000 -c6 Requests per second: 332.62 [#/sec] (mean) Time per request: 18.039 [ms] (mean) Time per request: 3.006 [ms] (mean, across all concurrent requests) Transfer rate: 2983.19 [Kbytes/sec] received ---- [II] inny serwer model name : Intel(R) Xeon(TM) CPU 3.06GHz bogomips : 6094.84 ---- ab -n1000 -c6 Requests per second: 427.53 [#/sec] (mean) Time per request: 14.03 [ms] (mean) Time per request: 2.34 [ms] (mean, across all concurrent requests) Transfer rate: 3944.60 [Kbytes/sec] received [III] RPS w ovh (lokalnie) bogomips : 3511.38 ---- ab -n1000 -c6 Requests per second: 35.89 [#/sec] (mean) Time per request: 167.193 [ms] (mean) Time per request: 27.865 [ms] (mean, across all concurrent requests) Transfer rate: 333.96 [Kbytes/sec] received [IV] to samo co III ale z dedyka w OVH bogomips : 3511.38 ---- ab -n1000 -c6 Requests per second: 36.52 [#/sec] (mean) Time per request: 164.277 [ms] (mean) Time per request: 27.380 [ms] (mean, across all concurrent requests) Transfer rate: 339.88 [Kbytes/sec] received [V] wygenerowałem HTML i bez udziału PHP lokalnie (tylko sam kod HTML) Requests per second: 1675.97 [#/sec] (mean) Time per request: 3.580 [ms] (mean) Time per request: 0.597 [ms] (mean, across all concurrent requests) Transfer rate: 15854.66 [Kbytes/sec] received |
| lamer
|
Posted: 24 Lut 2010 22:17:40 funkcja phpinfo() Ci to powie
CGI 1.1 Duzo zyskam przechodzac na FastCGI? lamer |
| max
|
Posted: 25 Lut 2010 08:35:43 funkcja phpinfo() Ci to powie
CGI 1.1 Duzo zyskam przechodzac na FastCGI? lamer Przy każdym zadaniu plików PHP uruchamia się program php który raczej jest dość dużym plikiem w FastCGI masz uruchomione już procesy które obsługuje kod PHP wiec nie ma konieczności ciagłego uruchamiania programu php FastCGI bedzie szybsze a najszybsze bedzie php jako moduł apache |
| Artur Muszyński
|
Posted: 25 Lut 2010 19:55:23 FastCGI bedzie szybsze
a najszybsze bedzie php jako moduł apache Ej, takie proste to stopniowanie chyba nie jest. FastCGI wydajnością jest porównywalne z mod_php, tak samo pod Windowsem przy porównaniu z ISAPI. artur |
| lamer
|
Posted: 3 Mar 2010 18:50:15 A jednak nie wiem co tam mam. Funkcja phpinof() zawsze zwraca CGI/1.1. lamer |
|
Czas ³adowania strony (sek.): 0.541 users miniBB.net © 2001-2010 | Polityka Prywatno¶ci e-gie³dy + opisy gg + kumy fubi ° oko na maroko ° nimda °
|