performance címkéhez tartozó bejegyzések

Azure sebesség teszt

Ha aszerint akarod eldönteni, hogy melyik Windows Azure adatközpontban legyen az alkalmazásod, hogy melyik a leggyorsabb, akkor a Windows Azure Speed Test oldal segítségével összemérheted őket:

http://azurespeedtest.azurewebsites.net/

 

Köszönet a linkért Gál Tamásnak.

 

Technorati-címkék: ,

50 teljesítmény tipp ASP.NET webalkalmazásokhoz

A fejlesztői segédeszközeiről híres RedGate kiadott egy ingyenes, 50 oldalas e-bookot 50 ways to avoid, find and fix ASP.NET performance issues címmel. A könyvben MVP-k SQL Server, ORM, .NET Framework, IIS és ASP.NET tippjeit gyűjtötték össze, melyek alkalmazásával jobb teljesítményt facsarhatunk ki a webalkalmazásainkból.

A könyv 50 javaslatot tartalmaz 50 oldalon, ebből talán már látszik, hogy nem az a célja, hogy minden technikai részlettel megismertesse az olvasót, hanem hogy felhívja a figyelmet olyan beállításokra vagy mintákra, amelyek mellett hajlamosak vagyunk nap mint nap elmenni. Ennek megfelelően a könyvben kevés újdonság van azok számára, akik már foglalkoztak ASP.NET teljesítmény tuningolással, számukra az igazi érték, hogy szinte ellenőrző listaként használható a könyv. Aki számára pedig új ez a terület, annak jó kiinduló pontot adhatnak a könyvben található témakörök és kulcsszavak a további tájékozódáshoz.

A könyv letölthető innen: http://www.red-gate.com/50ways

 

Technorati-címkék: ,,,,,

JavaScriptes Windows Store alkalmazások teljesítményelemzése

A Windows Áruházban közzétett alkalmazásoknak megfelelően gyorsnak kell lenniük, különben elutasíthatják őket az alábbi követelményre hivatkozva:

3.8 Az alkalmazásnak meg kell felelnie a teljesítményre vonatkozó alapvető követelményeknek a kis teljesítményű számítógépeken
Az alkalmazásnak legfeljebb 5 másodperc alatt el kell indulnia
Az alkalmazás felfüggesztése legfeljebb 2 másodpercet vehet igénybe

Mindennek a tesztelésére sajnos nem elég az Windows Application Certification Kit, az ugyanis a teljesítménnyel kapcsolatban csak minimális teszteket futtat. Szerencsére JavaScriptben írt alkalmazások esetén használhatjuk a Windows 8 SDK-ban található Performance Analyzer for HTML5 Apps segédprogramot. A Visual Studio telepítése után ez az alkalmazás nem lesz kivezetve a Start képernyőre, tehát kézzel kell elindítanunk a C:\Program Files\Windows Kits\8.0\bin\<platform>\AppPerfAnalyzer mappából a appperfanalyzer_js.exe-t. Ilyen gyönyörű (?) modern (?) a felülete (az eredeti élményért katt a képre a teljes méretért):

appperf-start

A Please select an app to analyze listából ki kell választanunk az alkalmazásunkat (de kiválaszthatjuk a Microsoft alkalmazásait is Mosolygó arc), ami után már rákattinthatunk a Let’s Get Started gombra. Az Advanced gombra kattintva kicsit testreszabhatjuk, hogy milyen teszteket akarunk futtatni:

appperf-advanced

Az indítás után egy 8 lépéses varázslón vezet végig az alkalmazás, ahol minden egyes lépésnél részletes útmutatót kapunk a teendőkről:

appperf-step

A megadott időket vegyük komolyan, különben nem lesz elég adatunk az elemzéshez. A végeredmény egy bőséges HTML formátumú jelentés számokkal és grafikonokkal, amit a C:\Users\<felhasználónév>\AppData\Local\Microsoft\HTML5AppAnalyzer\Traces mappában találunk.

