Srovnání hostingů

honzik
http://www.hostingy.cz/

Použíj google

Asi mas na mysli mereni.kyblsoft.cz

nicmene hodnota dat neni kvalitni a neda se rovnat s daty z nejakeho oficialniho audotu.

Tonda

Nobelicek
Jak to myslíte, že hodnota dat není kvalitní? Na té stránce je přesně popsána technologie měření včetně zdrojového kódu a popisem toho, co které číslo vlastně udává.

Co by podle vás měl dělat "oficiální audit"? Ptát se přímo hosterů? :-) Nebo vycházet z logů jednotlivých strojů? (Tam by zas nebyly vidět výpadky internetu a zátěž.)
Prosím o zdůvodnění.

Aleš Janda
Mám konkrétní příklad, ze kterého se nedá vycházet: http://mereni.kyblsoft.cz/hosting/Hy.cz

„Nedostupnost za rok 7 dní, 5 hod 31 min 18 s“ — i přesto, že se měří od srpna, se ten roční průměr počítá o rok zpátky. Když sečtu všechny výpadky, vyjde mi to na 54 hodin, což není 7 dní :). Ale jinak to neberte jako stěžování, ale jen jako příklad. Podobných malých „nesrovnalostí“ by se tam dalo najít více.

djlj

„Nedostupnost za rok 7 dní, 5 hod 31 min 18 s“ — i přesto, že se měří od srpna, se ten roční průměr počítá o rok zpátky.

To je matematická úvaha, kolik by to za rok bylo a je to dopočítáno z té části od srpna. Je to jako když kupuješ 20 deka salámu - také je cenovka pouze za kilogram, ale jde to z toho dopočítat.

Když sečtu všechny výpadky, vyjde mi to na 54 hodin, což není 7 dní :)

Právě :-) Pokud je za 5 měsíců 54 hodin výpadků, kolik těch výpadků bude za 12 měsíců? :-P

Ale jinak to neberte jako stěžování, ale jen jako příklad. Podobných malých „nesrovnalostí“ by se tam dalo najít více.

Budu rád, když mě zase na nějaký upozorníš :-)
U tohohle jsem myslel, že je to jasné, ale nějak to tam lépe popíšu.

ak to myslíte, že hodnota dat není kvalitní? Na té stránce je přesně popsána technologie měření včetně zdrojového kódu a popisem toho, co které číslo vlastně udává.

Co by podle vás měl dělat "oficiální audit"? Ptát se přímo hosterů? :-) Nebo vycházet z logů jednotlivých strojů? (Tam by zas nebyly vidět výpadky internetu a zátěž.)
Prosím o zdůvodnění.

Ja Vam povim proc nejsou namerene hodnoty kvalitni. Udam priklad :

1) Linka mezi poskytovatelem kyblsoft a poskytovatelem webhostingu bude poskozena -> kyblsoft hlasi vypadek i kdyz ostatnim lidem server jede.

2) Vypadek trva 2 vteriny -> Kyblsoft ho hlasi jako 5 minut (ve vysledne statistice je 5 minut z mesice uz orpavdu hodne)

3) Vypadek na strane kyblsoft -> hlasi vypadek hostingoveho serveru

Tri priklady kdy tyto data jsou zkreslovana.

Jak zjistit pravou dostupnost? Existuje nekolik auditoru dostupnosti. Jeden z nejlepsich je siux.cz. Ukazuje casove odezvy serveru. Conection time, rea time, prenosove rychosti pri spojeni. Ma vice mericich bodu (pokud je vypadek zpusoben vypadkem konektivity treba mezi bodem A a B ale z bodu C do bodu A spojeni fungue) umi to rozpoznat. Atd atd. Meri i ve vterinovem intervalu, takze dostupnost je velmi realna.

Antonin Capousek
Netzona.cz

Aleš Janda
Dobře.

ypadek trva 2 vteriny -> Kyblsoft ho hlasi jako 5 minut (ve vysledne statistice je 5 minut z mesice uz orpavdu hodne)
Jojo, obyčejnej pár sekundovej restart apache bývá započítán jako několika minutová nedostupnost.

Nobelicek
Málo čtete, to vše jsou jen Vaše domněnky, a bohužel špatné.

Linka mezi poskytovatelem kyblsoft a poskytovatelem webhostingu bude poskozena -> kyblsoft hlasi vypadek i kdyz ostatnim lidem server jede.

