logo
04.07.2020 17:17
31
Původně odeslal Wladass
Psal, že to CF měl vyplý. Ono tohle testování z tohodle webu.. Strašně to kolísá. Nuda :D
Exon používa cloudflare i pro webservery - předpokládám, že toto měl vyplý. Těžko měnil kvůli testu DNS

Co se právě děje na Webtrhu?

04.07.2020 17:18
32
Ano ale DNS je stale cez nich. Však je mozne te ten server speedtestu je v rovnakom DC?

Ja sem dam verejny link a spravim aj domenu s dns u nas.

Naviac ako jediny mame LiteSpeed ako webserver takže tak...

Ale po 23:00 :) migrujeme na novy hw
04.07.2020 17:20
33
Původně odeslal Jamira40
Ano ale DNS je stale cez nich. Však je mozne te ten server speedtestu je v rovnakom DC?

Ja sem dam verejny link a spravim aj domenu s dns u nas.

Naviac ako jediny mame LiteSpeed ako webserver takže tak...

Ale po 23:00 :) migrujeme na novy hw
Je to v GTS :)
04.07.2020 17:21
34
Tak to nie my sme v ServerParku. Ale ako som napisal dam verejne linky.
04.07.2020 22:30
35
Původně odeslal Jamira40
Ano ale DNS je stale cez nich. Však je mozne te ten server speedtestu je v rovnakom DC?

Ja sem dam verejny link a spravim aj domenu s dns u nas.

Naviac ako jediny mame LiteSpeed ako webserver takže tak...

Ale po 23:00 :) migrujeme na novy hw
Bylo by prosim mozne u daneho mereni zaslat "Request Details"?
05.07.2020 19:20
36
Len taky update. Otestovalo sa to aj s Cloudflare DNS aj Bez ich DNS a rozdiel je v prvom requeste kedy treba resolvnut IP webu. Inač je to TTFB +/- rovnake.
06.07.2020 10:02
37
Taky pridam maly update.

Standardni mereni na https://www.webpagetest.org/ probira v rezimu Connection Chrome - Cable (5/1 Mbps, 28ms RRT) - najdete v Advanced Settings.

Pokud takto merime standardne weby, je to uple jiny svet, prave ten TTFB a First Byte odpovida vetsine mereni, ktere uzivatele provedli, tj. First Byte klidne 150-300ms. Kupodivu nezalezi zda je to na Cloudflare CDN nebo ne, ta hodnota je +/- nekolik desitek ms stejna.

Pokud provedeme test mereni Chrome - Native, tj. bez network trottle tak ty hodnoty jsou +/- stejne (myslim tim ty nejnizssi) a u nekolik radu samozrejme lepsi nez klasicke mereni - avsak takove mereni neodpovida vubec realite vetsine navstevniku, kteri web prohlizi, tj nevyuzije v podstate nikdy plnou rychlost tak jak je v rezimu Native. Analogie k tomuto mereni je prave Pingdoom mereni, ktere meri plnou rychlosti server-server bez network trottle.

Tj. pokud nejaky web ma v Native rezimu Firts Byte 30-100ms, tak v Cable je to 150-300ms.
06.07.2020 14:27
38
A k čemu ti to pomohlo teda? Nebo jaký je závěr?
06.07.2020 17:40
39
Původně odeslal Wladass
A k čemu ti to pomohlo teda? Nebo jaký je závěr?
Resim tuto optimalizaci s hostingem, zkusime prenastavit par veci a uvidime. Jeste premyslim, ze nasadim na testovani Hurricane Electric DNS misto Cloudflare.

Jde o to, ze pokud delam optimalizaci webu a kompletni web na WP udela First View za 600-800ms (pri tom mereni Chrome - Cable 5/1 Mbps) tak tech 150-300 ms na First Byte me tam hrozne se*re, je to hrozny rozdil, kdyz uvazim, ze napriklad web ma cca 270KB.