A teszt az alábbi területeket érinti:

  • Activation time
  • UI responsivemess
  • Layout passes
  • Synchronous XMLHttpRequest on UI thread
  • Image scaling
  • Memory footprint
  • Runtimer broker memory reference set
  • Memory leaks
  • Idle state CPU usage
  • Successful suspend
  • Memory reduction when suspended
  • App memory growth
  • Runtime broker memory growth

Érdemes tehát kipróbálni, sokat tudhatunk meg az alkalmazásunk viselkedéséről. A JavaScriptes alkalmazások teljesítményével kapcsolatban itt találhatók további ajánlások angolul: http://msdn.microsoft.com/en-us/library/windows/apps/hh465194.aspx

VS 2010 SP1 – frissítsd a video drivered

Megjelent a Visual Studio 2010 Service Pack 1, ami egyelőre csak az MSDN előfizetők számára érhető el, de pár nap múlva publikus oldalról is letölthető lesz. Jason Zander blogjában található egy lista a javításokról (nincs minden benne, de például a legzavaróbb JavaScriptes problémáim igen Kacsintó arc) és azokról a fejlesztőeszközökről is (pl. Async CTP, LightSwitch), amivel kompatibilitási problémák lehetnek az SP1 telepítése után.

Van egy fontos változás az alapértelmezett beállítások között, ami elsősorban a Windows XP-t használó felhasználókat érinti, de a dolog hátteréről szerintem minden VS 2010 felhasználónak érdemes tudnia. A Visual Studio 2010 alapértelmezés szerint kihasználja a grafikus kártya képességeit, ahogy azt az alábbi ábra is mutatja (katt a nagy képért):

VS_2010_hardware_acceleration

Ez úgy működik, hogy a Studio lekérdezi a video drivertől a kártya képességeit, és ha tetszik, amit lát, akkor megpróbálja bekapcsolni a hardver gyorsítást. A gond ezzel az, hogy a “tudok valamit” és a “jól csinálok valamit” nem mindig jár együtt és ez különösen igaz a video driverek esetén. A statisztikák azt mutatják, hogy a VS elszállások igen jelentős hányada az elavult video eszközmeghajtókra és a hardvergyorsításra vezethető vissza. Ráadásul Windows XP-n az ilyen jellegű problémák száma 2x annyi, mint Windows Vista, Windows 7 vagy Windows Server esetén.

Ezért a fejlesztőcsapat úgy döntött, hogy az SP1-től kezdve Windows XP-n alapértelmezés szerint a VS nem fog hardvergyorsítást használni. Ez az alapértelmezés, amit a fenti ablakban bármikor vissza lehet kapcsolni. Ezen kívül összeállítottak egy Visual Studio Troubleshooting útmutatót is, ami segíthet.

Mi ebből a tanulság? Hogy a VS 2010 nagyon szereti a friss és jól működő video eszközmeghajtókat. XP-n különösen, de más oprendszeren is. Frissítsd a video drivered!

Ne várakoztasd a felhasználót: jQuery Templates és ASP.NET PageMethods

A webalkalmazásokkal szemben az egyik legfontosabb követelmény, hogy gyorsan jelenjen meg az eredmény a böngészőben, ami nem is gond, ha az oldalon kevés adat van. Probléma akkor van, ha az oldalra többféle adatforrásból jönnek az adatok, ekkor ugyanis előfordulhat, hogy egyetlen sokáig tartó adatbázis lekérdezés feltartja a teljes oldal renderelését, hiába jött meg a válasz a többi helyről villámgyorsan. Ekkor a legcélszerűbb megoldás, ha az oldal hamar elkészült részét gyorsan leküldjük a böngészőnek, a lassan előálló részt viszont aszinkron módon rendereljük ki. Hasonló megoldásra van szükség akkor is, amikor az oldal jelentős része output cache-ből jön, de egy kis részből mindig a legfrissebbet kell láttatnunk.

A problémát igazán nem is az aszinkronitás okozza, hiszen manapság már gyerekjáték egy Ajaxos hívást indítani a böngészőből. A gányolás ott kezdődik, amikor a nyers adatszerkezetből formázott HTML-t kell előállítani. Hol tegyük ezt meg: kliens oldalon vagy szerver oldalon? Egyáltalán hogyan lehet ezt kulturáltan megoldani, van jobb megoldás a sztring összefűzésnél?