Nemáte pravdu, v případě výpadku měříme z dvou dalších hostingů. Čili kvůli chybě po cestě se výpadek nenaměří.

Vypadek na strane kyblsoft -> hlasi vypadek hostingoveho serveru

Také nemáte pravdu, při každém výpadku je testována dostupnost na několika českých portálech. Čili kvůli našemu výpadku připojení se také nenaměří výpadek testované stránky.

Vypadek trva 2 vteriny -> Kyblsoft ho hlasi jako 5 minut (ve vysledne statistice je 5 minut z mesice uz orpavdu hodne)
(djlj) Jojo, obyčejnej pár sekundovej restart apache bývá započítán jako několika minutová nedostupnost.

K tomuhle se vyjádřím trochu blíže. To se totiž nejedná o neznalost našeho systému, ale neznalost matematiky. Dlužno dodat, že nejste zdaleka sami, na tohle se ptá docela dost lidí, i těch, o kterých jsem si myslel, že studovali technickou školu. Takže minimálně jednou měsíčně někomu po mailu vysvětluju středoškolskou matematiku. Lidi, to jste vážně nebrali ve škole statistiku?

Takže: pokud by bylo měření s intervalem 5 minut a testovaného serveru výpadek by byl 2 vteřiny, jaká je pravděpodobnost tohoto jevu?
2 / (5 x 60) = 1 / 150, tj. asi 0,6%. To znamená, že 1 ze 150 dvouvteřinových výpadků bude odchycen.
A teď: kolik dvouvteřinových výpadků za těch 5 minut zůstane neodhaleno?
1 - (2 / (5 x 60)) = 1 - (1 / 150) = 149 / 150. Tzn. na 149 ze 150 2vteřinových výpadků se nepřijde (pro hnidopichy: platí pro diskrétní intervaly, v tomto případě však zanedbatelné).

Pokud bude hosting měřen 150 x 5 minut a za tuto dobu bude mít 150 2vteřinových výpadků, jaké je nejpravděpodobnější počet odchycených výpadků?
Naměřená_pravděpodobnost = pravděpodobnost_odchycení x počet měření = (1/150) x 150 = 1
Čili za těch 150 měření se odchytne 1 výpadek (pokud by byl zájem, můžu sem dát i výpočet s jakou pravděpodobností právě 1, ale je vysoká :-)).
Jaká tedy byla naměřená dostupnost?
1 - (počet_výpadků / počet_měření) = 1 - (1 / 150) = 0,99333, tj 99,333 %
A jaká byla skutečná dostupnost?
1 - (doba_výpadků / doba_měření) = 1 - ((150 x 2) / (150 x 5 x 60)) = 0,99333 (99,333 %), tedy měření bylo správné.

Pravděpodobnost správného naměření se zvyšuje s počtem měření. Logicky ;-) Nezávisle ne délce intervalu, nezávisle na délce výpadku. Přesnost se zvyšuje jen s počtem měření jdoucím k nekonečnu :-)

Ono i tohle je v té nápovědě, ale je fakt, že ne tak rozepsané. No, možná to tam radši také dám.. ;-)

Mimochodem, je zvláštní, že každého zajímá odchycení 2vteřinového výpadku, ale nikoho nezajímá případ, kdy se nezachytí výpadek dlouhý třeba 9 minut 58 vteřin.. Přitom je to úplně to samé. Ve výsledku se to jenom vykrátí.

Mimochodem jsem autorem podobné měřící služby Monitoring-serverů.cz, která je drtivě největší u nás a na Slovensku. Proto si myslím, že tyhle věci myslím znám poměrně dobře. Kdyby tomu tak nebylo, zákazníci by nás zřejmě rychle sežrali :-)
Siux je jeden z našich konkurentů. Jestli jeden z nejlepších bych se neodvážil říci, jejich služeb nevyužívám. Znám je hlavně proto, že svou službu propagují zejména pod spojením "Monitoring serverů", tedy stejným jménem jako máme my (náhoda?) - stačí se podívat na jejich stránky, kde je toho plno, nebo si je hodit do Googlu, jaké uvádějí odkazy. Vzhledem k tomu, že existují mnohem lepší spojení pro SEO, např. "měření dostupnosti", o serióznosti jejich jednání bych radši pomlčel :-)

Mimochodem jednovteřinový interval je v podstatě nevyužitelný, běžná reakční doba od začátku měření (popř. čekání na vypršení timeoutu) až po uvědomění konkrétního člověka je mnohonásobně vyšší. Ale samozřejmě někdy se to hodit prostě může.