Jeste se to da vyresit vse pres Edge Cache na CF ale to uz miji se filosofie optimalizace webu pomoci refaktoringu kodu a bezplatnych pluginu etc vs nasadit placene CDNka a ultra drahe VPSka.
06.07.2020 18:25
40
CF DNS je jednoznačně nejrychlejší (viz dnsperf.com). HE.net je daleko i za českým anycastdns.cz od Gransy
06.07.2020 20:21
41
Původně odeslal Whois Proxy
CF DNS je jednoznačně nejrychlejší (viz dnsperf.com). HE.net je daleko i za českým anycastdns.cz od Gransy
Ja jdu po tech bezplatnych DNS, kdo nabizi bezplatne DNS, krome CF, HE, omezene NS1 a ClouDNS? Obavam se ze "full speed" u CF je jen u premium uctu.
06.07.2020 21:59
42
Původně odeslal Oleg
Ja jdu po tech bezplatnych DNS, kdo nabizi bezplatne DNS, krome CF, HE, omezene NS1 a ClouDNS? Obavam se ze "full speed" u CF je jen u premium uctu.
To neviem potvdiť ani vyvrátiť. Určite to platí u časti služieb hlavne teda (free) CDN je routované často cez lokality ktoré sú lacnejšie na traffic.
V prípade DNS ale rozdiel nejako nepozorujem (Free vs Business) že by tam bola nejaká latencia.
06.07.2020 22:08
43
Jeste mne zajima proc je takovy rozdil TTFB/First Byte pri testu rychlosti u Cable 5/1Mbps vs Native? 150-250ms je extra ujedy rozdil. Umite to nekdo vysvetlit?

---------- Příspěvek doplněn 06.07.2020 v 22:17 ----------

Původně odeslal Jamira40
To neviem potvdiť ani vyvrátiť. Určite to platí u časti služieb hlavne teda (free) CDN je routované často cez lokality ktoré sú lacnejšie na traffic.
V prípade DNS ale rozdiel nejako nepozorujem (Free vs Business) že by tam bola nejaká latencia.
U placeneho CF je Argo a to dodava neskutecnou stavu pak jeste dodatecna pravidla kdy vse lze nacachovat, neco z toho baypassnout a v podstate zredukovat odezvu temer o polovinu. Jenze ted aktualne zadny placeny ucet u CF nemam a hledam zpusob jak to udelat pomoci dostupnych porostredku, aby to bylo aplikovatelne ve vetsine pripadu.

Jiste, muzu jit na dren a osekat WP na kost, nebo pouzit jiny CMS nebo pouzit vlastni CMS, jenze v realu to tak vzdy nefunguje a/nebo neni to zadouci z libovolnych duvodu.
06.07.2020 22:19
44
Původně odeslal Oleg
Jeste mne zajima proc je takovy rozdil TTFB/First Byte pri testu rychlosti u Cable 5/1Mbps vs Native? 150-250ms je extra ujedy rozdil. Umite to nekdo vysvetlit?
Dôležitá je hodnota 25ms RTT. Zjednoušene je to umelé navýšenie latencie. No a to HTTPS spojenie... potrebuje Resolvnúť DNS
Nasledovne spraviť TCP Handshake (1 Roundtrip 25ms), ďalšje TLS Handskahe to máte hneď 2 roundtrips po 25ms no a nakoniec HTTP čo je jeden roundtrip.

Celkovo sme už na 100ms a DNS ako bonus ak to nie je v cache.

EDIT1: A to je len pridané na strane toho testu. Ešte do toho treba započítať reálnu odozvu samozrejme.
EDIT2: Argo je priplatková služba a je platená $5 mesačne + $0.10 za GB čo je neskutočne drahé. Sama o sebe nie je aktívna v žiadnom balíčku Pro ani Business (oba máme). Ale samozrejme súhlasím že to má pekný dopad na to cez čo to routujú.
06.07.2020 22:44
45
Argo nemá vliv na DNS a u DNS rozhodně nejde určovat lepší/horší latenci pro jednotlivý domény.
07.07.2020 10:12
46
Původně odeslal Whois Proxy
Argo nemá vliv na DNS a u DNS rozhodně nejde určovat lepší/horší latenci pro jednotlivý domény.
Argo ma vliv na redukci celkove rychlosti odezvy/nacitani, stejne jako edge cache u CF. Neco jako mereni pres webpagespeed v rezimu cable vs native. Nepis mi zde blbosti, mam to overene v praxi. Hledam bezplatne alternativy a moznosti jak dosahnout podobnych rychlosti bez pouziti premium sluzeb.
07.07.2020 11:01
47
Původně odeslal Oleg
Argo ma vliv na redukci celkove rychlosti odezvy/nacitani, stejne jako edge cache u CF. Neco jako mereni pres webpagespeed v rezimu cable vs native. Nepis mi zde blbosti, mam to overene v praxi. Hledam bezplatne alternativy a moznosti jak dosahnout podobnych rychlosti bez pouziti premium sluzeb.
Žádné blbosti nepíšu. Argo slouží pro webtraffic a ne pro DNS traffic, který se chová uplně jinak.
07.07.2020 11:36
48
Původně odeslal Whois Proxy
Žádné blbosti nepíšu. Argo slouží pro webtraffic a ne pro DNS traffic, který se chová uplně jinak.
Ja nepotrebuji DNS traffic, ja potrebuji minimalizovat odezvu serveru na minimum, o tom toto tema bylo, abych zjistil jak jsou na tom ostatni hostingy.
07.07.2020 11:45
49
Původně odeslal Oleg
Ja nepotrebuji DNS traffic, ja potrebuji minimalizovat odezvu serveru na minimum, o tom toto tema bylo, abych zjistil jak jsou na tom ostatni hostingy.
Ok :D v grafech je vidět, že nejvíc času před TFB je DNS resolution. V diskuzi ve které jsem reagoval si řešil náhradu CF DNS za HE.NET DNS, a tam jsem následně reagoval, že Argo nemá na DNS vliv, nacož si mě označil, že pišu hlouposti :D A teď, že o DNS není řeč :)
07.07.2020 12:37
50
Původně odeslal Whois Proxy
Ok :D v grafech je vidět, že nejvíc času před TFB je DNS resolution. V diskuzi ve které jsem reagoval si řešil náhradu CF DNS za HE.NET DNS, a tam jsem následně reagoval, že Argo nemá na DNS vliv, nacož si mě označil, že pišu hlouposti :D A teď, že o DNS není řeč :)

