14
« kdy: 12. 07. 2025, 11:59:45 »
Jste autorem té aplikace? Je potřeba tu aplikaci profilovat - buď na srovnatelném hardware a se srovnatelným objemem dat, anebo přímo na hostingu, pokud to je technicky a provozně možné. V aplikaci je nutno vyřešit, aby to bylo dost rychlé. Pokud chcete mít data na klientovi do 80ms a 50ms bude trvat přenos dat, tak ať aplikace html vygeneruje do 30ms. Profiller zobrazí, kde aplikace tráví nejvíc času, podle toho příslušnou část aplikace upravíte (upravíte dotazy do databáze, databázové indexy, vylepšíte zpracování dat, některá data si připravíte předem, použijete vhodnější datové struktury apod.). Pokud budete data přenášet komprimovaně, ušetříte na přenosu dat, takže se přenesou třeba za 15ms a zbyde vám větší rezerva pro aplikaci. Toto byste měl udělat vždy, nestojí to skoro nic, stačí přidat kompresi do konfigurace nginx. Klient ovšem musí mít pro kompresi podporu a vyžádat si data komprimovaná, což je ale dnes většinou standard (prohlížeče to mají defaultně zapnuté, u REST klientů to lze zapnout).
Pak můžete ladit dál - když na generovaný obsah, který se moc nemění, zapnete cachování na straně serveru, tak aplikace nebude muset data vůbec generovat a po dobu životnosti cache se pak bude uplatňovat pouze čas nutný pro přenos - takže v příkladu výše dostanete data za 15ms. Je potřeba se zabývat tím, která data cachovat a jak dlouho. Cachovat může nginx anebo přímo aplikace.
Zejména u webových aplikací můžete dále zlepšit odezvu tím, že budete klientovi posílat správné cache hlavičky, pak může cachovat i klient přímo u sebe, typicky se vyplatí u webových aplikací cachovat css, js a grafické assety (ikony, písma, pozadí, ...). Klient pak vyrenderuje celou stránku rychleji a zlepší se uživatelský dojem.
Akorát je potřeba myslet na to, že přestože má klient data v cache, může posílat aplikaci dotaz na příslušné resource a zpracovávat http hlavičky, kde bude uvedené, zda se resource od minula změnil nebo nezměnil. Tento round-trip musí být pro stav "nezměněno" co nejrychlejší, protože pokud bude klient čekat na odpověd stejně dlouho, jako na plná data, tak se ušetří pouze čas nutný na přenos dat, avšak čekání zůstane.
Pokud nejste autorem aplikace a nemáte možnost spolupracovat s autorem, můžete hledat, zda není úzké hrdlo na hostingu. Bohužel parametry hostingu se v čase mění, nejlepší postup je vyzkoušet několik hostingů a provést standardizované měření a podle toho se rozhodnout. Nezřídka se mi stalo, že hosting šel kvalitativně dolů a bylo potřeba upradovat balíček nebo přejít jinam. Záruky vyhrazeného výkonu dostanete totiž jen na dedikovaném hostingu nebo přímo na dedikovaném hardware, cena je ale logicky vyšší.
Zobrazit příspěvky
AI k tomu radí: