Tag Archives: Performance

Optimalizace výkonu webových aplikací – Slides, dema [TechEd Praha 2012]

Slides a dema z přednášky na konferenci TechEd Praha 2012:

Záznam přednášky nebyl pořizován, rozšířená podoba však byla následně prezentována pro WUG Praha a pro tu existuje záznam.

Návrh schématu DB – Slides a záznam [MS Fest 2011]

Slides z přednášky pro MS Fest Praha 2011:

Záznam z přednášky najdete na našem YouTube Channel:

Návrh schématu databáze – Slides a ukázkové DB [TechEd Praha 2011]

Slides a vzorové DB z přednášky pro TechEd Praha 2011:

Záznam z přednášky nebyl pořizován, jiná verze téže přednášky však byla prezentována pro MS Fest Praha 2011 a k té záznam existuje.

Optimalizace výkonu webových aplikací – Slides, dema a záznam [MS Fest 2010]

Slides a dema z přednášky na konferenci MS Fest 2010 (tentokrát se zaměřením na client-side a přenos):

Z přednášky byl pořizován obrazový záznam (HD 720p), který najdete na našem YouTube Channelu:

Ladění výkonu webových aplikací – Slides a dema [TechEd Praha 2010]

Slides a dema z přednášky na konferenci TechEd Praha 2010:

Záznam z přednášky nebyl pořizován, rozšířená podoba byla však prezentována pro WUG Praha a k té záznam existuje.

Optimalizace databázových aplikací – Slides, dema, záznam [SQL DevCon 2009, MS Fest 2009]

Slides a další materiály z přednášky na konferenci SQL DevCon 2009 a MS Fest 2009 (na obou konferencích byla prezentována velmi podobná verze):

Z přednášky byl pořizován záznam, který je k dispozici na našem YouTube Channelu:

Podobná přednáška v rozsáhlejší podobě se záznamem byla prezentována i pro WUG Praha v březnu 2013.

Zjištění volné paměti počítače na webhostingu

Pokud se chceme z naší hostované ASP.NET aplikace dozvědět něco o stroji, na kterém běží, nemůžeme tak zpravidla udělat přes WMI dotazy, či performance-countery, protože nemáme k dispozici účet s dostatečnými právy a dostáváme výjimku Access Denied.

I nám C#-istům je však k dispozici to, co mají ve VisualBasicu ukryto pod featurou My, konkrétně nás zde zajímá My.Computer.Info, které není nic jiného než instancí třídyMicrosoft.VisualBasic.Devices.ComputerInfo s propertama AvailablePhysicalMemory,AvailableVirtualMemory, TotalPhysicalMemory, TotalVirtualMemory a několika dalšími s informacemi o verzi OS atp.

Stačí si tedy do našeho C# projektu nareferencovat assembly Microsoft.VisualBasic, vytvořit si instanci třídy ComputerInfo a zeptat se jí na přísušné hodnoty:

using Microsoft.VisualBasic.Devices;

...

ComputerInfo computerInfo = new ComputerInfo();
InfoLb.Text = computerInfo.AvailablePhysicalMemory.ToString("n0");

Třída ComputerInfo používá volání podpůrných nativních metod .NET a informace o paměti stroje dostaneme i pod běžným hostingovým účtem.

Klientské (ne)cachování skriptů z WebResource.axd

Skripty emitované do stránky pomocí odkazů do assembly, pomocí WebResource.axd, se v browseru cachují pouze pokud máme debug-kompilaci vypnutou:

<compilation debug="false" />

Firefox velmi pomalý při použití Windows Vista a ASP.NET Development serveru

Načítání webových stránek je pod Firefoxem v kombinaci s Windows Vista a ASP.NET Development serverem velmi pomalé. První podezření padlo na ASP.NET AJAX pod Firefoxem, nicméně pravda se ukázala být jinde.

Za všechno může automatické ladění TCP stacku ve Windows Vista. Na internetu jsem nalezl dvě řešení:

Zákaz automatického ladění TCP stacku…

… lze provést spuštěním „netsh interface tcp set global autotuninglevel=disabled“ z příkazové řádky.

Toto řešení jsem nezkoušel.

Zákaz IPv6 ve Firefoxu

Dle návodu pomůže ve Firefoxu:

  1. přejít na stránku about:config,
  2. vyhledat položku network.dns.disableIPv6,
  3. nastavit hodnotu na true.

Toto řešení bylo jednoduché a účinné.

Jaká je Vaše zkušenost s kombinací Firefoxu, Windows Vista a ASP.NET Development serveru? Nebo jste na stejný problém narazili i při jiné kombinaci produktů?

SessionPageStatePersister: Ukládání ViewState do Session

ViewState se standardně ukládá do formulářového hidden input-fieldu do stránky, posílá se tedy sem a tam na klienta (GET) a zpět na server (POST).

Díky mechanizmu page-adapterů a připraveného SessionPageStatePersister-u lze v ASP.NET velmi snadno přesměrovat ukládání ViewState do Session, tedy na stranu serveru. Primárně je tento mechanizmus určený pro použití se zařízeními (browsery), kde není možné nebo žádoucí view-state pomocí hidden-fieldu přenášet (PDA, mobily, atp.). Nic nám však nebrání rozšířit jeho využití na všechny stránky.

Potřebujeme pouze dvě věci:

1. Připravit page-adapter, který používá SessionPageStatePersister

Vysvětlovat mechanizmus control-adapterů je mimo rozsah tohoto článku – je to prostě něco, co dokáže poměrně dost modifikovat výchozí chování controlů (a stránka je control), například zajistit jiné renderování, nebo právě způsob ukládání ViewState.

Potřebný page-adapter bude vypadat takto:

public class PageAdapter : System.Web.UI.Adapters.PageAdapter
{
   public override PageStatePersister GetStatePersister()
   {
      return new SessionPageStatePersister(this.Page);
   }
}

…nejde o nic jiného, než říci, že se má použít připravený SessionPageStatePersister.

2. Aplikovat page-adapter pomocí .browser souboru

ASP.NET řekneme, že má příslušný page-adapter použít, tak, že modifikujeme/vytvoříme příslušný .browser soubor. Modifikovat lze buď globální nastavení ve složce <windir>\Microsoft.NET\Framework\<ver>\CONFIG\Browsers, nebo pro jednotlivou aplikaci vytvořit .browser soubor do složky ~/App_Browsers.

Soubor ~/App_Browsers/My.browser bude vypadat třeba takto:

<browsers>
   <browser refID="Default">
      <controlAdapters>
         <adapter controlType="System.Web.UI.Page" adapterType="MyNamespace.PageAdapter"/>
      </controlAdapters>
   </browser>
</browsers>

…to je prakticky vše, co musíme udělat pro ukládání ViewState do Session.

Alternativa – overrride Page.PageStatePersister

Pokud máme ve svém projektu zavedenu společnou bázovou třídu všech stránek (což každopádně i jinak doporučuji), pal můžeme místo PageAdapteru můžeme i rovnou overridování property PageStatePersister:

protected override PageStatePersister PageStatePersister
{
    get
    {
        if (_pageStatePersister == null)
        {
            _pageStatePersister = new SessionPageStatePersister(this.Page);
        }
        return _pageStatePersister;
    }
}
private PageStatePersister _pageStatePersister;

…nevýhodou je pevné zakomponování volby Session jako ViewState uložiště do aplikace, na rozdíl od předchozí konfigurační možnosti nad hotovou aplikací.

POZOR!!! Od property PageStatePersister se nedokumentovaně očekává, že ji bude během jednoho requestu možno volat opakovaně a stále bude vracet stejnou instanci! Zatímco metoda PageAdapter.GetStatePersister() je zvnějšku obalena cachováním instance, v property si tento mechanizmus musíme zajistit sami pomocí private fieldu.

Konfigurace SessionPageStatePersisteru

SessionPageStatePersister se dá konfigurovat z web.configu pomocí elementu <sessionPageState />:

<system.web>
  <sessionPageState historySize="9" />
</system.web>

Jediným nastavitelným atributem je historySize, kterým se volí počet ViewState záznamů, které má persister udržovat. Výchozí hodnota je 9.

Úskalí použití SessionPageStatePersisteru

  • ViewState je ukládán jako položky Session + existuje slovník, který udržuje jaké klíče v Session odpovídají jakému požadavku.
  • Výchozí velikost tohoto slovníku je 9 záznamů, lze však změnit pomocí konfigurace.
  • Každý požadavek vytvoří nový záznam, desátý požadavek vytěsní první.
  • Pokud si tedy uživatel otevře více než 9 oken, pak načtení view-state selhává!!! Metoda není tedy ve výchozím nastavení příliš vhodná pro stránky s frames, nebo různá dialogová okna.
  • Ztrátou Session ztratíme i ViewState, pokud tedy máme například InProc session a restartujeme webovou aplikaci, ViewState je pryč.

Východiskem z některých situací je detekce ztráty ViewState.