Primarnim ucelem diskuse bylo zjistit proc je tak velky rozdil v First Byte / TTFB. Vis proc rychlost pri stejne velikosti souboru pod 300B je rozdilna pri mereni v rezimu Cable vs Native?

Dale, DNS CF, podle mne, nenabizi plnou rychlost ve variante Free vs placene verzi. Dale, Argo samozrejme ma zasadni vliv na rychlost odezvy serveru - co na tom nechapes? Mas to popsane na oficialnim webu/blogu CF. Mam s tim prime zkusenosti. Stejne jako prime zkusenosti s CF Edge Cache.

To co na normalnim CF DNS ve free verzi dam na DNS: SSL > Connect > Send > Wait > Receive za 300-350ms tak s argo je to kupodivu za 180-200ms a s Edge Cache za +/- 120ms.

DNS Lookup: 50-140ms CF Free. S Argo za 20-80 s Edge Cache za 15-50.

Hledam alternativy k placenemu CF, tak budu zkouset HE.


Mas nejake dalsi poznamky nebo zkusenosti misto omacky kolem jen abys nahnal pocet postu ve foru?
07.07.2020 12:41
51
best-hosting.cz, čistý nginx, dns u digitalocean.com, bez CF/CDN a jiných urychlovačů

07.07.2020 12:51
52
Původně odeslal Oleg
Ja nepotrebuji DNS traffic, ja potrebuji minimalizovat odezvu serveru na minimum, o tom toto tema bylo, abych zjistil jak jsou na tom ostatni hostingy.
Pokud chceš minimalizovat odezvu, nejlepší je jít do vps s vyhrazenými prostředky, tak aby tě neovlivňovaly jiní klienti jejich zatížením. Máš-li to pro konkrétní aplikaci je potřeba nastavit test podle plánovaného využití aplikace, nejde totiž snad nikdy o čísla takhle prázdného nezatíženého webu, ale potřebuješ udržet určité hodnoty pro median (třeba 90 %). Stejně tak je nutné počítat s použitím určitých protokolů, je super vše vyladit na TLS 1.3 s HTTP/2 a pak mít spousty návštěvníků se starým androidem nebo IE prohlížečem, to si moc nepomůžeš.

Všechna zde zveřejněná měření jsou přijatelná pro jakýkoliv web, ale musíš je udržet i při vysokém zatížení, tam je pak panečku již pěkný problém.

K DNS. Pěkně tady řešíte DNS, ale CF, HE a další jsou jen resolvery, ty neovlivníte pro náštěvníky (ani tady pro měření), protože to má každý jinak, rychlost DNS (zejména prvního vyhledání) bude záviset na autoritativních NS, ty se také nesmí přetížit. Ani CF není nejrychlejší pokud nemá data v cache a musí je získat, i u tohoto měření mohl být výsledek ovlivněn tím, že se to testovalo na nové doméně, kterou nikdo neměl v cache.

