Ještě než začnete se samotnou optimalizací aplikace, tak se věnujte proměření jednotlivých míst kódu, který chcete zrychlit. Namísto velkých úprav, které se provádí jednou za čas se vyplácí provést menší úpravy na kódu, který se provádí velmi často.

Tip 1 - Vracet víc výsledkových množin najednou

Prozkoumejte kód na to, kolikrát je přistupováno k databázi. Pokud je ve skriptu přistupováno více než jednou, zkuste optimalizovat. Každý dotaz k databázi snižuje počet požadavků, které vaše aplikace stihne zvládnout za jednotku času.

Pokud potřebujete přesto víc výsledků, použijte dynamické SQL a nechte si vracet více výsledků v jednom (multiple resultsets). Případně můžete také použít uložené procedury (stored procedures). V uložené proceduře můžete omezit množství dat, které se bude posílat z databázového serveru a budete tím šetřit zdroje. Ať už přenosové pásmo mezi databází a webovou aplikací, tak i alokaci paměti pro data na straně webového serveru.

Tip 2 - Stránkovat přístup k datům

Objekt DataGrid umožňuje velmi zajímavou věc - stránkovat. Přístup k datům je omezen vždy na konkrétní počet položek a dole je zobrazována navigační lišta pro přechod na ostatní stránky.

Tato funkce má bohužel jednu nepříjemnou vadu. Pro zachování funkčnosti je třeba, aby byl DataGrid připojen na data. Pokud je celkem 100 000 položek, tak bude z dotazu 99 975 položek odstraněno a zobrazí se pouze 25 (počet na jedné stránce). Čím více poroste množství dat v databázi, tím pomalejší pak bude vaše aplikace.

Pro efektivnější přístup je lepší použít opět uložených procedur, případně si vytvořit vlastní stránkovací komponentu. Počet vrácených položek se může lišit, pokud je dotaz omezen podmínkou WHERE. Uživatelské rozhraní s tím musí počítat a pro korektní zobrazování je třeba, aby bylo informováno i o celkovém počtu vrácených položek (i když se zobrazuje na stránce pouze část).

Tip 3 - Sdílení připojení

Namísto, aby se webový server s každým dotazem do databázového serveru připojoval novým TCP spojením, je možné založit několik otevřených spojení k databázovému serveru. Tyto spojení neuzavírat, ale opakovaně je užívat pro další dotazy.

I když by vše mělo fungovat i automaticky, tak CLR nevěřte a explicitně volejte uzavření spojení, jakmile jej přestanete potřebovat.

Pro efektivní sdílení spojení existuje několik pravidel. Je lepší několikrát spojení otevřít a zavřít, než jej mít otevřené po celou dobu běhu skriptu. Nepoužíváte-li pro různá připojení stejného připojovacího řetězce, sdílení databázového spojení nebude možné efektivně využívat a ukládat dotazy do vyrovnávací paměti.

Tip 4 - ASP.NET Cache API

Před výkonovou optimalizací je dobré maximalizovat využití ASP.NET Cache API. Stačí přidat referenci na System.Web.dll a pro přístup ke Cache přistupovat k HttpRuntime.Cache (Page.Cache nebo HttpContext.Cache). Data, která budou použita více než jednou, jsou dobrým kandidátem pro vyrovnávací paměť. Čím více jsou data obecnější, tím vhodnějším kandidátem pro cache jsou.

Při použití cache si dávejte problémy na ukládání velkého množství dat. Většina problémů řešených na helplince, které jsou s cachováním spojené souvisí právě s nadužíváním cache. Algoritmus používaný pro cache je LRU (Last Recently Used). Při vyprazdňování jsou odstraňována data, které nebyly používána nejdelší dobu.

Tip 5 - Cachování požadavků

Zatímco Cache API slouží k ukládání dat, která se používají delší dobu. Cachování dat jednotlivých požadavků ukládá pouze to, co potřebuje právě vyřizovaný požadavek. Do proměnné HttpContext.Items je možné ukládat data, která budou dostupná po dobu trvání požadavku.

Tip 6 - Provádění na pozadí

Náročnějších operací je třeba provádět opatrně. Systém nemusí vydržet provádění při každém požadavku. Pro takové operace je možné použít zpracovávání na pozadí. Ať se jedná o odesílání emailů, indexace nově přidávaného obsahu nebo filtrování periodicky importovaných dat. Definovaný objekt Timer (System.Threading) umožní periodické spouštění libovolného aplikačního kódu. Timer následně po definovaném čase vybírá Thready z fronty ThreadPool.

Tip 7 - Výstupní Cache stránek a Proxy servery

Cachování výstupních stránek lze jednoduše zapnout následujícím řádkem kódu:

<%@ Page OutputCache VaryByParams="none" Duration="60" %>

Po vygenerování bude stránka uložena na 60 vteřin a může být několikrát znovu použita. Parametr VaryByParam umožňuje odlišit různé stránky podle parametru v GET nebo POST požadavku. Parametr se použije jako klíč při ukládání do ASP Cache.

Vyrovnávací paměť sice aplikace neurychlí, ale může velmi znatelně ulehčit zátěži webového serveru.

Tip 8 - Používejte IIS 6

Pokud nepoužíváte pro běh stránek IIS 6 (Windows Server 2003), tak přicházíte o některé velmi zajímavé výkonové vylepšení. Šestková verze IIS a Server 2003 obsahují jádrem podporované cachování, tak není potřeba v ASP.NET aplikacích měnit ani řádku kódu. V pozadí se o lepší výkon stará cache síťového provozu zabudovaná přímo do jádra systému.

Tip 9 - Používejte Gzip kompresi

Ačkoliv se o nějakou část zvýší zatížení procesoru, sníží se nároky na přenosovou kapacitu a urychlí se stahování stránek ze serveru na klienta. Stejně tak je možné zasílat více požadavků za vteřinu.

Nastavení Gzip komprese v IIS 6.0 bohužel není možné přes žádné administrační rozhraní. Je nutné editovat XML nastavení IIS serveru.

Tip 10 - Serverová kontrola stavů

Při opakovaném zasílání formulářů na server je velmi časté používání ViewState. Data jsou ukládána do zakódované podoby v proměnné ViewState a zasílány spolu s požadavky. Ačkoliv může být použití pohodlné, také má bohužel vyšší nároky na výkonnost serveru. A pokud ViewState nepotřebujete (nevyužíváte postback), stačí jej jednoduše vypnout:

<%@ Page EnableViewState="false" %>

MSDN - 10 Tips for Writing High-Performance Web Applications