Ještě nějaké dotazy ohledně mereni.kyblsoft.cz? ;-)

Lidi, to jste vážně nebrali ve škole statistiku?
Ne, a pokud jo, tak jsem z toho měl za 5, matika mě nezajímá.

Takže: pokud by bylo měření s intervalem 5 minut a testovaného serveru výpadek by byl 2 vteřiny, jaká je pravděpodobnost tohoto jevu?
Já sice nemám padesát vysokých škol, ale při pohledu na tebou odkazovanou stránku čtu: „V praxi to znamená, že server musí něco odpovědět, a to v rozumném čase (zde do 30 vteřin).“ Z toho se dá lehce odvodit, že když je dvousekundový výpadek, měření ho nezaznamená, protože čeká na odpověď 30 sekund, není-liž pravda?

o serióznosti jejich jednání bych radši pomlčel
Je zakázané používat slovní spojení „monitoring serverů“? Co to má vypovídat o serióznosti? To byl předpokládám jen pokus o pozdní novoroční vtípek.

Já sice nemám padesát vysokých škol

Já také ne. Pokud jsi to bral tak, že se nad někým vyvyšuju, tak se omlouvám. Prostě mě to překvapovalo.

při pohledu na tebou odkazovanou stránku čtu: „V praxi to znamená, že server musí něco odpovědět, a to v rozumném čase (zde do 30 vteřin).“ Z toho se dá lehce odvodit, že když je dvousekundový výpadek, měření ho nezaznamená, protože čeká na odpověď 30 sekund, není-liž pravda?

Ano. A pak se zkouší z dalšího serveru. Takže hosting už by normálně jel. To měření krátké výpadky nezaznamená, těm hostingům tedy spíše nadržuje než škodí.

Je zakázané používat slovní spojení „monitoring serverů“? Co to má vypovídat o serióznosti? To byl předpokládám jen pokus o pozdní novoroční vtípek.

Když jsem na začátku roku 2006 (před rozjetím naší služby) dal do vyhledávače "monitoring serverů", našlo mi to jen několik málo stránek - všude se běžně psalo spíše o měření dostupnosti. Monitoring serverů neznělo zas tak dobře. Zřejmě se jazyk rychle vyvíjí a dnes se jako hlavní používají jiné termíny..
Ale to bylo jen takové malé rýpnutí. Stejně to já vidím ze svého pohledu trochu zkresleně. Nevím ale jak moc zkresleně.
Klidně to ber jen jako náhodu a můj pozdní novoroční vtípek ;-)

To měření krátké výpadky nezaznamená, těm hostingům tedy spíše nadržuje než škodí.
Nejsem si jistý, zda to z předchozí konversace vyplynulo, ale já i Nobelicek jsme o tom psali právě proto, že to ten výpadek (dejme tomu ty dvě sekundy) zaznamená.

djlj
To měření dvousekundový výpadek nezaznamená, právě kvůli jeho ověřování.

Nicméně i kdyby zaznamenalo, tak je to jedno, protože tento výpadek vykompenzuje nezaznamenání výpadku dlouhého 7 minut 58 vteřin (při 4minutovém intervalu), což je stejně (ne)pravděpodobný jev jako by bylo zaznamenání toho dvouvteřinového.

To měření dvousekundový výpadek nezaznamená, právě kvůli jeho ověřování.
Zaznamená. Na té stránce je psáno, že se po třiceti vteřinách zkouší spojení z dalších dvou míst, to tedy máme minutu a půl. Pak nechápu, jak můžu (a že se mi to stává častěji než uvádí nějaká výše uvedená statistika; teoreticky má možná matika pravdu, praxe je trochu jiná) při restartu apache chytnout výpadek. Restart určitě netrvá minutu a půl, trvá pár sekund.

Nicméně i kdyby zaznamenalo, tak je to jedno, protože tento výpadek vykompenzuje nezaznamenání výpadku dlouhého 7 minut 58 vteřin (při 4minutovém intervalu)
Jakto?
čas 0.00 —výpadek = ve statistice 4 minuty nedostupné
čas 0.04 —výpadek = ve statistice už 8 minut nedostupné

Takže při výpadku trvajícím 7:58 to započítá 8 minut, nemýlím-li se.