Szerencsére van jobb megoldás: adatkötés. Jelentős mennyiségű ügyeskedéssel eddig is meg lehetett oldani, hogy szerver oldalon egy ASCX modult készítettünk, abban a szokásos módon szétválasztottuk a kódot és a megjelenést, majd a megszokott adatkötéssel HTML-lé alakítottuk és ezt a kész HTML-t küldtük le a böngészőnek. Ez így elsőre jónak is tűnik, de hamar elkezd több sebből vérezni.

A jó hír az, hogy most már lehet kliens oldalon is adatot kötni! Így nem kell szerver oldalon az adatok formázásával foglalkozni, gyorsan át lehet küldeni a nyers adatszerkezetet a kliensnek, a szép megjelenítésről pedig a böngésző fog gondoskodni. Nagyon vártam már ezt a pillanatot, ugyanis így jelentősen egyszerűsödni fognak az alkalmazásaink, sokkal karbantarthatóbb lesz a kódunk.

Van egy kis dezsavű érzésem, ugyanis ez már a harmadik alkalom, hogy ennek örülök. A Microsoft először 2007-ben próbálkozott a kliens oldali adatkötéssel, akkor XML Script formájában. Aztán azt mind elvetették, jött a Sys.UI.DataView, ami szintén ígéretesnek látszott, de végül az Ajax Library-vel az is ment a kukába. A mostani megoldást szintén a Microsoft kezdte el fejleszteni, de végül a jQuery csapat közreműködésével készült el és jQuery pluginként lett elérhető. Pontosabban két pluginről van szó, a jQuery Templates és a jQuery Data Link pluginekről, az előbbi az adatok megjelenítésére jó, az utóbbi pedig a kétirányú adatkötés megvalósítása. Bár nem ez az első deklaratív megvalósítás a sablon alapú renderelés és az adatkötés megoldására, a jQuery csapat végül úgy döntött, hogy ez lesz a hivatalos, és várhatóan az 1.5 verziótól kezdve az alap jQuery könyvtár részét képezik majd.

Mint a faék

Íme a jQuery Templates használata 4 egyszerű lépésben:

1. Legyen egy JavaScript objektumod az adatokkal:

  var movies = [
    { Name: "The Red Violin", ReleaseYear: "1998" },
    { Name: "Eyes Wide Shut", ReleaseYear: "1999" },
    { Name: "The Inheritance", ReleaseYear: "1976" }
  ];

2. Készíts hozzá egy sablont, ami fontos, hogy text/x-jquery-tmpl típusú script blokk legyen, így a böngésző figyelmen kívül fogja hagyni:

  <script id="myTemplate" type="text/x-jquery-tmpl">
    <li>
        <b>${Name}</b> (${ReleaseYear})
    </li>
  </script>

3. Keress egy placeholdert, ahol az eredményt meg akarod jeleníteni:

  <ul id="movieResults"></ul>

4. Renderelj:

  $("#myTemplate").tmpl(movies).appendTo("#movieResults");

Mondtam én, hogy nem bonyolult. Akárhogy is nézem, egyáltalán nem baj, hogy az előző próbálkozások mentek a levesbe, ez sokkal egyszerűbb és szebb. Az egyszerűségén kívül az tetszik benne nagyon, hogy a ${ } helyekre automatikusan HTML encoded értékek kerülnek. Ha nyers HTML-t, vagy JavaScriptet tartalmazó adataink vannak, akkor a {{html}} placeholdert kell használni. Ezen kívül lehet még a sablonba feltételeket tenni, sablonokat elnevezni és névvel hivatkozni rá és még pár dolgot, akit érdekel, nézze meg a teljes API leírást.

Szerver oldali kóddal

A fenti példa elég sok helyen megtalálható az interneten, de valljuk be, nem túl életszerű, hiszen az adatok többnyire inkább a szerverről jönnek. Ha ilyet szeretnénk, akkor legegyszerűbb az adatokat ASP.NET PageMethod segítségével publikálni:

  public class Movie
  {
    public string Name { get; set; }
    public int ReleaseYear { get; set; }
  }

  public partial class Step2 : System.Web.UI.Page
  {
    [WebMethod]
    public static Movie[] GetMovies()
    {
        return new Movie[]{
            new Movie(){ Name = "The Red Violin", ReleaseYear = 1998 },
            new Movie(){ Name = "Eyes Wide Shut", ReleaseYear = 1999 },
            new Movie(){ Name = "The Inheritance", ReleaseYear = 1976 }
        };
    }
  }

