Prosty benchmark hostingów

[alien 345]

No tak, ale ja zalozylem, ze porownujemy zdecydowanie te sama ilosc obrotow, podobnej klasy sprzet.

[patryk 451]

Alien: tak, właśnie o tym piszę. SATA2 = 300 MB/s, SCSI U320 = 320 MB/s. Teraz porównując ceny dysku Seagate Cheetah 73GB 10K.7 z WD RAPTOR X może się okazać, że pojemniejszą i barzdziej niezawodną macierz o nieznacznie mniejszej wydajności stworzymy używając dysków SATA a nie SCSI. I nie mówię, że to będzie dobre we wszystkich rodzajach zastosowań, ale jeśli jest potrzebny kompromis między wydajnością a ceną to rozwiązania oparte o dobre dyski SATA2 i dobry kontroler są bardzo sensownym rozwiązaniem w porównaniu do SCSI U320. Teoretyczna niezawodność (MTBF) też jest praktycznie taka sama (desktopowe dyski SATA mają po 600,000h, te troszkę lepsze mają wartości takie jak dyski SCSI czyli powyżej 1 miliona godzin).

[T 6]

moze przyklad do ciebie dotrze:(...)

Nie pij tyle. Stwierdziłem, że na podstawie fałszywych danych nie da się wyciągnać poprawnych wniosków co jest wręcz truizmem, a Ty mi wyjeżdżasz z sumami kontrolnymi. Litości.

 

podparles tym stwierdzeniem swoja wypowiedz, wypowiedz miala byc bezstronna lecz nie byla w zwiazku z tym mozna przyjac ze bylo to "chwalenie sie" - skad taki wniosek?dla wielu osob omawiany tutaj test wydaje sie byc poprawny wiec wypadajacy w tym tescie _dobrze_ hosting moze byc traktowany jako dobry - co oczywiscie jest zalozeniem blednym jesli nie zna sie warunkow pracy "testera"

Jak wyżej -- nie pij tyle. Napisałem, że moje serwery wypadły dobrze, żeby nikt nie pomyślał, że krytykuje test tylko dlatego, że wypadły źle. Wydawało mi się to oczywiste.

 

Alien: tak, właśnie o tym piszę. SATA2 = 300 MB/s, SCSI U320 = 320 MB/s. Teraz porównując ceny dysku Seagate Cheetah 73GB 10K.7 z WD RAPTOR X może się okazać, że pojemniejszą i barzdziej niezawodną macierz o nieznacznie mniejszej wydajności stworzymy używając dysków SATA a nie SCSI. I nie mówię, że to będzie dobre we wszystkich rodzajach zastosowań, ale jeśli jest potrzebny kompromis między wydajnością a ceną to rozwiązania oparte o dobre dyski SATA2 i dobry kontroler są bardzo sensownym rozwiązaniem w porównaniu do SCSI U320. Teoretyczna niezawodność (MTBF) też jest praktycznie taka sama (desktopowe dyski SATA mają po 600,000h, te troszkę lepsze mają wartości takie jak dyski SCSI czyli powyżej 1 miliona godzin).

Powyższe testy nie mówią niestety wiele o rzeczywistej wydajności. A co do Raptorów to maja one zbliżoną cenę do dysków SCSI.

[alien 345]

Alien: tak, właśnie o tym piszę. SATA2 = 300 MB/s, SCSI U320 = 320 MB/s. Teraz porównując ceny dysku Seagate Cheetah 73GB 10K.7 z WD RAPTOR X może się okazać, że pojemniejszą i barzdziej niezawodną macierz o nieznacznie mniejszej wydajności stworzymy używając dysków SATA a nie SCSI. I nie mówię, że to będzie dobre we wszystkich rodzajach zastosowań, ale jeśli jest potrzebny kompromis między wydajnością a ceną to rozwiązania oparte o dobre dyski SATA2 i dobry kontroler są bardzo sensownym rozwiązaniem w porównaniu do SCSI U320. Teoretyczna niezawodność (MTBF) też jest praktycznie taka sama (desktopowe dyski SATA mają po 600,000h, te troszkę lepsze mają wartości takie jak dyski SCSI czyli powyżej 1 miliona godzin).

 

Ciekawy argument. Na pewno to przeanalizuje szerzej. Generalnie juz jakis czas temu sklonilem sie do uzywania SATA przy duzych macierzach dyskowych. Ale w typowych serwerach jednak wciaz ufam SCSI.