Pořád mi totiž buď odpovídáš na něco jiného, než se ptám; a nebo jsem tedy já negramotný, protože nemám tři vysoké školy.

djlj
Zaznamená. Na té stránce je psáno, že se po třiceti vteřinách zkouší spojení z dalších dvou míst, to tedy máme minutu a půl. Pak nechápu, jak můžu (a že se mi to stává častěji než uvádí nějaká výše uvedená statistika) při restartu apache chytnout výpadek. Restart určitě netrvá minutu a půl, trvá pár sekund.

Vlastně máš pravdu, zrovna restart Apache to chytne. Při restartování Apache totiž stroj požadavky neignoruje, ale přímo odmítá. Nečeká se tedy na timeout, čili i to ověření je hodně rychlé.
Při "obyčejném" výpadku, kdy server vůbec neodpovídá, měření propadne na timeout a při ověření už zase stroj odpovídá. Kdyby se tedy před restartem vyndal a zandal drát od připojení, měření by výpadek nezaznamenao. Docela paradox.

> Nicméně i kdyby zaznamenalo, tak je to jedno, protože tento výpadek vykompenzuje nezaznamenání výpadku dlouhého 7 minut 58 vteřin (při 4minutovém intervalu)
Jakto?

Heh, omlouvám se, měl jsem na mysli výpadek dlouhý 3:58. Nevím jak jsem na to přišel. Tohle mám koukám špatně i v tom předcházejícím příspěvku.
Myslel jsem tohle:
00:00 - proběhlo měření, dostupné
00:01 - začal výpadek
03:59 - skončil výpadek
04:00 - proběhlo měření, dostupné
:-)

Při restartování Apache totiž stroj požadavky neignoruje, ale přímo odmítá.
Aha, tak tím to je vysvětleno :).

A je i vysvětleno tedy i to druhé ;). Je pravda, že tímhle se to vyváží; když mám tu možnost, snažím se restartovat právě mezi měřeními, aby tam nebyl kvůli blbině výpadek.

když mám tu možnost, snažím se restartovat právě mezi měřeními, aby tam nebyl kvůli blbině výpadek.

:-)

djlj: snažím se restartovat právě mezi měřeními
Prozradis jak to delas? :) Protoze tail -f xyz.log to asi nebude to prave orechove.

armin
Podle toho, kdy proběhlo poslední měření. Je to napsané v detailu každého hostingu.

Každopádně by tenhle typ „výpadku“ mohl Aleš Janda nějak vychytat. Kdyby tam byl třeba 20 sekund timeout, bylo by to ok ;).

Každopádně by tenhle typ „výpadku“ mohl Aleš Janda nějak vychytat.

No ale jak? Čekat mezi měřeními, když je výpadek, ale rychlá odezva?

To by sice bylo řešení, ale v podstatě by to degradovalo to měření - ono je žádoucí, když to odchytne i 2vteřinový výpadek. To, že to funguje jen v některých případech je něco jiného.. Degradovat nějaký typ měření kvůli tomu, že je zdegradovaného i jiný typ... nevím nevím :-)

A na nic jiného - ideálně rozpoznání normálního krátkého výpadku - mě řešení nenapadá.

Pánové, ja tedy nejsem webhostér, ale zákazník. A z mého hlediska to měření vyhovuje.
Já ho používám hlavně jako srovnávací - absolutní hodnoty mne až tak neberou.
Tedy měření je z principu nepřesné, ale pro mne je důležité, že pro každého nepřesné stejně.

Z hlediska pravděpodobnosti nevěřím, že ten hosting s nižší dostupnosti má tu smůlu, že jede furt, akorát době měření zrovna restartuje apache, kdežto ten dobrý jede furt špatně a zvedne se zrovna v době měření.

Já bych ho zavrhl ve chvíli, kdy by se provalilo, že nějaký hosting zvýhodnil.
Ale do té doby mne jeho nepřesnost vůbec nezajímá.

BTW: a asi pro nikoho to není jediné kritérium

ten hosting s nižší dostupnosti má tu smůlu, že jede furt, akorát době měření zrovna restartuje apache
To ne, ale apache se třeba restartuje několikrát denně, protože se generují statistiky, při kterých rotují logy.

No ale jak?
Nevím, Tys přece nahoře psal, že se v tom vyznáš.