A gyönyörű ebben az, hogy a [WebMethod] attribútum hatására az ASP.NET automatikusan gondoskodik arról, hogy a válasz Movie[] JSON formátumra alakuljon (ha mégis manuálisan szeretnénk, akkor használhatjuk a JavaScriptSerializer osztályt).

Az így elkészült szerver oldali metódust nagyon egyszerű meghívni, elég csak feldobnunk az oldalra egy ScriptManagert és máris lesz egy JavaScriptből hívható PageMethods.GetMovies függvényünk. Persze ha úgyis jQuery-zni fogunk később, akkor logikusabb, ha ezt a PageMethodot is jQuery-ből hívjuk ScriptManager nélkül:

  $(function () {
    $.ajax({
        type: "POST",
        url: "Step2.aspx/GetMovies",
        dataType: "json",
        contentType: "application/json; charset=utf-8",
        success: function (result) {
            $("#myTemplate").tmpl(result.d).appendTo("#movieResults");
        }
    });
  });

Barátságos, nem? Sehol semmi extra kód a sorosításhoz vagy az alacsonyszintű HTTP kommunikációhoz. Egyetlen apró részletre kell figyelni, hogy a válaszban egy d objektumon belül lesznek az értékek. Ennek egyébként az a magyarázata, hogy ha az adatok között JavaScript kód is van, akkor az így nem tud véletlenül végrehajtódni.

Sokat egyszerre

Az Ajax lehetőségeinek bemutatására az egyik kedvenc példám a Pageflakes, mert gyönyörűen látszik, ahogy az oldal egyes részei önállóan betöltődnek. Kipróbáltam, hogy a fenti megoldás működik-e több párhuzamos kérésre is, vagy esetleg a browser connection limit miatt elhal valahol. Átírtam a kódot adatbázisosra és jó sok késleltetést tettem a szerver oldali kódba (így egyúttal azt is kipróbáltam, hogy egy List<T> sorosítása is megy magától), majd megnéztem, hogy mi látszik Firebugban (katt a képre a nagyobb változatért):

jQuery-PageMethods-Firebug

Látszik, hogy a böngészőnek valóban van párhuzamosítási korlátja, nálam a Firefox hatosával küldte el a kéréseket a szerverre. Szerencsére mindez ment teljesen automatikusan, a placeholderekbe tett animáló gifek pörögtek, ahogy kell, így még a felhasználó is kapott visszajelzést.

Ha ehhez a gördülékeny implementációhoz még az OData-t is hozzávesszük, akkor látszik, hogy végre kezdenek összeérni a technológiák, vége a trükközésnek.

Technorati-címkék: ,,,

Alkalmazások bemelegítése IIS 7.5 alatt

Mint minden szoftvernél, webalkalmazások esetén is előfordulhat, hogy az alkalmazásnak induláskor inicializálnia kell magát, adatbázis kapcsolatokat kell felépítenie, cache-t kell feltöltenie, sőt az összes olyan rendszer- és platform komponenst is inicializálnia kell, amelyre ráépül. A .NET keretrendszerre épülő alkalmazások esetén ehhez még hozzájön a just-in-time fordítás, mellyel összességében az alkalmazáshoz érkező első kérés kiszolgálása zavaróan elhúzódhat.

Erre a problémára a hagyományos megoldás az, hogy a felhasználói kéréseket megelőzve mi küldjük be az első kérést a webalkalmazásnak, így mire a valódi felhasználók megérkeznek, már a bemelegített, villámgyors honlappal fognak találkozni. Ezzel a megoldással sajnos legalább három probléma van:

  • Meg kell írnunk a kliens szkriptet, ami HTTP kérésekkel bombázza a webalkalmazásunkat.
  • Gondoskodnunk kell arról, hogy a bemelegítő szkriptünk az alkalmazáskészlet minden indulásakor lefusson.
  • IIS 7.5 előtt a felhasználóktól érkező kérések megelőzhetik a bemelegítő szkriptet (architekturális korlát).