[patryk 451]

T: to w takim razie co rozumiesz przez rzeczywistą wydajność jeśli nie prędkość kopiowania plików na dysku czy prędkość odczytów/zapisów?

 

Co do cen - owszem, jeśli porównujemy stockowe ceny Raptora X 150 GB (180-200$) z cenami Seagate Cheetah 10K.7 146GB (250-280$, 73GB można kupić trochę taniej niż Raptory) to różnica cenowa nie jest tak widoczna (choć i przy zakupie dużej ilości dysków uwidacznia się bardziej), co innego gdy pod lupę weźmiemy Hitachi 7K1000 czy inne Baraccudy na SATA-II gdzie w cenie 146 GB na SCSi dostajesz 750 GB.

[T 6]

T: to w takim razie co rozumiesz przez rzeczywistą wydajność jeśli nie prędkość kopiowania plików na dysku czy prędkość odczytów/zapisów?

Jakieś bardziej realne testy, a nie tylko proste zmierzenie transferu. Powinny brać pod uwagę rzeczywistą wydajność dysków przy odczycie (wyszukiwaniu) i zapisie małych porcji danych, tak jak to się dzieje w hostingu.

 

Mam np. dyski ATA 7,2K (PATA, nawet nie SATA) które w `hdparm -t` osiągają 64 MB/s, ale to wcale nie oznacza, ze są porównywalne z SCSI 10K w zastosowaniu hostingowym.

Dodam, że ten podsystem dyskowy wypada mi lepiej w testach niż SATA na serwerach dedykowanych.

 

Co do cen - owszem, jeśli porównujemy stockowe ceny Raptora X 150 GB z Seagate Cheetah 10K.7 73 GB to Raptor jest tańszy raptem kilkadziesiąt złotych (choć i tak masz dwa razy wyższą pojemność), co innego gdy pod lupę weźmiemy Hitachi 7K1000 czy inne Baraccudy na SATA-II gdzie w cenie 146 GB na SCSi dostajesz 750 GB.

Z tym się zgadzam, dlatego używam dysków SATA. Nie sądze, żeby system zlokalizowany na jednym dysku SCSI był bardziej wydajny niż rozrzucony po kilku dyskach SATA.

 

Lub inaczej -- jeśli w cenie jednego dedykowanego Dual Xeona/2xSCSI mogę mieć cztery Dual Core/2xSATA to wybór też jest raczej oczywisty.

[beliq 442]

Jakieś bardziej realne testy, a nie tylko proste zmierzenie transferu. Powinny brać pod uwagę rzeczywistą wydajność dysków przy odczycie (wyszukiwaniu) i zapisie małych porcji danych, tak jak to się dzieje w hostingu.

bonnie++

[bald 0]

Nie pij tyle.

 

nie pije

 

co do przykladu, jesli go nie zrozumiales to juz wylacznie twoj problem

[T 6]

co do przykladu, jesli go nie zrozumiales to juz wylacznie twoj problem

Zrozumiałem, tyle że nie ma związku z tematem. Dla mnie EOT.

[Prohost 345]

sata w raidzie z dobrym kontrolerem jest lepsze przy kopiowaniu plików itp. sas/scsi jest dużo lepsze przy bazach danych i typowych zastosowaniach hostingowych. Dlatego ten test nie jest miarodajny jeśli się stawia sata naprzeciwko sas/scsi bo przy identycznym sprzęcie sata wygra punktami.

 

Ale dla porównywania sata/sata , sas/sas sie nadaje. Problemem tu też jest obciążenie maszyny bo może zmienić wynik nawet o kilkadziesiąt procent w porównaniu do czystej maszyny. Także os jest ważny - lepsze wyniki da 64bitowy.

[cyberluk 0]

to powyzsze "cos" jest kompletnie bez sensu gdyz:

1 - brak "pomiaru" czasu

2 - zakres zmiennych jest bledny i program nie wyjdzie z petli

kolejna bzdura,

testy tego typu nie badaja wylacznie wydajnosci procesora ani wydajnosci jezyka, maja zbadac jak szybko jest generowana strona ato zalezy od bardzo wielu czynnikow

 