Je to jen a pouze nahoda. Neni mozne, aby se kyblsoft dejme tomu vzdy v celou "desetiminutovku" dotazoval na vsech 400 hostingu. Takze pokud djlj bude mit vypadek stejne jako ja na 5 vterin, a na me se dotaze kyblsoft v case vypadku, tak je jasne ze ja budu nedostupny, djlj za 14-15 vterin bude dostupny. To ze se apache musi restartovat, o tom nikdo nevi. To ze se restartuje sam v nastavenych intervalech, to taky nikdo nevi. stejne tak jako nikdo nevi zda se kyblsoft dotazuje na sekundu presne kazdych 10 vterin. Takze jak uz jsem psal v x vlaknech, je to smerodatne, ale nelze tomu 100% verit.

Co se tyce pocitani statistiky, tak mozna bych doporucil zda by bylo mozne vymyslet i nejaky koeficient rekneme od 1 do 10 ktery by charakterizoval charakter vypadku. Jednicka by byla kratke vypadky, 10 by byla dlouhe vypadky. To by bylo myslim docela zajimave.

Vyuzivam mereni od monitoring-serveru.cz, mam nastaven 15 vterinovy interval a nemohu se stezovat. Nekolika minutove vypadky mi to zaznamena pomerne presne a to je pr ome dulezite.

Dotaz pro Aleše Jandu:
Chtěl bych si v monitoringu serverů nastavit normálně timeout na 15s, ale pokud by byl timeoput vetsi nez 2s, tak aby to uz zaznamenalo jako vypadek. Bylo by to mozne?

Pane Janda vysvetlete mi tposim tento jev :

jsou 3 merene stranky : 1 - www.netzona.cz 2. masaze.netzona.cz 3. czdc.netzona.cz

Par vypisu mereni :

Hlavní stránka Hostovaná #1 Hostovaná #2
24.1.2008
22:19:31 22:20:52
22:13:29 22:14:50
22:10:54
22:09:04
22:03:56 22:05:18
22:00:05 22:01:27
21:56:08 21:57:30
21:50:27 21:51:49

Velice zajimave hodnoty. Vzhledem k tomu ze vsechny tri stranky jedou na jednom serveru, jak to ze tak rozdilne dostupnosti? Mam k tomu jeste prilozit namerene vysledky ze siuxu?

Radek Novák
Chtěl bych si v monitoringu serverů nastavit normálně timeout na 15s, ale pokud by byl timeoput vetsi nez 2s, tak aby to uz zaznamenalo jako vypadek. Bylo by to mozne?

Moc nechápu. Pokud by se měření zaznamenalo jako výpadek už po 2 vteřinách, proč by se mělo čekat dalších 13 vteřin? Nějak to ještě objasněte.

Nobelicek
To je zajímavé. Koukal jsem se do logů a zjistil jsem, že se v ten čas referenční stránka #2 vůbec neměřila. To je dost chyba, během dneška se na to podívám. Díky za report.

Jinak pokud to jsou stejné servery, nemá cenu je všechny měřit. Ono to není ani na to moc dělané; měření probíhá v několika vláknech zároveň, ale jeden hosting obsluhuje vždy jen jedno vlákno, čili stránky se měří postupně. To nemá žádný zvláštní důvod, prostě to tak bylo nejjednodušší udělat. Ale vidím, že to nebyl dobrý nápad. Pokud jsou měřené servery různé, nevadí to. Pokud se jedná o tentýž server, je referenční stránka #2 ve výhodě, protože než se naměří výpadek hlavní stránky a #1, může server začít fungovat. Což budí dojem vyšší dostupnosti, než ve skutečnosti je.

Děkuji za upozornění, během dneška tedy udělám, aby se stránky měřily paralelně i v rámci hostingu, což i tenhle problém odstraní.

Ono by bylo dobre merit i stranky na ostatnich serverech. PRotoze vsechny tri stranky ktere merite jsou na serveru alfa. Ale uz nemerite zadnou stranku na beta gama atd atd. Takze i tak je dostupnost dost odlisna od celkove dostupnosti celeho hostingu. Nehlede na to ze na alfu jiz zadne nove hostingy nepridavame a spis se je snazime presouvat na novejsi servery a alfu vyclenit jen pro postu a administraci.

Nobelicek
Dobře, rád zařadím i ostatní servery. Doporučíte mi tedy nějaké adresy, které mám dát do měření místo těch stávajících? (klidně mailem)
Díky.

Nemohu na Vas nikde najit emailovy kontakt. Budete tak hodny a poslete mi ho sem nebo na capousek@netzona.cz ?