Pokud tě to jen osobně zajímá, klidně si to takhle testuj, pokud na tom chceš založit důležitý projekt, najmi si někoho zkušeného, je v tom tolik háčků, že je potřeba určitá zkušnost a znalost, i spousty zde zmíněných hostingů se v tom dost plácají a mají velké mezery v konfiguracích.
07.07.2020 15:02
53
Původně odeslal TomášX
Pokud chceš minimalizovat odezvu, nejlepší je jít do vps s vyhrazenými prostředky, tak aby tě neovlivňovaly jiní klienti jejich zatížením. Máš-li to pro konkrétní aplikaci je potřeba nastavit test podle plánovaného využití aplikace, nejde totiž snad nikdy o čísla takhle prázdného nezatíženého webu, ale potřebuješ udržet určité hodnoty pro median (třeba 90 %). Stejně tak je nutné počítat s použitím určitých protokolů, je super vše vyladit na TLS 1.3 s HTTP/2 a pak mít spousty návštěvníků se starým androidem nebo IE prohlížečem, to si moc nepomůžeš.

Všechna zde zveřejněná měření jsou přijatelná pro jakýkoliv web, ale musíš je udržet i při vysokém zatížení, tam je pak panečku již pěkný problém.

K DNS. Pěkně tady řešíte DNS, ale CF, HE a další jsou jen resolvery, ty neovlivníte pro náštěvníky (ani tady pro měření), protože to má každý jinak, rychlost DNS (zejména prvního vyhledání) bude záviset na autoritativních NS, ty se také nesmí přetížit. Ani CF není nejrychlejší pokud nemá data v cache a musí je získat, i u tohoto měření mohl být výsledek ovlivněn tím, že se to testovalo na nové doméně, kterou nikdo neměl v cache.

Pokud tě to jen osobně zajímá, klidně si to takhle testuj, pokud na tom chceš založit důležitý projekt, najmi si někoho zkušeného, je v tom tolik háčků, že je potřeba určitá zkušnost a znalost, i spousty zde zmíněných hostingů se v tom dost plácají a mají velké mezery v konfiguracích.

Ja se o to predevsim zajimam z duvodu kdy resim optimalizaci rychlosti webu a nevychazi mi ta logika (mereni webu o velikosti 300KB vs 300B) pod to zcela stejny +/- nekolik desitek ms rozdil na FB/TTFB.

Nektere testy ukazaly i na Wedosu First Byte za 0,09 ms, a ten je zatizeny, pravdepodobne, az az.
Na nove domene test nedelam, domena bezi 5+ let, minimum 1+ rok

Jop, TLS mam v minimalni verzi 1.2 h2 pokud to prohlizec dovoli tak to pujde pres TLS 1.3 s 0-RTT.


Prave, ze na VPSku apod. se vse resi jednoduse. Ale tady chci dojit nejakemu rozumnemu vysvetleni proc to tak je ve vetsine pripadu a proc Cable ma jiny DNS lookup a FB/TTFB nez Native rezim mereni plnou rychlosti server-server bez network trottle.


Prave jak jsem chtel, vsechny testy bez CDN a jinych urychlovacu apod. Takze nektery web to ma dobre jiny proste hroznou odezvu. Nedava mi to vubec zadnou logiku a jak jsem psal, cloveka docela dost zamrzi napriklad pokud web je na Wordpress nacten do 800ms z celho FB je 150-300ms.


Dal hledam nejake vysvetleni a zkousim to vselijak resit.
07.07.2020 16:14
54
https://www.webpagetest.org/forums/s....php?tid=14159 - Cable vs Native chápu jako omezení na straně testu na simulaci připojení přes domácího poskytovatele, vs. spojení z měřícího serveru jak síť dovolí.

Co je pro mě překvapením z tý diskuze, tak WPT využíva pro test reálné prohlížeče a ne jen simulace.
07.07.2020 16:27
55
To jsem cetl taky a nedostal odpoved na svoj otazku proc to tak je.

Pokud nekdo ma 1Gbps pripojku nebo 5 Mbps proc mu to hodi zcela jine hodnoty mereni zvlast u toho TTFB/FB. Prece pomaly pocitac a pomale pripojeni by nemelo byt znevyhodnovano tim, ze dostane First Byte az za 300ms, kdezto teoreticky hi end pc s 1Gbps dostane o 2/3 odezvu rychleji ze serveru. To je jety podle mne.

Smysl by to davalo pri vykonu zarizeni a rychlosti pripojeni, kdy by byla hodnota FCP a Fully Loaded odlisna az nasobna ve smyslu pomale/rychle zarizeni a internet.