No i właśnie o to mi chodziło Dokładnie na takiej pętli opiera się ten benchmark PHPowy. Czyli sam sobie odpowiedziałeś, że ten test jest bzdurą. Różnica jest taka, że tutaj miał być odpalany w postaci time ./benchmark - pomiar czasu przez gotowe narzędzie, a w benchmarku PHP ten pomiar był dodany - przed "funkcją do sprawdzenia wydajności" pobierany był timestamp pierwszy raz, po wykonaniu tej funkcji drugi raz i różnica, to była czas zwracany dla użytkownika.

 

A teraz najciekawsze:

cyberluk@cyberluk-desktop:~$ cat benchamrk.c

int main() {

int i,j;

 

for (i=0; i<10000000; i++)

j++;

 

return 0;

}

cyberluk@cyberluk-desktop:~$ gcc -o benchamrk benchamrk.c

cyberluk@cyberluk-desktop:~$ time ./benchamrk

 

real 0m0.022s

user 0m0.024s

sys 0m0.000s

cyberluk@cyberluk-desktop:~$

 

A jednak działa

[bald 0]

No i właśnie o to mi chodziło

pisalem o twoim tescie a nie o tym omawianym

 

Dokładnie na takiej pętli opiera się ten benchmark PHPowy.

 

 

z ta "drobna " roznica, ze kod twojego testu miesci sie w pamieci cache

a ten wokol ktorego toczy sie dyskusja nie

 

 

A jednak działa

 

tu moja pomylka, zle policzylem ilosc zer

[irvinek 4]

Wy znowu to samo ile można "ciągnąć" w kółko ten sam temat?Nie znam źródła tego skryptu ale wydaje mi się ,że jest to mnożenie ew dodawanie lub dzielenie + pętla?Jeśli tak to taki benchmark to można sobie między bajki wsadzić.

[cyberluk 0]

pisalem o twoim tescie a nie o tym omawianym

 

z ta "drobna " roznica, ze kod twojego testu miesci sie w pamieci cache

 

a ten wokol ktorego toczy sie dyskusja nie

 

tu moja pomylka, zle policzylem ilosc zer

 

Tylko, że mój test robi prawie (podkreślam prawie, bo nie chciało mi się przepisywać go dokładnie - to ma być tylko przykład - chodzi głownie o pętlę) dokładnie to samo co ten PHPowy. Chodziło mi o pokazanie, ze testujesz tak naprawdę jakość języka-kompilatora/interpretera/vm'a, a nie wydajność platformy hostingowej. To czy jest to napisane w C, czy w PHP, czy w Javie nic nie zmienia... To, że mój kod zmieścił się w cache też o niczym nie świdaczy. Po prostu wynik będzie lepszy. Cały trick polega na tym, że taki test sprawdza tylko malutki kawałek języka-kompilatora/interpretera/vm'a, który ma się nijak do sprawdzenia całej platoformy. Nie będę już wspominał takich o zmianie trybu pracy PHP'a...

Nie wiem jak to prościej wytłumaczyć. To tak jakbyś za pomocą programu w C, które realizuje:

- weź dwie liczby

- pomnóż je przez siebie

- dodaj do trzeciej

- weż literki od a dof

- wpisz pod adres pamięci

- dopisz na końcu te literki poprzedniego ciągu znaków

- powyższe operacje wykonaj 100k razy i zmierz czas

 

Chciał przetestować scheduler w kernelu albo podsystem I/O... Już rozumiesz o co chodzi?

 

Ten PHPowy benchmark możeby być jakimś marnym miernikiem wydajności maszyny, jeżeli:

- odpalisz go na czystej maszynie - zapiszesz wynik

- odpalisz na obiciążonej maszynie - zapiszezs wynik

- porównasz te wyniki

Wtedy wyjdzie Ci mniej więcej ile procentowo masz dostępnego czasu procesora. Nadal nie jest to testowanie platformy, tylko konkretnej, okrojonej funkcjonalności w samym PHP i konkretnego składnika systemu jakim jest procesor.

 

A co do zer

Dopisałem jeszcze jedno:

cyberluk@cyberluk-desktop:~$ time ./benchamrk

 

real 0m0.199s

user 0m0.192s

sys 0m0.004s

i jeszcze:

cyberluk@cyberluk-desktop:~$ time ./benchamrk

 

real 0m2.030s

user 0m2.000s

sys 0m0.028s