Szerencsére a Windows 7-ben és a Windows Server 2008 R2-ben megjelent IIS 7.5 ezen a területen jelentősen fejlődött. A kulcskérdés az, hogy az alkalmazás minek a hatására kezdi el inicializálni magát?

Tovább a cikk folytatására » 
(A teljes cikk a magyar nyelvű TechNet Portálon olvasható.)

 

Teljesítménynövelés az IIS 7 beépített funkcióival

Az Internet Information Services 7 komponensei között találunk két olyan elemet, amelyek segítségével jelentősen növelhetjük a webkiszolgálónk teljesítményét, mégpedig gyakorlatilag a webalkalmazás módosítása nélkül, pusztán üzemeltetői eszközökkel.

Teljesitménynövelés Az egyszerűbb funkció a tömörítés, azaz a compression. Ezzel a funkcióval a szervertől a böngésző felé menő forgalmat csökkenthetjük azáltal, hogy a kiszolgáló átküldés előtt tömöríti az átküldendő adatokat, amit a böngésző automatikusan kitömörít. A háttérben ez úgy valósul meg, hogy a kliens egy Accept-Encoding fejléc átküldésével jelzi a szervernek, hogy képes tömörített válasz feldolgozására. Az IIS 7-ben a statikus állományok tömörítése alapértelmezés szerint be van kapcsolva, a dinamikus állományokra (.aspx, .php stb.) pedig külön engedélyezhetjük a tömörítést. A grafikus felületen nincs lehetőség a funkció finomhangolására (például a tömörítés fokának a megadására), azt közvetlenül az applicationHost.config állományban tehetjük meg a system.webServer/httpCompression elemben.

A másik teljesítményfokozó funkció a gyorsítótárazás, azaz a kiszolgáló oldali cache használata. Ezzel a funkcióval a webkiszolgáló képes a statikus fájlokat vagy a generált oldalak HTML kódját memóriában tartani és így elkerülni azok ismételt felolvasását a diszkről, illetve szükség esetén a fordítását és futtatását. Az IIS 7 bizonyos körülmények között akár kernel szintű gyorsítótárazásra is képes, amely jelentős teljesítmény növekedést eredményez. Az IIS Manager grafikus felületén akár kiterjesztés szerint megadhatjuk, hogy mennyi ideig próbálja a rendszer gyorsítótárban tartani a fájlt, valamint megadhatjuk azt is, hogy különböző fejléc mezők (pl. Accept-Language) vagy query string értékek szerint több változat is gyorsítótárba kerüljön.

Demó

Tömörítés és gyorsítótárazás - Kattints ide a demó videó megtekintéséhez Lejátszáshoz kattints a képre

Letöltés: Teljesitmeny.wmv (19:04, 94.8 MB)

Első lépések

Ahhoz, hogy a tömörítés és a gyorsítótárazás működjön, telepítenünk kell a Performance, a Static Content Compression és a Dynamic Content Compression modulokat. Ezek után az IIS Managerben az Output Caching és a Compression menüpontok alatt tudjuk bekapcsolni ezeket a funkciókat.

Jó tudni

A tömörítés jelentős processzor terhelést generálhat a szerveren, melynek finomhangolására system.WebServer/httpCompression ágban számos opciót találunk. Ezeket a paramétereket csak a konfigurációs állományban módosíthatjuk, nincsenek kivezetve a felhasználói felületre.

A gyorsítótárazás bekapcsolása után nem kerül minden fájl automatikusan a cache-be, az IIS 7 meghatározza, hogy melyek azok a fájlok, amelyek célszerű memóriában tartani. Alapértelmezés szerint ehhez az szükséges, hogy az adott állományt 10 másodpercen belül legalább kétszer kérjék le a kliensek. Ezek a beállítások a system.WebServer/serverRuntime ágban található frequentHitThreshold és frequentHitTimePeriod attribútumokkal módosíthatóak.

További információk