Ladění výkonu

Malá a středně velká prezentace postavená v systému jNetPublish nebo prezentace, která není pod extrémní zátěží, může zpravidla fungovat bez toho, že by se prováděla nějaká cílená optimalizace.

Na druhou stranu prostředky optimalizace, pokud je nutná, jsou tak široké, že tento přehled musí být nutně neúplný. Jen část prostředků potřebných pro ladění má v rukou autor prezentační logiky. Výkonové problémy musí vždy společně řešit tester, systémový administrátor, programátor a autor šablon.

Testování výkonu, dostupné nástroje

jNetPublish má k dispozici nástroje, které jsou schopné poměrně přesně lokalizovat zdroj výkonového problému až na úroveň konkrétního pravidla šablony nebo formátovače, nebo až ke konkrétnímu datovému zdroji.

Použití profilovacích nástrojů by mělo předcházet každému pokusu o výkonovou optimalizaci; měly by se také použít po ní, k ověření jejího efektu.

U rozsáhlých projektů je třeba počítat s několika iteracemi a podle toho projekt plánovat.

Potenciálně problémové konstrukce

Je poměrně málo typů konstrukcí, o kterých lze s velkou mírou pravděpodobnosti předpokládat, že povedou ke zhoršení výkonu:

• Volba forceCount=1 v příkazu while při iteraci přes dotazový datový zdroj pracující s řádově tisícovkami assetů.
• Validace seznamu assetů, které vrací dotazový datový zdroj, podle data.
• Nezanedbatelný vliv může také mít časté hledání dětského assetu podle jména.

Tento seznam je pochopitelně závislý na aktuální implementaci; bude se tedy velmi pravděpodobně s vývojem systému jNetPublish měnit.

Doporučení

Statické stránky

V případě stránek zveřejňovaných přes standardní publikační rozhraní, které není nutné generovat dynamicky a je pravděpodobný velký počet požadavků na jejich stažení, je možné zapnout generování jejich statické podoby.

Takové stránky se potom generují jen jednou – při prvním požadavku – a pro obsloužení všech následujících požadavků na tuto stránku se použije statická podoba stránky uložená na souborovém systému. Pro každý projekt (a sezení) se ukládá na souborový systém odlišná verze statické podoby stránky.

Invalidace na straně serveru je ošetřena automaticky: jakákoli změna kteréhokoli assetu v assetové databázi způsobí zneplatnění příslušných souborů; při následujícím požadavku se tedy bude stránka znovu generovat přes publikační rozhraní systému jNetPublish.

Generování statické podoby se v systému jNetPublish nastavuje pro každou sekci nastavením atributu staticContent (Generovat statickou podobu) na true. Potom všechny generované odkazy, které mají tuto sekci nastavenou jako primární, povedou na statickou verzi stránky.

Typickým případem, který spadá do této kategorie, je CSS, pokud ho generuje šablona. V takovém případě je nutné zapnout generování statické podoby téměř vždy.

Datové zdroje

Tyto poznámky se týkají v první řadě použití assetů typu JDO dotazový datový zdroj.

Cache výsledků

Cache je třeba explicitně zapnout nastavením atributu cachingEnabled (Ukládat výsledky do cache) na true. Pak je ještě třeba zvolit režim cache operací; pokud tomu nebrání nic jiného, nejúčinnější je volba Cache je společná pro všechny uživatele.

Pouze nezbytná validace

Validace výsledků dotazu, tedy kontrola, zda rozsah platnosti pro jednotlivé assety obsažené ve výsledku dotazu, odpovídá jednomu ze zvolených pravidel, může podstatně zhoršit rychlost vykonání dotazu (nebo dotazů). Nejlepší výkon zajistí volba Na dobu platnosti se nehledí; tu je tedy třeba použít, když není požadovaná jiná funkčnost.

Eliminovat zbytečné počítání výsledků

Pro obecný dotaz do assetové databáze lze použít vestavěný asset Dotazový datový zdroj. Vzhledem k šíři funkčností, které tento datový zdroj poskytuje (včetně režimů cache a validace) nemusí být někdy možné zjistit celkový počet výsledků bez iterace přes všechny položky. Pobídky k uvážlivému používání najdete v příslušné dokumentaci.

Obsahová cache

jNetPublish disponuje mechanismem, který umožňuje ukládat výsledek vyhodnocení často používaných fragmentů šablon tak, aby při dalším použití bylo možné použít přímo uložený fragment výstupu. Tento mechanismus se aktivuje použitím samostatně zdokumentovaného příkazu cache.

Vyloučení dětských assetů z akvizice

Omezení typu akvizice

Operátory . i ! je možné nahradit explicitním voláním funkce acquire; funkce má řadu parametrů, kterými je možné jednak přepínat mezi chováním podle operátoru . a chováním podle operátoru !, jednak nastavit, zda se mají vůbec při akvizici brát v úvahu dětské assety.

Tento prostředek je nutné používat s vědomím, že může znepřehledňovat kód šablony; tzn. jen v odůvodněných případech, a ideálně doplnit komentářem.

Nastavení explicitní reference

Toto řešení se týká případů, kdy víme o nějaké konkrétní dvojici assetů ve vzahu rodič – dítě takové, že se v šabloně často hledá dětský asset podle jména jako potomek rodiče. Předpokládejme, že v šabloně je rodičovský asset hodnotou proměnné p a název dětského assetu je "childName".

Pak je řešením nastavit assetu p vlastnost typu reference; název vlastnosti bude "childName" a cílem reference bude dětský asset. Při vyhodnocování se nejprve budou hledat vlastnosti a až po nich dětské assety, na hledání dětského assetu podle názvu tedy vůbec nedojde.

Pozor: toto je řešení, které je skutečně možné uplatnit jen na základě výsledků profilování, ze kterých bylo možné identifikovat konkrétní dvojici (nebo dvojice) assetů. S ohledem na související snížení přehlednosti dat by se nikdy nemělo používat preventivně a mělo by být vždy řádně zdokumentované.