I tak mogę dopisywać Fakt, że po którymś razie pętla będzie wykonywała się 10 lat, ale w końcu się wykona

 

Z ciekawostek - wiesz, że powyższy kod, jeżeli wpisze mu tam 64 zer skompilowany za pomocą C będzie pewnie się kręcił kilka lat. W javie ten sam kod wykona się w kilka ms? To tak żeby dodać pikanterii i pokazać, że takie pętle testują nie to co trzeba...

 

EDIT: Eh mała pomyłka Ten ostatni przykład to pętla bez tego j++... Sorki

[bald 0]

i o to chodzi,

wiekszosc rzeczy ktore maja istotny wplyw na czas generowania strony (czyli "szybkosc" dzialania hostingu) nie jest mierzalna, to co mozemy zmierzyc daje jakis mniej lub bardziej PRZYBLIZONY obraz rzeczywistosci

 

co do dopisywania zer to oczywistym jest ze nie mozna tego robic bez konca

 

co do kodu w c i javie roznica w czasie wykonania nie wynika w doskonalosci jezyka (srodowiska) a raczej z jego niedoskonalosci - jesli wprowadzisz liczbe (w kodzie) wieksza niz 32 bitowa (zakladam prace w srodowisku 32 bitowym) to zostanie ona "przycieta" (dobry kompilator powinien wywalic blad) do wartosci ktora mozna upchnac na 32 bitach moze to byc proste obciecie / zaokraglenie, w efekcie wcale licznik petli nie bedzie zawieral liczby ktora oczekujemy lecz jakas "przyblizona" - na pewno mniejsza od oczekiwanej

[cyberluk 0]

i o to chodzi,

wiekszosc rzeczy ktore maja istotny wplyw na czas generowania strony (czyli "szybkosc" dzialania hostingu) nie jest mierzalna, to co mozemy zmierzyc daje jakis mniej lub bardziej PRZYBLIZONY obraz rzeczywistosci

