Prosim o TEST, maly jednoduchy test na Vasem hostingu

Napsal Whois Proxy;1589802

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.

Delam weby pro testy a taky pro lidi samozrejme a pak predelavam weby pro lidi po lajdacich. Mam nechat zakazku, kdyz prijde na optimalizaci rychlosti webu? Ja nemam problem vysvetlit v cem je pricina, ale jelikoz to chci mit v ramci rozpoctu dokonale, tak hledam reseni a zpusoby jak toho dosahnout maximalne efektivne. Je v tom i ma invence aby byl vysledek maximalni v ramci libovolneho rozpoctu.

Napsal Oleg;1589794

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.

Primárně bys měl klientům vysvětlit, že to je orientační test, na který se nelze spolehnout, nejsou zveřejněny algoritmy, technické podrobnosti a nic dalšího.Pokud jde o bariéry, v tom výsledku testu máš pěknou nápovědu. Zobrazení stránky je celý dlouhý proces a je potřeba ladit a řešit jednotlivé části samostatně a validovat vše jako celek, pro kontrolu. Určitě spoustu věcí znáš, ale jen tak z rychlíku:1. DNS Lookup - tady pomůže TTL, propagace do velkých resolverů (u některých projektů např. pravidelně dotazujeme DNS resolvery, aby měly cache připravenou, pokud není dostatek běžného provozu; nasazují se sondy do různých prostředí a těmi se měří DNS dotazy a případné problémy), běžné časy musí být v max. desítkách ms, opakované návštěvy už většinou chytá i lokální cache na straně klienta. Vezmi si třeba si sítě, z kterých návštěvníci chodí nejčastěji, sežeň si v nich sondy, stanov hranici a měř to, je také dobré to měřit ze sítě od klienta. Z jednoho místa to může být rychlé, z druhého to může skoro web znepřístupnit (UPC je třeba často problematické).2. Initial Connection - vytvoření TCP spojení znamená několik vzájemných zpráv (např. hledej 3-way handshake) mezi klientem a serverem, je to náchylné ná ztrátovost paketů, je dobré řešit a optimalizovat tcp reuse, cachování spojení, u hodně zatížených serverů poté lookup tabulky na linuxu, spousta hostingů tohle neřeší a při hodně spojeních se to exponenciálně spomaluje. Zároveň je to místo častých útoků na servery (ack flood) a lze je snadno přetížit. Tohle spravuje linuxový kernel, měřit se to dá spoustou nástrojů, při špičkách je tohle achillova pata velké části hostingů, server vypadá v pořádku, nic není zatížené a přitom stránky se dlouho načítají. Tenhle čas by nikdy neměl být vyšší než dvojnásobek pingu, to znamená nějaké problémy.3. SSL Negotiation - tady probíhá několik procesů, server by měl posílat cel tls chain, aby si ho klient nemusel donačítat zvlášť, je potřeba nastavit tls reuse při opakovaných spojeních, transparency register někdy generuje velká zpoždění a může stránky znepřístupnit, starší protokol je o dost pomalejší, ale zase má vyšší kompatibilitu. Jako metriku používá počet tls sezení za sekundu na jednom cpu jádru a generuji provoz např. přes ab, je výrazně ovlivněno množstvím entropy v OS (rychlost vs. bezpečnost), je to velký problém na webhostingu, na vps je potřeba doplnit zdroj entropy (např. pomocí haveged). Běžná vps se dají škálovat na asi 800 nových spojení za vteřinu na jádro, na dedikovaném serveru pracujeme s cílovkou i 10tis spojení za vteřinu na jádro.4. Start Render - tahle metrika z prohlížeče je důležitá, znamená, že je veškerý nutný obsah stažený, spojení vytvořeno a je možné začít něco uživateli zobrazovat. Nejčastější chyba je umístění dalších zdrojů do head sekce v html bez async/defered flagů, to jsou bariéry a je potřeba je odstranit. Měříme počet requestů, které je nutné před renderováním vyřídit a jejich celkovou velikost, je nutné sledovat kontinuálně a může být jiné pro HP a jiné pro podstránky.5. DOM Content Loaded - opět důležitá metrika, košatost html může tyhle časy posunout na pomalých zařízených klidne na sekundu a klient musí čekat, často výdám u admin stránek, výpisů eshopů. Velikost html by neměla překračovat o moc stovky KB. Při unbuffered vykreslování stránky je potřeba pohlídat řádně ukončení přenosu jinak prohlížeč bude čekat docela dlouho a zpozdí to vše ostatní, ovlivní to další akce v prohlížeči. Tenhle čas je nutné minimalizovat a zvlášť řešit ty nejpomalejší návštěvníky a hledat důvody.6. On Load - tady se začíná třeba měření GA, spouští se skripty a spouští se klientská část, react aplikace tady začíná svoji pouť a občas si ještě pár sekund něco chroustá. Je tady spousta prostoru k chybám a problémům.A takhle bych mohl pokračovat ještě dál, je toho spousta a téma je komplexní. Dávat prosté html a měřit tím naslepo hostingy generuje náhodná data a ne výsledky měření. Zkušenost čerpám z těch největší webů v ČR, rukama mi jich prošla celá řádka a často jsme ušetřili i terminačních 2/3 serverů jen drobnou optimalizací.

Tak jiste. To TTL mne nenapadlo, vyzkousim, ale dalsi veci na shared hostingach nevytahnu, neni to proste VPS ani tam obcas vse nenastavim sam.Kazdopadne, dekuji za diskusi. Jdu hledat dalsi moznosti jak vymacknout z shared hostingu maximum co jde.Jen oripomenu, ze zde resime normalni weby ne nejake ultra appky a hodne navstevovane weby.