No nic, budu resit dal, snad najdu reseni.
07.07.2020 16:33
56
Ano, WPT ten cable vs. native řeší na úrovní virtuálního interfacu, kde softwarově pro celou instanci přidává nějaké zpoždění pro každý paket, takže u DNS ty časy zbytečně narostou, stejně tak to postihne kontrolu certificate transparency nebo kontrolu na podvodné stránky u chromu.

Ano, spouští se tam celý container s vlastním prohlížečem, to lze vyvodit z toho, že se tam mohou natáčet videa, uložit z chromu debug panel, udělat jeho snímek (což je vlastně to, co tady se screenuje) atd.

Při měření tam máš i timelinu co jak dlouho trvalo. U DNS to je sranda, pokud web má TTL 60s, většina DNS resolverů to plus mínus dodržuje a při dotazu po expiraci se dotáže na autoritativního NS a to výrazně zpodí dotaz. Nastav TTL na 24h a uvidíš jak i tohle bude mnohem rychlejší.

Měření rozeber na jednotlivé části a ty měř/optimalizuj samostatně, dělat tyhle full chain měření produktují tyhle skoro náhodné výsledky. Pro optimalizaci načtení webu musíš primárně dělat (za mě) dvě věci, hledat/odstraňovat bariéry (velké obrázky, pomalý NS, přístup z jiného světadílu, počet souborů atd.) a zjišťovat/rozstahovat limity (počet souběžných uživatelů, šířka pásma u serveru, vytížení disku vs. cachování).
07.07.2020 16:57
57
Původně odeslal TomášX
Ano, WPT ten cable vs. native řeší na úrovní virtuálního interfacu, kde softwarově pro celou instanci přidává nějaké zpoždění pro každý paket, takže u DNS ty časy zbytečně narostou, stejně tak to postihne kontrolu certificate transparency nebo kontrolu na podvodné stránky u chromu.

Ano, spouští se tam celý container s vlastním prohlížečem, to lze vyvodit z toho, že se tam mohou natáčet videa, uložit z chromu debug panel, udělat jeho snímek (což je vlastně to, co tady se screenuje) atd.

Při měření tam máš i timelinu co jak dlouho trvalo. U DNS to je sranda, pokud web má TTL 60s, většina DNS resolverů to plus mínus dodržuje a při dotazu po expiraci se dotáže na autoritativního NS a to výrazně zpodí dotaz. Nastav TTL na 24h a uvidíš jak i tohle bude mnohem rychlejší.

Měření rozeber na jednotlivé části a ty měř/optimalizuj samostatně, dělat tyhle full chain měření produktují tyhle skoro náhodné výsledky. Pro optimalizaci načtení webu musíš primárně dělat (za mě) dvě věci, hledat/odstraňovat bariéry (velké obrázky, pomalý NS, přístup z jiného světadílu, počet souborů atd.) a zjišťovat/rozstahovat limity (počet souběžných uživatelů, šířka pásma u serveru, vytížení disku vs. cachování).

Tomasi, jaka byla bariera u toho jednoducheho html souboru o velikosti 300 bajtu? Zadna.
Pritom native vs cable mereni je rozdilne, 50-100ms vs 150-300ms. Dela to i na normalnim webu.

Samozrejme ze se snazim eliminovat vsechny bariare ale toto nevim jak, nevim jak to ted jinak eliminovat.

S tim TTL diky za napovedu, zkusim to prenastavit na CF i u sebe na domene a podivam se jak to dopadlo.
07.07.2020 17:29
58
Podle mě se snažíš eliminovat něco, co tam ve skutečnosti není. Je to omezení z jejich strany aby to jakože simulovalo prostě "bežnýho" smrtelníka, který při návštěvě webu sjíždí facebook, čumí na youtube a stahuje péčko na dobrou noc. Tzn ty čísla jsou úmyslně zhoršeny.
07.07.2020 17:46
59
To je fajn, ale klientum to dere oci. Jaky je smysl plazit ultra husta CDNka nebo mit VPSko s vyhrazenym vykonem, pokud to umyslne zhorsi vysledek i tak :D nonsense
07.07.2020 18:16
60
Původně odeslal Oleg
To je fajn, ale klientum to dere oci. Jaky je smysl plazit ultra husta CDNka nebo mit VPSko s vyhrazenym vykonem, pokud to umyslne zhorsi vysledek i tak :D nonsense
Já myslel, že weby se dělají pro lidi a ne pro online testy :) Proto prostě vezmeš víc různých testů a dokážeš, že tvoje řešení je ok, i když jeden test dělá blbosti.