Ależ oczywiście, że prędkość hostingu jest mierzalna. Ba, nawet lepiej pokaże wydajność całej platformy, niż składanie takiego wyniku z kawałeczków. Co z tego, że w dodawaniu PHP wypadnie Ci mega-super-hiper ekstra, jeżeli okaże się, że np karta sieciowa jest z tyłka i totalnie zamuli Ci środowisko, albo dyski nie wydolą i skrypty będą wisiały w oczekiwaniu na I/O? Prosty przykład. Odpalałem ten skrypt (chodzi mi o tego PHP'a) na wypasionej maszynie - 2x Quad Core Xeon, 16GB RAMu, podpięty po FC do macierzy 2TB zbudowanej na dyskach 36GB 15k obr/min (policz sobie wydajność I/O tego systemu) z 4GB cache. I wiesz co? Chodził porównywalnie lub gorzej niż na progresso - oboje korzystamy z Debiana i wydaje mi się, że na progreso php był/jest z paczek. Różnica jest taka, że w przypadku hostingu ta maszyna pociągnęłaby klientów z 4 albo 5 maszyn progreso... Gdzie tutaj Twoja logika? Gdzie jakość tego benchmarku?

 

co do dopisywania zer to oczywistym jest ze nie mozna tego robic bez konca

Można, tylko kod nie wykona się w skończonym czasie

 

co do kodu w c i javie roznica w czasie wykonania nie wynika w doskonalosci jezyka (srodowiska) a raczej z jego niedoskonalosci - jesli wprowadzisz liczbe (w kodzie) wieksza niz 32 bitowa (zakladam prace w srodowisku 32 bitowym) to zostanie ona "przycieta" (dobry kompilator powinien wywalic blad) do wartosci ktora mozna upchnac na 32 bitach moze to byc proste obciecie / zaokraglenie, w efekcie wcale licznik petli nie bedzie zawieral liczby ktora oczekujemy lecz jakas "przyblizona" - na pewno mniejsza od oczekiwanej

Różnica wynika w doskonałości kompilatora. Kompilator w Javie wie, że ta pętla jest pusta i nie będzie jej "kręcił"... To jest "ficzer" języka zaimplementowany przez jego twórców. C tak nie potrafi...

Żaden kompilator nie będzie wiedział, czy "pojemność" zmiennej nie skończy się w trakcie działania programu. Jakby tak było - ehh piękne czasy - zero buffer overflow itp...

[bald 0]

Ależ oczywiście, że prędkość hostingu jest mierzalna.

 

hosting to "zywy organizm" nie jestes w stanie go dobrze przetestowac bo albo zrobisz test "rozrywkowy" w warunkach domowych czyli cala maszyna twoja, albo na uzywanej przez kilka (nascie/dziesiat/set) osob maszynie

 

zadna z powyzszych sytuacji nie odda prawdziwego obrazu - pokaze tylko _mniej wiecej_ co mozna uzyskac

 

Można, tylko kod nie wykona się w skończonym czasie

 

 

prosze skompiluj w gcc cos takiego:

int a= 100000000000000000000000000000000000000000000;

(oczywiscie bez "ficzerow" w stylu bignum )

 

 

Różnica wynika w doskonałości kompilatora. Kompilator w Javie wie, że ta pętla jest pusta i nie będzie jej "kręcił"... To jest "ficzer" języka zaimplementowany przez jego twórców. C tak nie potrafi...

Żaden kompilator nie będzie wiedział, czy "pojemność" zmiennej nie skończy się w trakcie działania programu. Jakby tak było - ehh piękne czasy - zero buffer overflow itp...

 

 

 

j++ _zawsze_ zajmie cos w pamieci chocby glupi jeden bajcik na INC

 

a jesli rozpatrujesz wersje bez j++ (zauwazylem twoja poprawke: EDIT) to i tak kompilator nie powinien sobie ot tak wywalic kawalka kodu - ktory z pozoru nic istotnego nie robi bo jak by na to nie patrzec taka petla moze miec istotny wplyw na dzialanie calego programu

[cyberluk 0]

hosting to "zywy organizm" nie jestes w stanie go dobrze przetestowac bo albo zrobisz test "rozrywkowy" w warunkach domowych czyli cala maszyna twoja, albo na uzywanej przez kilka (nascie/dziesiat/set) osob maszynie

 

zadna z powyzszych sytuacji nie odda prawdziwego obrazu - pokaze tylko _mniej wiecej_ co mozna uzyskac

 

A kto mówi o warunkach domowych? Ja mówię o laboratorium, gdzie mam 15 serwerów i każdy z nich może generować jakiś rodzaj ruchu. Jak robiliśmy testy Oracla z Novellem i IBMem, to soft do benchmarku udawała setki klientów robiących zakupy w sklepie. I wiesz co? Był na tyle dokładny, że po wdrożeniu systemu wynik różniły się o 5% od rzeczywistego obciążenia systemu... Oczywiście podpieranie się benchmarkiem opartym na ab, czy podobnym narzędziu też nie jest miarodajne. Jest na 100% lepsze niż przedstawiony tutaj benchmark, ale daleko mu do prawdziwego softu do wykonywania testów. Przy odpowiedniej składance narzędzi i przygotowaniu środowiska testowego da się w miarę dokładnie określić wydajność platformy.

 

Dla każdego systemu da się napisać benchmark. Musi on być zrobiony z głową. Im bardziej skomplikowane środowisko, tym więcej pracy trzeba włożyć w przygotowanie testów.

 

prosze skompiluj w gcc cos takiego:

int a= 100000000000000000000000000000000000000000000;

(oczywiscie bez "ficzerow" w stylu bignum )

Ależ proszę bardzo:

 

cyberluk@snoopy:~$ gcc -o test_file test.c

test.c:3:9: warning: integer constant is too large for its type

test.c: In function 'main':

test.c:3: warning: integer constant is too large for 'long' type

test.c:3: warning: overflow in implicit constant conversion

cyberluk@snoopy:~$ ./test_file

 

Co nie zmienia faktu, że jest to tylko warning i dało się przypisać tak dużą liczbę do int'a. Ba program nawet się uruchomił... Tak, wiem - dobry programisty pisze kod na tyle czysto, żeby nie było warningów. Ale dobry programista nie przypisuje tak dużej liczby do int'a świadomie. Natomiast sprawdzenie, czy wynik 2^128 zmieści się w int nie leży już w "kompetencjach" kompilatora i on po prostu coś takiego oleje...

 

j++ _zawsze_ zajmie cos w pamieci chocby glupi jeden bajcik na INC

 

a jesli rozpatrujesz wersje bez j++ (zauwazylem twoja poprawke: EDIT) to i tak kompilator nie powinien sobie ot tak wywalic kawalka kodu - ktory z pozoru nic istotnego nie robi bo jak by na to nie patrzec taka petla moze miec istotny wplyw na dzialanie calego programu

Wiem, że nie powinien - pewnie dlatego większość kodu tworzę w C, a czasami w assemblerze...

[bald 0]

Przy odpowiedniej składance narzędzi i przygotowaniu środowiska testowego da się w miarę dokładnie określić wydajność platformy.

 

kluczowe w tej wypowiedzi jest "w miare" , dziekuje :0

 

Dla każdego systemu da się napisać benchmark. Musi on być zrobiony z głową. Im bardziej skomplikowane środowisko, tym więcej pracy trzeba włożyć w przygotowanie testów.

zgadzam sie z tym - szczegolnie z tym ze test ma byc pisany POD KONKRETNY SYSTEM

 

 

 

 

Ależ proszę bardzo:

Co nie zmienia faktu, że jest to tylko warning i dało się przypisać tak dużą liczbę do int'a. Ba program nawet się uruchomił...

 

to jeszcze tylko dla zaspokojenia wlasnej ciekawosci sprawdz sobie co tak _naprawde- znalazlo sie z omawianej zmiennej

 

Tak, wiem - dobry programisty pisze kod na tyle czysto, żeby nie było warningów.

 

to nie jest prawda, czasem warningi sa i MAJA byc - swiadomie

 

 

 

Natomiast sprawdzenie, czy wynik 2^128 zmieści się w int nie leży już w "kompetencjach" kompilatora i on po prostu coś takiego oleje...

Wiem, że nie powinien - pewnie dlatego większość kodu tworzę w C, a czasami w assemblerze...

 

czyli np zapis:

 

mov eax,1000000000000000000h

 

jest w ogole boski i cacy a kompilatorowi nic do niego - tak ma byc bo jasnie pan programista wie najlepiej?

[Prohost 345]

Test na działającym hostingu sensowny jest tylko jeden. Przetestować czy 5 kont więcej wejdzie na taki serwer. Dlaczego?

Bo poprostu nie ma znaczenia do końca szybkość całej maszyny tylko stosunek obciążenia do jej szybkości.

Dla użytkownika ważne jest:

- czas generacji strony

- zapas mocy serwera

 

Benchmarkując 5x zwykłe konto hostingowe można uzyskać info jak się hosting zachowuje.

Przyjmujemy, że jest sobie skrypt forum np. smf z określoną ilością postów.

Do tego zewnetrzny serwer na którym latałoby oprogramowanie testujące wykonujące 5x może nawet 10x więcej zapytań niż normalnie jeden sajt dostaje.

Czasy generacji stron i czasy odpowiedzi mogłyby być rejestrowane oddzielnie. Ruch należaloby zablokować tylko do tego jednego ip na sajcie.

 

Test pokazałby czas generacji strony i czy serwer ma zapas mocy. Coś co jest wyznacznikiem jakiejś jakości technicznie.

Mówimy tu jednak o samym teście technicznym konta.

 

Inna sprawa to support itp.

 

Taki test nie jest wcale trudny do zrobienia.

[cyberluk 0]

kluczowe w tej wypowiedzi jest "w miare" , dziekuje :0

 

Czekaj, czekaj. Ja cały czas staram Ci się uświadomić, że ten konkretny benchmark, który wszyscy odpalali jest z tyłka. To, że każdy benchmark jest obłożony błędem to chyba logiczne. Kwestia jest taka, że może to być benchmark całkiem z tyłka (taki jak ten PHPowy), albo specjalnie napisany pod testy danego systemu - wtedy taki benchmark będzie całkiem dokładny. Przestrzelenie wydajności systemu o 5% w porównaniu do 200% czy 300% jest chyba sporą rozbieżnością. Ba, nie wspomnę już o zignorowaniu sporej części elementów systemowych i programowych, które mogą mieć wpływ na wydajność hostingu, a w tym konkretnym benchmarku zostały pominięte. To tak jakbyś w czasie prowadzenia projektu miał kupić serwery za 1 mln zł. Albo się pomylisz o 10% i będzie +/- 100k zł, albo się pomylisz o 200% i wyjdzie, że albo serwery wcale nie są potrzebne, albo będą kosztowały 3mln zł

 

zgadzam sie z tym - szczegolnie z tym ze test ma byc pisany POD KONKRETNY SYSTEM

Np. system hostingowy

 

to jeszcze tylko dla zaspokojenia wlasnej ciekawosci sprawdz sobie co tak _naprawde- znalazlo sie z omawianej zmiennej

Ja wiem co tam się znalazło. Nie zmienia to faktu, że program dał się skompilować i nawet się uruchomił.

 

Dobra, bo pewnie żaden z nas nie ustąpi Ten konkretny benchmark PHP jest z tyłka - z tym się chyba zgodzisz. Każdy benchmark jest opatrzony błędem - z tym też się chyba zgodzisz. Benchmarki są potrzebne - muszą być napisane w odpowiedni sposób i musimy wiedzieć, czego oczekujemy od systemu i co chcemy zmierzyć - musimy stworzyć metodologię benchmarka. To chyba też jest jasne. Peace

[Prohost 345]

Napisałem prosty benchmark dla hostingów.

 

Tu jest paczka:

http://www.prohost.pl/hostingbenchmark.tar.gz

 

Do odpalenia potrzebuje mysqla - rezultaty w bazie się zapisują.

 

Zasada jest prosta - test tworzy 200 wirtualnych przeglądarek (nie requestuje obrazków i css przynajmniej w tej wersji).

Co 5-15 sekund przeglądarki ściągają strony z listy - stron do testowania jest 10 (można zmienic modyfikując skrypt).

Strony trzeba dodać w tabeli @url.

 

Po skończonej pracy podane są max/min/average czasy.

Nie wiem czy 200 to nie jest zamało ale powinno starczyć chyba.

 

Więc jesli ktoś zrobi paczkę forum które można będzie wrzucić na serwery to mozna coś potestować.

Testy muszą być robione przez jednego hosta bo liczony jest czas ściągnięcia.

Można dodać odczytywanie czasu generacji strony później jak będzie wiadomo gdzie na stronie się by to wyświetlało.

 

A i obsługi błędów nie robiłem. Bardziej oszczędny skrypt można by napisać ale mi się nie chciało bawić.

[alien 345]

No tak, tylko ze ten test z kolei ma inna wade - silnie uzaleznia wyniki od polaczenia internetowego komputera, na ktorym test jest uruchamiany (dostawca, punkty styku, odleglosc, technologia). Test Warszawa-Warszawa na dobrych laczach sila rzeczy bedzie miec lepszy wynik od np. Warszawa-Krakow. Tak samo np. technologia ADSL generalnie zwiekszy czasy, zatracajac tym samym subtelne roznice w szybkosci serwowania - zbyt duzy udzial w wyniku ma sama transmisja po szkieletach roznych sieci i uzywanych technologiach. Zbyt wiele zalezy od sieci zewnetrznych, zbyt malo od operatora.

 

Zastanawialem sie juz dawno nad testami tego typu na potrzeby rankingow w Magazynie Internet. Nawet byly przeze mnie przeprowadzane, ale nie powstaly z tego zadne wiarygodne wyniki, ktore nadawalyby sie do publikacji.

[Prohost 345]

No tak, tylko ze ten test z kolei ma inna wade - silnie uzaleznia wyniki od polaczenia internetowego komputera, na ktorym test jest uruchamiany (dostawca, punkty styku, odleglosc, technologia). Test Warszawa-Warszawa na dobrych laczach sila rzeczy bedzie miec lepszy wynik od np. Warszawa-Krakow. Tak samo np. technologia ADSL generalnie zwiekszy czasy, zatracajac tym samym subtelne roznice w szybkosci serwowania - zbyt duzy udzial w wyniku ma sama transmisja po szkieletach roznych sieci i uzywanych technologiach. Zbyt wiele zalezy od sieci zewnetrznych, zbyt malo od operatora.

 

Zastanawialem sie juz dawno nad testami tego typu na potrzeby rankingow w Magazynie Internet. Nawet byly przeze mnie przeprowadzane, ale nie powstaly z tego zadne wiarygodne wyniki, ktore nadawalyby sie do publikacji.

 

Masz racje ale jak napisałem można spokojnie dodać zczytywanie czasu generacji ze strony i liczyć oddzielnie.

Wystarczy wiedzieć jak testowany skrypt wyświetla to. Czy "czas generacji strony" czy "generated in" itp.