Siin lehel kirjutan oma diplomitööd. Alustan 19.märtsil probleemi kirjeldusega.

Olemasoleva olukorra ja probleemi kirjeldus

Järgnevalt antakse lühike ülevaade Eesti Rahvusringhäälingust ja olemasolevast lahendusest

Eesti Rahvusringhääling

Ilus organisatsiooni skeem
Eesti Rahvusringhäälingu moodustavad kaks tele- ja viis raadioprogrammi, millele lisanduvad juurde veel mitmed uudiste- ja teemaportaalid. Organisatsioon hakkas sellisel kujul tegutsema 1. juunil 2007, kui ühendati Eesti Raadio ja Eesti Televisioon. Viimast esindavad ETV ja ETV2 ning raadiod Vikerraadio, Klassikaraadio, Raadio 2, Raadio 4 ja Raadio Tallinn.

Missiooniks on arendada ja hoida Eestit ning selleks kaasatakse inimesi Eesti riigi ellu, innustatakse vaba arutelu, edendatakse loomingulisust ja tegusust. Luuakse teabevõrgustik kõigi Eestiga seotud inimeste vahel kogu maailmas, oma programmides avardatakse Eesti inimeste maailmapilti, haritakse avalikus mõtteruumis osalejaid, väärustatakse inimeste isiklikku elu ja perekonda, kaitstakse eetilisi põhiväärtusi.

Raadio-ja teleprogrammide kõrval mängivad olulist rolli missiooni täitmisel ka Eesti Rahvusringhäälingu internetiportaalid. Näiteks on antud organisatsioon loonud ainsana inglise keelse portaali, mis kajastab Eestit. Samuti tehakse seda ka vene keeles. TNS-i Emor andmetel oli Rahvusringhäälingu portaalide lugejaskond 2010. aasta lõpul enam kui 165 tuhat lugejat nädalas. Eesmärk on olla viie esimese ajakirjanduslikku sisu pakkuva portaali seas.

Samuti on loodud võimalused jälgimaks kõiki tele- ja raadioprogramme otsesaateid üle maailma läbi interneti, et olla Eestis toimuvaga kursis. Praegu tegeletakse sellega, et tuua otsetoodang ka mobiili ja inimesed saaksid programme jälgida sõltumata seadmetest. Internetis saavad oluliseks ka ineteraktiivsed keskkonnad ja sotsiaalvõrgustikud.

Portaalide arendus ERR'is

ERR'is tegeleb portaalide arendusega portaalide arenduse üksus. Ametikult loodi see 1. jaanuar 2010. Praeguse hetkel kuuluvad meeskonda ametlikult 3 arendajat ja veebiarendusjuht. Eelnevalt vastutas arenduse eest üks inimene. Kõik uued portaalid luuakse hetkel ASP.NET 4 platvormil, millega paralleelselt toimub vanema versiooni ASP.NET portaalide üle toomine uuemale versioonile. Lisaks .NET raamistikku kasutavatele portaalidele on kasutusel hetkel veel ka PHP lahendusi, millele ei tehta enam väga suuri juurdearendusi, vaid pigem tegeletakse haldamisega.

PHP tehnoloogial portaalid Eesti Rahvusringhäälingus

PHP portaalide haldusega tegeleb praegu täiskohaga üks inimene. Räägi ka miks ja kuidas need on tekkinud

PHP4 tehnoloogial arendatud portaalid

etv.err.ee - ETV kanali portaal, võimalik jälgida tagantjärele saateid ja nende uudiseid.
uudised.err.ee - uudiste portaal.
ilm.err.ee - ilma portaal.
meieoma.ee - lastele mõeldud portaal.

PHP5 tehnoloogial arendatud portaalid

Millal tekkinud, kas arendatatakse edasi, mis on plaanid nendega

pood.err.ee - võimalik osta ERR toodangut.
Raadioportaalides on võimalik lugeda nendega seonduvaid uudisedeid, kuulata saateid arhiivist ja ka otse.

vikerraadio.err.ee
r2.err.ee
r4.err.ee
raadiotallinn.err.ee
klassikaraadio.err.ee

teadus.err.ee - teadus- ja haridussaadete portaal.
raadioteater.err.ee - võimaldab kuulata vikerraadios esitatud kuuldemänge ja järjejutte.

ASP.NET platvormil portaalide arendus Eesti Rahvusringhäälingus

Miks? Kes?Kus? Kuidas?

ASP.NET 2.0

err.ee -Eesti Rahvusringhäälingu keskportaal.
om.err.ee - Taliolümpiamänge kajastav portaal.

ASP.NET 4.0

news.err.ee - Eestit kajastav ingliskeelne uudiste portaal
eestilaul.err.ee - Eesti Laulu ja Eurovisiooni kajastav teemaportaaal
otse.err.ee - Portaal, mis võimaldab jälgida ERR'i tele-ja raadiotoodangut reaalajas.
valijakompass.err.ee - teemaportaal mis aitas võrrelda inimestel enda seisukohti erakondade omadega.
koolifilm.err.ee - koolifilmi konkurssi läbiviimiseks loodud portaal
rus.err.ee - Eestit kajastav venekeelne uudisteportaal.
retseptid.err.ee - portaal, kuhu lisatakse eetris olnud retsepte.
kodanik.err.ee -
jalgpall.err.ee - Portaal, mis kajastas jalgpalli MM 2010't
ring.err.ee - ERR portaalide registreeritud kasutajate..
etv2.err.ee - kajastab ETV2'ga seotud uudiseid/üritusi.

Probleemi kirjeldus

Teise põlvkonna ASP.NET portaalide jaoks loodud lahendus valmis kiirustades, kuna selle valmistamine toimus äärmiselt piiratud ajaraamis ja tööjõudu selle projekti tarvis oli vähe. Seetõttu puudus oodatava süsteemi põhjalik eelanalüüs. Rakenduse loomiseks kasutati töövõtteid, mis kiirendasid küll selle valmimise kiirust, kuid paratamatult kannatas selle all rakenduse kvaliteet (sh jõudlus). Ametlikku kasutuselevõttu eel ei olnud võimalik, tulevenalt ajaraamist, teha süsteemile täielikke jõudlusteste, mis näidanuks selle toimimist suurte koormuste korral. Teise põlvkonna ASP.NET portaalide mootori valmimise hetkel hakati seda lahendust kasutama vaid ühe portaali piires. Hiljem lisandus sellele platvormile täiendavaid portaale ning jõudluse küsimus muutus seepärast aktuaalseks.

Arendusmeeskonda on lisandunud noori programeerijaid, kes ei ole piisavalt teadlikud kuidas tagada korraliku koodikvaliteeti. ASP.NET lahendusi on küll võimalik pealtnäha kiiresti ja kergelt luusa, kuid kasutades valesid tehnoloogiaid ning töövõtteid ja jättes optimaalse ressursikasutuse jälgimise tagataustale, mõjub see rakenduse jõudlusele negatiivselt.

Poole aasta jooksul on lisandunud uusi .NET portaale, milledest enamus kasutab eelpool mainitud lahendust. Viimasel ajal on esinenud suurte koormuste korral märgatavaid jõudlusprobleeme. Üheks põhjuseks on kindlasti asjaolu, et kõiki .NET portaalide haldamiseks on kasutada ainult üks server. Ehk kui üks portaal hakkab kasutama väga palju ressurssi, siis mõjutab see ka teiste veebirakenduste tööd. See on kindlasti hetkel ka üheks turvanõrkuseks - leides ühel leheküljel ressursinõudliku protseduuri, saab seda kasutada kõikide Eesti Rahvusringhäälingu ASP.NET portaalide töö häirimiseks. Halvimal juhul lõpeb see serveri töö seiskumisega. Serveripargi jõudluse parandamiseks on täiendavad investeeringud riistvarasse hetkel välistatud. Kuna organisatsioon tegutseb internetimeedia turul ja laieneb sellel pidevalt, siis häired veebirakenduste töös mõjuvad mainele negatiivselt ning on oht kaotada külastajaid.

Lähiajal on lisandumas antud serverile veel kaks täiesti uut portaali. Lisaks peavad hakkama mõned esimese põlvkonna portaalid kasutama "uut mootorit", üheks neist on sport, millele on oodata suurt külastajatearvu. Arvestades asjaolu, et juba praegu esineb jõudlusprobleeme, tuleb enne parandada olemasoleva lahenduse jõudlust.

Antud peatükis andis autor ülevaate konkreetse organisatsiooni probleemi tekkimise põhjustest, lisaks käsitleb peatükis 2.3 "Optimeerimisest üldiselt" jõudlusprobleemide esinemist laiemalt.
See osa on selgelt liiga lühike Võimalik viide, et probleemi aktuaalsust üldisena käsitleb autor peeatükis see ja see

Metoodika valik ja võimalikud lahendused

Selles peatükis selgitab autor töös kasutatavat metoodikat ning annab ülevaate käsitletava teema valdkonnast üldiselt....

Metoodika

Lahenduse leidmiseks teostab autor teoreetilise uuring kasutatakse olemasolevate materjalide analüüsi ning seejärel koostab olemasolevate rakenduste optimeerimise kava. Lõputöö käigus tutvutakse parimate praktikatega ja valitakse välja neist sobivaimad. Valiku tegemisel hinnatakse sobivust olemasoleva lahendusega. Kui valik on teostatud mõõdetakse praeguse lahenduse töökiirust. Peale seda võetakse kasutusele leitud optimeerimisvõimalused, mida rakendatakse kõigepealt testserveris, millele järgnevad uuesti mõõtmiseid. Võrreldakse saadud tulemusi ja tehakse järeldus. Eelistatud on Microsofti enda poolt soovitatud lahendused. Miks?

ASP.NET veebirakenduse põhikomponendid ja töötsükkel

Optimeerimisest üldiselt

Tänapäeval on jõudlusprobleemid väga aktuaalsed, kuna IT-lahendused ning nende funktsionaalsute maht kasvab ajas kiiresti ning populaarsete veebirakenduste kasutajate hulk võib ajas eksponentaalselt kasvada. Kui veebirakendused on optimeerimata, siis võib kasutajate hulga lisandumine põhjustada halvimal juhul rakenduse töö katkemise või mitteootuspärase kasutajakogemuse.

Tihti häirivad optimeerimata veebirakenduste tööd jõudlusprobleemid. Viimased kerkivad esile, kui süsteemile kasvab koormus ning tihti on nende tekkimist raske prognoosida. Olukorra iseloomustamiseks võib näite tuua liikluses: kell 4 öösel tööle sõit võtab alati vähem aega, kui seda teha hommikusel tipptunnil, teisalt võib juhtuda, et hommikul kell seitse toimub mõni oluline tähtsündmus ning öösel kell 4 on ootamatult tekkinud ummikud, kuna valgusfoorid ei tööta, aga liikluskoormus on suur. Nii võib juhtuda, et veebirakeendusel, kus tavapäraselt on paartuhat külastajat päevas, kasvab ühel päeval kasutajate hulk kümnetes kordades, kuna rakendusele tegi reklaami mõni meeldiakanal või populaarne sotsiaalmeedia kasutaja.

Sellised näited on EERi kogemuses näiteks otse.err.ee portaalis, kus mõne aktuaalse sündmuse ajal võib kasvada kasutajate hulk järsult kümnetes kordades. Varasemalt on seda juhtunud eurovisiooni ja spordiülekannete puhul, mille tulemusena käitus leht mitteootuspäraselt.

Kuidas seda vältida? Parem kirjuta vormis: selle vältimiseks saab kasutada...
Sellise olukorra vältimiseks on alati kõige lihtsam juurde soetada riistvara, mis annab omakorda juurde rohkem jõudlust. See on õigustatud ainult juhul, kui on kindlaks tehtud, et süsteem on juba optimeeritud ja olemasolevate vahenditega pole seda enam võimalik parandada. Vastasel juhul on tegemist probleemi ajutise peitmisega, mitte lahendamisega. Lisaks kulutatakse nii ebaotstarbekalt rahalisi vahendeid. Seega tuleks alati alustada probleemi lahendamist olemasoleva lahenduse analüüsiga ja võimaluse korral optimeerimisega.

Süsteemi tuleb alati vaadata kui tervikut. Näiteks veebileht ei koosne ainult koodist, mis kirjutab välja vajalikke asju. Seda infot tuleb käia kuskilt pärimas - andmebaasist. Lehe reserveerimise eest vastutab aga server. Ükskõik millise eelpool mainitud osa halvasti töötamine mõjutab teisi. Parandades ühte osa, paraneb enamasti ka üldine jõudlus, kuid maksimaalse kasutegerui saavutamiseks tuleb vaadata rakenduse kõiki osasid. Edukalt probleemide lahendamisel võib nii vältida täiendava riistvara soetamist ja tagada parema süsteemi töökindluse.

Enne optimeerimise alustamist tuleks veenduda, et plaanitav muudatus on vajalik ning see toob kaasa endaga jõudlusekasvu. Näiteks, kui kulutada kaks päeva andmebaasipäringu optimeerimiseks, mida tehakse kord aastas ja sellega võidetakse paar millisekundit, siis tegelikkuses on kaotatud 2 väärtuslikku tundi. Lisaks tasub jälgida, milliseid muudatusi toob tehtva muudatus kaasa olemasolevas lahenduses, kuna muutus, mis muudab koodi loetamatuks ja selle silumise raskeks ei pruugi olla alati õigustatud.

Antud lõputöö raames vaatleeb autor eelkõige enimkasutatavaid ja suuremat jõudlusvõitu tagavaid võtteid ASP.NET veebirakenduse optimeerimiseks ning seda, kuidas neid olemasolevates ja ka uutes ERRi portaalimootorites rakendada. Tuuakse välja ka võimalused, kuidas mõõta erinevate rakenduse osade töötamiskiirust, millele tuleks selle juures tähelepanu pöörata ja milliseid muudatusi see endaga kaasa toob. Lisaks luuakse dokument, mida saab kasutada uute loodavate lahenduste varajaseks optimeerimiseks tulevikuks. Eeludseks on, et tegemist on .NET 4 raamistikuga ja andmebaasina kasutatakse SQL Server 2008 väljaannet, kuna need on antud töö aluseks.

Andmebaasi optimeerimine

Siia pigem jutt, miks on andmebaaside optimeerimine rakenduse optimeerimise seisukohast oluline
Mõiste "Andmebaas" defineerib wikipedia järgnevalt:"Andmebaas on korrastatud infokogum." http://et.wikipedia.org/wiki/Andmebaas Sellest vajaliku osa näitamise eest lõppkasutajale vastutab enamasti rakendus, mis pärib seda andmebaasist. Järelikult võib väita, et sellise rakenduse töö sõltub lisaks muule ka andmebaasist. See tõttu on viimase kiire ja optimaalne töötamine prioriteetne, kuna aeglane andmete leidmine ei mõjuta ainult andmebaasi enda tööd, vaid ka rakendust. Kui andmebaasi päringute täitmine võtab palju aega, peab rakendus ootama vajalike andmete järel, enne kui saab oma tööd jätkata.

Antud peatüki eesmärgiks on kirjeldada võimalusi andmebaasi optimaalse töö tagamiseks, lisaks peab autor vajalikuks kirjutada ka selle loomisest, kuna materjalide analüüsist selgus, et andmebaasi optimaalse töö tagamisel mängib väga suurt rolli ka selle disain. Halva arhitektuuriga andmebaaasi on väga keeruline optimeerida.

Microsoft SQL Server 2008 andmebaasimootori väljaanded ja nende funktsionaalsuste erinevus

Microsoft SQL Server 2008 on 6 erinevat väljaannet: Express, Workgroup, Web. Standard, Enterprise ja Datacenter. Antud nimekirja järjestus baseerub litsentside hinnal, milles kõige esimene on Express versioon. See on tasuta ja kõige väiksema funktsionaalsuse ning võimalustega. Töö käigus kasutas diplomitöö autor Standard väljaannet. Selle peatüki eesmärgiks on lühidalt võrrelda ja kirjeldada erinevate väljaannete funktsionaalsust lähtuvalt jõudlusest.

Tabelite ja indeksite partitsioneerimine (Table and index partitioning) - võimaldab tabelid või indeksid jagada väiksemateks osadeks. See on kasulik suure hulga andmete puhul, sest sellest väiksema osa läbi vaatamine võtab ka vähem aega ja ressurssi. SQL Server 2008 Bible 1428

Indekseeritud vaated (Indexed views) - tavalised vaated on virtuaalsed tabelid, mis luuakse alati iga päringu ajal uuesti. Indekseeritud vaadete puhul shs hoitakse päringu tulemusi tabelina andmebaasis. Lisaks sellel suudab päringuoptimeerija(query optimizer) loodud vaadet kasutada päringute täitmiseks ilma, et seda peaks FROM klauslis eraldi kirjeldama.
http://msdn.microsoft.com/en-us/library/ms187864.aspx

Andmete tihendamine(Data Compression)- võimaldab tihendada tervet kuhja(heap), klasterdatud indeksit, klasterdamata indeksit, indekseeritud vaadet ja üksikut tabelit või indeksi partitsiooni. Näiteks mahub seetõttu lehtedele rohkem ridu ja kirjete läbi vaatamine toimub kiiremini. Peab arvestama, et kõik andmed ei kompresseeru hästi ja lisaks mõjutab see protsessori jõudlust. (SQL Server 2008 Bibile lk 1416)

Ressursi haldur (Resource governor) - tööriist, mille abil saab määrata erinevatele päringutele ressursipiirangud ja limiidid. Kasulik olukorras, kus suur ja väikeseprioriteediga päring, kasutab palju ressurssi. Saab peale panna maksimaalse protsessori kasutuse piiri. Nii võtab selle päringu täitmine küll rohkem aega, kuid ei sega muude päringute täitmist. http://msdn.microsoft.com/en-us/library/bb895232.aspx

Parallel index operations - http://msdn.microsoft.com/en-us/library/ms191292.aspx

Parallel consistency checks (DBCC) - võimaldab andmebaasi käsurea päringuid täita paralleelselt.

Enhanced read-ahead scan -

-	Express	Workgroup	Web	Standard	Enterprise	Datacenter
Protsessorite arv	1	2	2	4	8	Operatsioon süsteemi maksimum
Maksimaalne mälukasutus	1GB	4GB	64GB	64GB	2TB	Operatsioon süsteemi maksimum
Maksimaalne andmebaasi suurus	10GB	524PB	524PB	524PBB	524PB	524PB
Tabelite ja indeksite partitsioneerimine	Ei	Ei	Ei	Ei	Jah	Jah
Indekseeritud vaated	Ei	Ei	Ei	Ei	Jah	Jah
Andmete tihendamine	Ei	Ei	Ei	Ei	Jah	Jah
Resource governor	Ei	Ei	Ei	Ei	Jah	Jah
Parallel index operations	Ei	Ei	Ei	Ei	Jah	Jah
Parallel consistency checks (DBCC)	Ei	Ei	Ei	Ei	Jah	Jah
Enhanced read-ahead scan	Ei	Ei	Ei	Ei	Jah	Jah
Täistekstiotsing	Ei	Jah	Jah	Jah	Jah	Jah

Andmebaasi loomine

Andmete hoiustamiseks andmebaasis, tuleb see enne luua. Selle protsessi käigus tehtud otsused mõjutavad väga palju tulevikus jõudlust ja ressursikasutust. Algfaasis tehtud valed valikud mõjuvad halvasti nii andmebaasi kui seda kasutavale rakenduse kiirusele. Oluline on andmebaasi loogiline ülesehitus, kuid tähelepanu tuleb pöörata ka kindlasti veergude definitsioonidile, mis tuleb määrata korrektselt ja loogiliselt. Näiteks reaalarvulised väärtused peavad olema reaalarvu tüüpi, tekstina neid hoides raisatakse ressurssi ning andmete lugemisel peab neid üldjuhul kasutamiseks teisendama vajalikku vormingusse. Samuti tuleb veerutüüpide loomisel alati läbi mõelda, kui täpseid andmeid nõutakse. Lihtne näide selle kohta on kuupäevad, mida kasutatakse alati väga palju. Näiteks registreerimaks uue sissekande loomise kuupäeva. Tihti kasutatakse andmebaasis kuupäeva tüübiks automaatselt DateTime, mis võtab ruumi 8 baiti ja täpsuseks kolm millisekundit. Kuid enamasti ei ole selline täpsus vajalik ning väiksema täpsusega andmete hoiustamiseks ja töötlemiseks kulub vähem ressursse. Samas on olukordi, kus väärtuste suur täpsus on kriitiline, kuid kindlasti leidub rohkem situatsioone, kus piisab ka väiksemast täpsusest.

Näiteks uudisteportaalides on uudiste avaldamisajad tihti märgitud ainult kuupäeva koos kellaajaga, mis on minutitäpsusega. Viimase jaoks on sobiv SmallDateTime, mis on minuti täpsusega ja lisaks võtab poole vähem ruumi (4baiti). Lisaks on sellisel juhul olemas vajalikus vormingus kuupäev ning seda ei pea hakkama veebirakenduses andmete väljaküsimusel ümber hakkama vormindama.

Andmebaasi loomisel tuleb säilitada paindlikus. Näiteks tabelis võtab tinyint primaarvõtme väljana 4 korda vähem ruumi võrreldes Int tüüpi veeruga, kuid sellesse tabelisse saab luua see tõttu ka 256 sissekannet.

Samasuguseid näiteid leidub kõigi andmetüüpide kohta. Seega peaks enne tabelite loomist ja veergude tüübi määramist tutvuda konkreetse andmebaasimootori dokumentatsiooniga ja analüüsida, milliseid võimalusi võimalused on olemas. Näitena võib tuua eelpool mainitud kuupäevade tüübi valimise, kuna SmallDateTime on saadaval alates SQL Server 2008 versioonist.

Kordumatute väärtustega väljad andmebaasides

Andmebaasi loomisel tuleb otsustada, millist tüüpi on primaarvõtme veerud. Tihti on nendeks INT või uniqueidentifier. Esimene neist esindab täisarvulisi arve ja teise puhul on tegemist kordumatute väärtustega, mis on 16 baidised globaalsed identifikaatorid (GUID- Global Unique IDentifier). Need esitatakse kujul xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, kus iga x tähistab üht tähte või arvu kuueteistkümnendsüsteemist.
Siia selgitus, milleks sellised väljad andmebaasides üldse kasutusel on ning mis on INT ja mis GUID

Arvestades kui palju kordumatu väärtusega identifikaator ruumi võtab, võrreldes täisarvuga, võib selle kasutamine tunduda ebaratsionaalne. Siiski on sellel täisarvu ees ka mõned eelised: see on alati unikaalne, kuid täisarv on unikaalne ainult ühes tabelis, lisaks on selle kasutamisega välistatud võimalus, et relatsioonilises andmebaasis viiakse omavahel kokku tabelite veerud, mis tegelikult ei ole seotud. Lisaks ei saa GUID kunagi otsa, kuid täisarvulise tüübi kõige suurem väärtus on 9 223 372 036 854 775 807, kui tegemist on bigint 'iga ja sellel juhul võtab see ruumi 8 baiti. [1]

Üheks kordumatu väärtusega välja puuduseks on see, et selle kasutamine võib vähendada klasterdatud indeksiga saavutatud jõudlusevõitu, kui genereerida see automaatselt. Iga uus sissekanne nõuab indeksite uuendamist ja seetõttu võib selle kasutamine kutsuda esile indeksi lehtede poolitusprobleeme ja nende fragmenteerumist, kuna loodud võtme väärtus ei pruugi olla viimane ja sellele tuleb leida õige koht. See nõuab aga kõigi seniste võtmete uuesti sorteerimist. Alates SQL Server 2005 versioonist saab selle vältimiseks kasutada funktsiooni NewsequentialID(), mis tagab, et iga järgmine globaalne identifikaator on eelmisest suurem. Seega ei tule uus sissekanne mitte indeksite lehe keskele, vaid läheb alati viimaseks. Tuleb arvestada ka asjaoluga, et kuna see kasutab rohkem mälu, siis tekib indekseerimisel rohkem lehti ja nende uuendamine on kulukam kui täisarvulise tüübi puhul.

Päringute analüüs

Kirjete lisandumisel andmebaasi kasvab selle suurus ja ka päringute täitmiseks hakkab kuluma rohkem aega. Mingil ajahetkel võib tekkida situatsioon, kui andmete leidmiseks kulub liiga palju aega. See on aga selge märk sellest, et tehtavaid päringuid tuleks analüüsida ja seejärel optimeerida.

Alljärgnev päring aitab otsustada, millised päringuid andmebaasis võivad vajada optimeerimist.

-- alljärgneva päringuga saad lugeda protseduur cache'i sisu
-- saadav tabel sisaldab küllalt infot otsustamaks, millised protseduurid või päringud kulutavad serverit

SELECT sql.text, qs.EXECUTION_COUNT, qs.*, p.* 
FROM sys.dm_exec_query_stats AS qs 
CROSS APPLY sys.dm_exec_sql_text(sql_handle) sql
CROSS APPLY sys.dm_exec_query_plan(plan_handle) p
WHERE text NOT LIKE '%sql.text%'
ORDER BY 

-- vali ise mis järjekorras sa vastust tahad
--qs.total_worker_time desc  -- kulutatud aja järgi
qs.EXECUTION_COUNT DESC  -- täitmiskordade järgi
--qs.max_elapsed_time DESC  -- maksimaalse kestuse järgi

--vajaduse saad protseduur cache'i puhastada
--CHECKPOINT				--writes dirty pages to disk
--DBCC FREEPROCCACHE		--clears entire plan cache

--NB! Viimases veerus saadud tabelis on XML kujul Query Plan
--Salvesta see laiendiga sqlplan ja ava Management Studios - ja imesta :)

(http://www.sarv.ee/ftp/henn/SQL/Proc%20cache%20statistika.sql)

Selle abil saab sorteerida SQL päringuid kolmel erineval viisil:

täitmiskordade arvu järgi
päringu täitmiseks kokku kulunud aeg
päringu täitmiseks kulunud kõige suurem aeg.

Head kandidaadid on päringud, mida täidetakse kõige sagedamini, sest nende parandamine annab tihti lõppkokkuvõttes suurema võidu. Näiteks, olgu meil kaks päringut,milledest esimest täidetakse päevas kümme ja teist tuhat korda. Optimeerides neist esimest, paraneb kiirus ühe sekundi ja teise puhul saja millisekundi võrra. Kogu ajaline võit ühe päeva kohta on aga tegelikult vastavalt kümme sekundit ja poolteist minutit.

Konkreetse päringu analüüsimiseks saab kasutada SQL Serveri päringu täitmisplaani (Query Execution Plan). See näitab graafiliselt, kui palju mingi päringu täitmine aega võtab ja milliseid operatsioone selle käigus läbi viiakse. Kuvatavat plaani tuleb lugeda paremalt vasakule ja see lihtsustab päringus probleemsete kohtade leidmist.

Päringute optimeerimine

Info saamiseks andmebaasist tehakse päringuid, kus vastavalt seatud tingimustele väljastatakse neile vastavad kirjed. Nende loomisel tuleks jälgida mõningaid lihtsaid võtteid, et vältida üleliigset ressursi raiskamist.

Kirjete pärimisel peab alati kirjeldama, milliseid veerge soovitakse selle tulemusena saada. Näiteks SELECT *(vali kõik veerud) mõjub jõudlusele negatiivselt: kui tabelis on kümme veergu, kuid vaja läheb neist ainult kahte. Sellisel juhul on tegemist ebavajaliku ressursiraiskamisega kahel põhjusel: 1)andmebaas saadab rakendusele rohkem infot kui vaja, 2) muudab indekseerimise keeruliseks.

Tingimuste kirjutamisel tuleks alati küsida seda, mida tahetakse. Mitte vastupidi.

Kõiki päringuid peaks hoidma andmebaasile võimalikult lähedal, kuna nii saadakse neile ka kiirem vastus ja need asuvad andmetele lähemal võrreldes rakendusega.

Talletatud protseduurid

Talletatud protseduurid on põhimõtteliselt kogum juba varem valmis kirjutatud SQL päringuid, mis on koondatud üheks hallatavaks blokiks. Igat loodud protseduuri kompileeritakse (toimub automaatselt) ühekorra ja peale seda luuakse päringu täitmise plaan, mida hoitakse mälus. Edaspidi võetakse päringu täitmiseks see plaan juba mälust ning seetõttu on ka nende täitmine kiirem. http://www.tech-faq.com/stored-procedure.html + SQL Server Bible(Lk 610)

Kas peaks siia hoopis loetelu tekitama? Nagu punkt1..punkt2.. punkt3
Hästi kirjutatud protseduurid on väga kiired, kuna nad asuvad andmete lähedal. Neid on lihtne testida ja hallata võrreldes veebirakendustes loodud päringutega. Talletatud protseduurid on turvalised, kuna kasutavad parameetreid, mis antakse neile kaasa ja nii kaob SQL injektsiooni oht. Rakenduse loojatel on samuti lihtsam kutsuda välja protseduur, mille sisendiks antakse parameetrid, kui kirjutada seda päringut veebirakenduses. SQL Server Bible (607)

Kasutades protseduure on lihtsam jälgida päringute täitmist ja ajakulu, võrreldes tavalise SQL päringuga, mis tuleb väljaspoolt andmebaasi. Kuna talletatud protseduuri väljakutsumiseks antakse kaasa ainult parameetrid, siis on ka edastatav andmemaht väiksem.

Kirjutades protseduure on hea praktika lülitada COUNT välja kasutades käsku

SET NOCOUNT ON

. Viimasega võib sõltuvalt päringu keerukusest võita kuni 17% selle täitmise kiirusest. Vaikimisi on NOCOUNT välja lülitatud ja seetõttu saadetakse päringu tulemusele kaasa ka alati kirjete arv, mis selle tulemusena leiti. ( SQL Server 2008 Bible ..622 ).

(LK

Lisaks tuleks vältida kursoreid. Kuigi nad on väga paindlikud ja võimaluste rohked, tuleb nende kasutamisel maksta ränka hinda jõudluses. Kui neid kasutatakse protseduurides, siis optimeerimiseks tuleks alustada nende eemaldamisest.
Kas võin tuua näite SQL Server Bible'st?

Indekseerimine

Indekseerimine on nagu raamatu sisukord. Kui soovitakse leida vajalikku infot, vaadatakse eelkõige sisukorda ning leitakse õige koht. Samamoodi käiakse pidevalt andmebaasist infot pärimas. Tabel ilma indeksita on nagu raamat sisukorrata - millegi leidmiseks peab lehitsema läbi terve raamatu, et leida õige koht, mida otsitakse. Loomulikult on see ajaliselt kulukas protsess. Kui andmebaasis on tabelid õigesti indekseeritud toimub otsimine nagu raamatu sisukorrast (kiiresti).

Indekseid on kahte tüüpi - klasterdatud ja klasterdamata. Klasterdatud indekseerimiseks on ideaalsed väljad tabelite primaarvõtmed kahel põhjusel: 1) see väli on alati unikaalne 2) infot otsitakse tihti selle võtme järgi. Vaikimisi luuakse primaarvõtme veerule alati klasterdatud indeks. Selle loomiseks käsitsi tuleb kasutades SQL lauset:

CREATE UNIQUE CLUSTERED INDEX index_id ON TABLE (veeru_nimi)

Tabeliveerg, millele see luuakse, peab olema alati unikaalne.

Mitte klasterdatud indekseerimise puhul ei pea väli olema unikaalne. Luuakse lausega: <source="sql"> CREATE INDEX voti ON tabeli_nimi(veeru_nimi)</source>. Sellest on ainult siis kasu, kui me valime ainult konkreetse välja, mis on klasterdamata indeksisse määratud. Kui lisaks sellele on vajalik valida veel välju, tuleks kasutada kaetud indekseerimist ning lisada vajalikud väljad. Selleks tuleb kasutada lauset:

CREATE INDEX v0ti ON tabeli nimi(veerg) include ( tabeli_veerg1, tabeli_veerg2,..).

Sobib eriti veergudele, kus kasutatakse GROUP BY, COUNT(*) päringuid.

Indekseerimiseks ei sobi väljad, mis on väga mahukad. Näiteks nVarchar(200), mis võtab palju ruumi ja indeksite loomine on mahukas protsess.

Indekseerides tabeli veerge ilma analüüsita, võib see mõjuda jõudlusele hoopis negatiivselt, kuna õigete ridade leidmiseks peab ikkagi tegema lisapäringuid. Selle vältimiseks tuleks jälgida päringu täitmise plaani, mis näitab, kuidas päringuid läbi viiakse ja kas loodud indekseid kasutatakse. Nii võib leida kohti, kus need on küll loodud, kuid küsitakse rohkem kirjeid kui indeksiga kaetud on.

Indekseerimisel tuleb arvestada sellega, et nende loomisel peab maksma natuke hinda ka jõudluses. Sellest tulenevalt tuleks kaasata indeksitesse minimaalselt välju. Mida rohkem on välju, seda kulukam on indeksite uuesti arvutamine, mis leiab aset iga DDL käsu puhul. Indeksite tabel koosneb lehtedest ja lisades uue sissekande tuleb lehed uuesti luua. Eriti halvasti mõjub see siis, kui uus sissekanne tuleb indeksi lehtede keskele. Viimane eeldab lehtede uuesti loomist ja nende poolitamist. Seetõttu tuleb hoolikalt kaaluda, kus kasutada rühmitatud indekseid.

Alates SQL Server 2008 versioonist on võimalik kasutada filtreeritud indekseerimist, mis tähendab, et klasterdamata indeksite loomiseks kasutatakse andmetest ainult mingit osa, mis vastab seatud tingimustele. Selle loomiseks on lause:

CREATE INDEX index_id ON tabeli_nimi(tabeli_veerg) WHERE tingimus

. Vajadusel saab ka siin kasutada kaetud indekseerimist.

Transaktsioonid

http://msdn.microsoft.com/en-us/library/ff647793.aspx#scalenetchapt14%20_topic9 Valesti kirjutatud transaktsioonid mõjuvad andmebaasi tööle negatiivselt. Selle vältimiseks on levinud praktikad: tuleks vältida pikki transaktsioone, kuna nende ajal toimub tabelis lukustamine. Soovitatav on valideerida enne transaktsioone juba rakenduses andmed, et vältida transaktsiooni ajal vigade tekkimist, mis pikedab neid. Lisaks ei tohiks transaktsioone alustada enne, kui kõik vajalikud andmed on olemas, kuna lukustus lõpeb alles siis, kui kõik andmed on saadetud. Halb näide on näiteks see, kui alustada transaktsiooniga, kuid selle edukaks lõppemiseks on vaja veel kasutaja poolt sisendit. Tabel on lukus seni, kuni kasutaja on sisendi andnud.

Ummik(Deadlock)on situatsioon, kus üks transaktsioon ootab teise ja teine esimese taga. Kindlasti tuleks sättida sellele aegumise piir, kuna vaikeseadetes võivadki need üksteise järgi põhimõtteliselt ootama jääda. Samuti tuleks sättida parallelism üheks. SQL Server Bible 1382.

Täistekstiotsing

Tihti on vaja lõppkasutajatele võimaldada info otsimist. Kuna enda otsingusüsteemi loomine on kulukas protsess, siis sobib seda asendama alguses SQL Serveri FullTextSearch funtsionaalsus. Viimast saab kasutada alates Standard väljaandest ning töötab indekseerimise põhimõttel. Antud funktsionaalsus pole mõeldud otseselt otsingumootoriks, kuid see on väga hea jõudlusega ning täidab igati oma põhiülesannet, hoides samal ajal ressursikasutuse madalana. Kindlasti tuleks seda eelistada algelisele otsingule, kus kasutatae LIKE operaatorit, mis on aeglane. Sama lahendus on kasutusel Eesti Rahvusringhäälingu .NET portaalide otsingusüsteemides.

Andmebaasi konfigureerimine

Parimate praktikate kohaselt soovitatakse jätta paljudele seadetele vaikimisi väärtused. Nii töötab server kõige optimaalsemalt ning nende muutmisel võib olla effekt jõudlusele hoopis negatiivne.

Startup Manager Kui soovida andmebaasist kätte saada maksimum, siis võib SQL Server Configuration Manager'is lisada Startup Parameters alla parameetri -x, mis võimaldab maksimaalselt jõudlust. Selllel on aga üks väga suur miinus. Nimelt lülitatakse kõik monitoorimisvõimalused selleks välja ja jõudlusprobleemide jälgimine ja otsimine muutub peaaegu võimatuks.

Ühenduste automaatne sulgemine(Auto Close) Ühenduste automaatse sulgumise korral vabastab SQL SERVER kõik selle andmebaasi ressursid, peale viimase aktiivse ühenduse sulgumist. Neid saavad kasutada teised andmebaasid. Pealtnäha tundub selline tegevus optimaalne, kuid tegelikult on see kindel viis, kuidas SQL Serveri töö hävitada. Paljud rakendused sulgevad ja avavad ühendusi korduvalt. Uute ühenduste tekkimisel tuleb uuesti laadida, kompileerida protseduurid ja arvutada päringu läbiviimise plaanid. See tõttu peaks ühenduste automaatne sulgemine olema keelatud, mis on ka kõigis SQL Serveri versioonides vaikimisiväärtuseks, välja arvatud SQL Express.

Ühenduste automaatset sulgemist saab kontrollida graafiliselt Management Studiost ja käsuga:

ALTER DATABASE <ANDBEMAASINIMI> SET auto_close ON/OFF.

See peaks olema lubatud ainult siis, kui tegemist on andmebaasiga, mis hoiab endas arhiivi ja kasutatakse väga vähe.

Automaatne kahanemine (Auto Shrink) Seda peab parandama.. Samuti peaks olema keelatud käsuga ALTER DATABASE <Andmebaasinimi> SET AUTOSHRINK OFF; Kui andmebaasil on üle 25% vaba ruumi, siis see põhjustab andmete ja logifailide kahandamise operatsiooni. Failide kahandamine on väga kulukas protsess.

ASP.NET tehnoloogiast tulenevad optimeerimisvõimalused

Konfiguratsioon

Konfiguratsiooni hoitakse web.config failis. Selle näol on tegemist infoga veebirakenduse seadistuse kohta. Näiteks: andmebaasiga ühenduse loomiseks vajalikud parameetrid või kuidas toimub rakenduse kompileerimine. ASP.NET kasutab selles failis olevat infot, et luua rakenduse ülesehitus.

Kui testkeskkonnas siluda rakendust, peaks kindlasti selles failis parameetri "compilation debug" väärtus olema true. Vigade esinemise korral on sel juhul neid lihtne leida. Veebirakenduse live serverisse tõstmisel peab jälgima, et silumine oleks kindlasti välja lülitatud. Vastasel juhul kompileeritakse pidevalt veebirakendust iga lehe laadimise ajal uuesti ja see omakorda kasvatab protsessori ja mälu kasutust. Kõige kindlam viis sellise olukorra vältimiseks on muuta serveris asuvat machine.config faili ja lisada parameeter deployment retail="true". Nii on kindel, et ükski veebiaplikatsioon ei kasuta antud serveris silumist. Ainukeseks miinuseks selle puhul on, et vea ilmnemisel ei kuvata vea täpset asukohta (rea numbrit ja veakirjeldust).

Lisaks tasub web.config faili lisada väljundipuhvri erinevad profiilid. Sellega saab määrata, kui kaua lehte serveri mälus hoitakse. Kui rakendusele on tulemas suur koormus, saab ühest kohast muuta kõikide väljundite kehtivuse pikkust, mis kasutavad konkreetset profiili.

Viewstate

Viewstate'i kasutatakse, et hoida väärtusi ASP.NET tööriistade (controls) objektide kohta. Lehe laadimisel genereerib ASP.NET ühe peidetud välja, mis kannab nime __VIEWSTATE, kus on see info sees. Nii on võimalik antud väärtuseid kasutada ka peale kliendi-serveri vahelist suhtlust, kui toimub tagasipostitamine (postback), mille kutsub esile näiteks nupulevajutus. Hoides selles aga suurel hulgal andmeid, kasvab seetõttu ka lehe suurus ning selle laadimise aeg. Arvestama peab ka sellega, et lehe laadimisel tuleb viewstate'is olevaid andmeid serialiseerida ja deseriaaliseerida. Lisaks võib see vähendada mäluhalduse GC) efektiivsust. Sellepärast tuleb selle kasutamisega olla ettevaatlik ja eemaldada kohtadest, kus seda vaja ei lähe, kuna see mõjub jõudlusele halvasti. Näiteks genereerivad kõige rohkem viewstate'i ASP.net enda tööriistad Listview ja Gridview. Lehel sisalduva viewstate'i hulga analüüsimiseks on hea tööriist ASP.NET ViewState Helper, mis töötab Firefoxi ja Internet Exploreriga. Selle abil on võimalik näha, kui suure osa moodustab kogu lehe suurusest viewstate.

Vaikimisi on see ASP.NET'is igal pool sisse lülitatud. Soovitatav on see välja lülitada kohtades, kus ei toimu serveri poolseid kontrolle ja ei kasutata tagasipostitamist (postback). Seda saab välja lülitada erinevatel tasemetel: serveris (machinge.config), veebirakenduses (web.config), lehel

<%@ Page EnableViewState="false" %>

kui ka ASP.NET tööriistades endas (EnableViewstate=false).

Kui lehel on lubatud viewstate ja toimub tagasipostitus (postback), siis tuleb seda kontrollida kasutades IsPostBack() meetodit. Viimane teeb kindlaks, kas tegemist on tagasipostitamisega (postback). Kui on, siis pole mõtet enam uuesti andmeid pärida, vaid kasutada juba olemasolevaid ja võtta need viewstate'is.

ASP.NET enda tööriistad

Enimkasutatavad tööriistad on tihti GridView, Listview ja Repeater. Neid kasutatakse tihti erinevate vaadete loomiseks. Esimesed kaks neist genereerivad suurel hulgal viewstate'i, sisaldes väga palju funktsionaalsust. Selle tõttu peab alati valima, milliseid tööriistu kasutada. Kui eesmärgiks on tavalise listi loomine (näiteks uudiste), siis peab kindlasti viewstate'i keelama ja kasutama võimalusel Repeater' it, kuna ListView funktsionaalsust tegelikult vaja ei lähe.

Nende kasutamisel tuleks tähelepanu pöörata väärtuste kuvamise viisile. Levinud on selleks kasutada võimalust:

<%#Eval("fieldname")%>

, mis defineerib välja nime, kuskohast väärtust päritakse. Seda on lihtne kasutada, olenemata sellest, kas tegemist on objektide listiga või DataTable'iga. Tegelikult tuleb sel juhul maksta hinda jõudluses, kuna küsitava välja tüüp ei ole tegelikult defineeritud ja selle kindlaks tegemiseks kasutatakse peegeldust (reflection). Nii tuleb 10 rea väärtustamiseks teha Eval operatsiooni tegelikult 20 korda, kuna esialgu pole teada, millist tüüpi andmetega on tegu. Parem variant on viidata kohe klassile, kust otsitav väli pärit on. Nagu näiteks:

<%#((MyClass)Container.DataItem).field1%> <!-----Klass----!> 
<%#((DataRowView)Container.DataItem).field1%>.<!---DataTable---!>

Ainuüksi 10 rea lisamisel võib kiiruse vahe olla enam kui kümnekordne, viimase variandi kasuks mõõdetuna ticksides. Selle kasutamisel peame arvestama, et muutes näiteks klassinime, peame muutma seda ka kohas, kus pärime välja väärtuseid.

ASP.NET genereerib automaatselt html'i kõikidele väljadele ID'd, kui need on ka koodis määratud. Näiteks kui meil on ASP.NET'i pildikomponent parameetritega

<asp:Image ID="imgMainItem" runat="server"/>

, siis sõltuvalt selle sügavusest lehtede hierarhias võib peale kompileerimist htmli vaadates näha, et antud välja ID'ks on saanud hoopis

id="ctl00_leftColumn_ctl00_Vaikekategooria3_imgMainItem"

. Tegemist üpriski mahuka nimetusega. Kui aga tegelikkuses seda id'd meil vaja ei lähe, siis peaks jätma selle määramata. Mahuka esilehe puhul on sellega võimalik hoida päris palju ruumi kokku. Kui siiski vajame ID'd, võime selle peale kasutamist ära nullida. Ehk näiteks:

//....
imgMainItem.Src="pilt.jpg"; 
imgMainItem.ID=null;
//....

Puhver

Andmete talletamine puhvris on üks lihtsamaid viise, kuidas muuta veebirakenduse ja ka andmebaasi tööd kiiremaks, hoides enimkasutatavaid ressursse mälus. Sellest andmete kättesaamine on lihtsam ja kiirem, kui selle pärimine pidevalt andmebaasist või kuskilt mujalt. ASP.NETis on kasutusel väljundi puhverdamisliides hoidmaks mälus objekte ning väljundipuhver, kus salvestatakse serveri mällu terve leht. Nende mõlema meetodi kasutamisel peab arvestama, et vajalike andmete/lehtede hoiustamiseks kasutatake serveri mälu. Seetõttu peab läbi mõtlema, mida on vaja mälus hoida ja mida mitte. Eriti siis, kui serveril on seda vähe. Head kandidaadid puhverdamiseks on lehed/andmed, mida kasutatakse kõige rohkem või mille kätte saamine on väga kulukas protsess. Enamasti on selleks näiteks esileht ja mõned suuremad listid ning otsingutulemused.

Väljundi puhverdamisliides ja väljundipuhver on küll kaks erinevat mõistet, kuid põhimõte on neil siiski sarnane. Mõlemale on võimalik ette anda aeg, kui kaua aega neid serveri mälus hoitakse. Lisaks saab mõlema puhul kasutada SqlCacheDepencyt, mis võimaldab jälgida, kas andmebaasitabelites on muudatusi toimunud. Mälust kustutakse andmed, kui jälgitavas tabelis toimub muudatus.Selle toimimiseks peab andmebaasis lubama tabelitel SqlCacheDependency ja ka web.config failis kajastama seda. Võimalus on kasutada ka mitme tabeli jälgimist. Soovitatav on vaadelda tabeleid, milles ei toimu tihti muudatusi. Vastasel juhul on puhver pidevalt tühi ja andmete saamiseks tuleb siiski päringuid teha. Sellisel juhul tuleks anda ajaline intervall, mille tagant andmeid uuendatakse. http://msdn.microsoft.com/en-us/library/system.web.caching.sqlcachedependency.aspx.

Väljundipuhver

Väljundipuhvri kasutamisel salvestatakse terve dünaamiliselt loodav leht serveri mällu. Peale seda kuvatakse seal olevat lehte. Seda saab kasutada nii terve .aspx lehtede salvestamiseks kui ka usercontrolide puhul. Väljundipuhvri jaoks tuleb lisada järgnev kood lehe ülaossa:

< %@ OutputCache Duration="60" VaryByParam="None" % >

Need kaks parameetrit on alati kohustuslikud. Kestvus(Duration) näitab kui pikka aega lehte serveri mälus hoitakse ja VarByParam parameetriks saab anda päringustringi(d). Lisaks on levinumad parameetrid veel:

Shared="true/false" - saab kasutada ainult usercontrollide puhul. Kui true, siis cache'itakse see kõikidel lehtedel.
CacheProfile="profiilinimi" - web.configis asuv outputcache'i profiil.
SqlDependency ="adnmebaasi/tabeli paar" - defineeritakse andmebaasi /tabeli paarid, mille muutumise korral leht serveri mälust kustutakse. http://msdn.microsoft.com/en-us/library/hdxfb6cy.aspx
VarByCustom ="nimi" - võimaldab kasutajal luua endal puhverdamise meetod

VaryByCustom'i, kasutamiseks tuleb Global.asax failis ülekirjutada GetVarByCstomString meetod: Näiteks:

public override string GetyVarByCustomString(HttpContext context, string custom){
		if(custom=="weekday"){
			return ....
		}else{
			return base.GetVarbyCustomString(context, custom)
		}
	}

ASP.NET ei hooli stringi tegelikust sisust, vaid kontrollib seda, kas vastav stringi väärtusega leht on juba serveri mällu salvestatud. Kui on, siis serveeritakse leht serveri mälust, vastasel juhul lisatakse uus lehe koopia mällu. Kas selle alumise möla peaks ära kustutama? Tegelikult ei ole üldse hea lahendus ju... Või mis? Olen seda saab kasutanud näiteks feedi cache'imiseks, mille loomine oli väga kulukas ja mida tohivad näha ainult teatud IP aadressitega kliendid. Tavalise OutPutCache'i lisamine on välistatud, kuna kui võõra IP'ga klient tuleb, näeb ta ikkagi feedi sisu, leht on serveri mälus ja outputcache'i puhul lehe eventeid ei käivtata. Teine halb asi, mis võib juhtuda on kui võõra IP'ga klient tuleb siis kui lehte pole veel serveri mälus.Sellel juhul aga läheb terve feed katki, kuna serveri mälllu salvestatakse leht, mis on tühi, kuna sel hetkl käis lehel keelatud IP'ga klient. Lahenduseks oli override'ida GetVarByCustomString meetod ja cache'ida leht IP põhiselt.

Väljundi puhverdamisliides

Cache API puhul ei hoita serveri mälus mitte tervet lehte, vaid soovitud väärtusi, mis lisatakse sinna koodifailis. Näiteks:

Cache.Insert("võti", "väärtus")

. Tihti on selleks list objektidest, DataTable või midagi muud sarnast. Lisamiseks kasutatakse võti/väärtus paari, millele saab lisaks kaasa anda aegumise intervall või sõltuvus andmebaasitabeli muudatustest (SqlCacheDependency).

Võimalikud parameetrid, mida Cache.Insert meetodi sisendiks saab kasutada on:

Insert(String, Object) - Lisab objekti mällu.
Insert(String, Object, CacheDependency) - Lisatakse objekt mällu ja arvestatakse Dependencyga nii faili kui andmebaasi puhul.
Insert(String, Object, CacheDependency, DateTime, TimeSpan) - Lisatakse objekt mällu koos aegumisreeglitega.

Selle abil saab vähendada väärtuste pärimiseks tehtavaid päringuid. Enne väljundipuhvrist informatsiooni välja võtmist, tuleb alati kontrollida, kas vastava võtmega on seal üldse midagi olemas, kuna vahepeal kustutakse serveri mälus hoiustatud väärtusi. See leiab aset näiteks juhtudkel, kui serveril on vähe mälu, objekt aegub või muutub dependency.

Kontrollida saab näiteks nii:

if(Cache[key]!=null){

}

http://msdn.microsoft.com/en-us/library/ms178597.aspx

.NET raamistiku vahenditest tulenevad optimeerimisvõimalused

Koodi optimeerimine ei puuduta ainult koodi kirjutamist, vaid kuidas seda teha. Juba lihtsamate praktikate jälgimine võib anda olulist võitu. Tuleks vältida kordusi, kuna see genereerib liiasusut ja võtab ilmaasjata mälu. Objektid tuleks initsialiseerida võimalikult hilja:alles siis kui neid kasutatakse. Nende loomine võtab küll vähe aega, kuid nad allutavad endale seniks mälu kuni neid enam ei vajata. See tõttu tuleks teha objektidega toimetamised võimalikud lühikesed ja siis nad deinitsialiseerida(anda väärtuseks null). Siis teab GC, et võib objekti "heap"ist ära kustuta. Kui objekt initsialiseerida varakult ja seda pikalt kasutada, siis võib ta tõusta GC kõrgemale tasemele ja jääda nii kustutamata, kasutades ilmaasjata mälu.

Stringide liitmine.

Kui teha stringide mahukaid liitmisoperatsioone, on soovitatav kasutada StringBuilderi append meetodit. Kui tegemist on vähem kui seitsme stringi liitmisega, siis tuleks kasutada + operaatorit. Kui ühekorraga liita suurem kogus stringe, on mõistlik kasutada samuti + operaatorit, kuna ainult stringi lõpptulemus luuakse.

Võrdlused

Erinevate objektide võrdlemiseks tuleks kasutada Compare meetodit nii stringide kui ka kuupäevade puhul, kuna see on kiirem. Eriti on see kasulik stringide puhul, kui tegemist on tõusutundmatute võrdlustega.

Veahaldus

Veahaldus on kulukas protsess ja selle valesti kasutamine võib maksta väga valusalt kätte jõudluses. Toome näite. Olgu meil stringide list ja me peame kontrollima kas neid on võimalik Guidides parsida. Selleks on kaks võimalust: kasutada tavalist try-catch veahaldust või meetodit TryParse(). TryParse proovib sisendiks antud parameetrit parsida ja kui see õnnestub, siis tagastab väärtuse true ja parsitud väärtuse. Kui parsimine on edukas, töötavad mõlemad variandid sama kiiresti. Kui aga parsimine ei õnnestu, on TryParse tunduvalt kiirem.

Koodinäide lk 74:

for(int i=0; i<1000; i++){
		int targetInt=0;
		try{
			targetInt = Int32.Parse("xyz");
		}catch{
		}
	}
	
	for(int i=0; i<1000; i++){
		int targetInt=0;
		if(!Int32.TryParse("xyz", out targetInt)){
		}
	}

Tulemus: Esimese variandi jaoks kulus 1052207 ticksi, TryParse jaoks 1522 ticksi. Vahe on märgatav ning võib järeldada, et try-catchi kasutamist tuleb vältida igal pool kus seda võimalik. See on siiski loodud ainult vigade töötlemiseks nagu näiteks andmebaasiühenduseavamine, kus ei saa seda tõesti muudmoodi kontrollida. Kindlasti ei tohiks kasutada seda programmis tingimuste täitmise kontrolliks.

Tsüklid Kasutades foreachi on küll mugav koodi kirjutada, kuid arvestades jõudlust ei ole see kõige parem variant, kuna listi läbikäimiseks kasutatakse enumeratorit ja see tõttu on see ka kulukas. Sellele tuleks eelistada for tsüklit, mis on optimaalsem. Lisaks tuleks viimast kasutades hoiustada listi pikkus muutujas, et iga iteratsiooni ajal ei peaks seda uuesti arvutama, mis on küll väike, aga siiski ressursi raiskav operatsioon. Samuti ei tohiks küsida välja iga iteratsiooni ajal välja väärtusi, mis on kõik aeg konstantsed, vaid defineerida need enne tsüklit näiteks objektide puhul. Lk80

Strukt ja klass Võimalusels tuleks eelistada struktide kasutamist, kuna need annavad juurde jõudlust. Põhjuseks on nende erinevus mälukasutuses. Struktid paiknevad alati pinus(stack), peale meetodi täitmist kustutab kohe ära need. Mäluhaldus on väga lihtne. Klasside puhul on tegemist reference tüüpi, mille jaoks läheb lisaks vaja veel aadressi(tüüpobjektpointerit), sünkroniseerimisblokki(alati olemas), GC vajalikud väljad(bitid), alles siis hakkavad väärtused. Ehk üks integer võtab 3 integeri ruumi. Struct aga ainult ühe. Ka nende meetodite väljakutsumine on erinev, kuna value tüüpi, siis teab alati mis tüüpi välja kutsuda. Objekti meetodi väljakutsumisel viitab see tüübi tabelile... Staatilisi meetodeid tuleks kasutada, kuna tema puhul saab translaator panna õige aadressi. Struktidel on ka piirangud, kus neid kasutada ei saa. Nende puhul ei ole pärilust(inheritance) nagu klassidel. Teda ei saa olemasolevast klassist ega struktist tuletada, küll aga saab implementeerida interface'ist. http://msdn.microsoft.com/en-us/library/aa288471%28v=vs.71%29.aspx + hennu loeng. 00:43 H.Sarv. Võimaluse korral tuleks staatilisi meetoodeid kasutada, kuna translaator saab... 00:44 on koodinäide.

Listid Kollektsioonide kasutamist tuleks alati võimalusel vältida, neile tuleks eelistada massiive, mis on kõige kiiremad. Kui see pole aga võimalik, on soovitatav kasutada Genereerikuid nagu näiteks List või Dictionary. Viimane on eriti kiire kui listist on vaja otsida konkreetseid väärtuseid, kuna tegemist on võti-väärtus paariga. Lisaks saab võtme välja abil välistada duplikaatide esinemist, kuna see peab olema unikaalne. Listi loomisel tuleks anda ette ka selle suurus. Kui seda mitte teha, siis peale seda kui listis saab kohtade arv täis, korrutatakse olemasolev list kahega ja pannakse see selle uueks pikkuseks. Sorted lisit asemel List.Sort

http://msdn.microsoft.com/en-us/library/ms172181%28v=vs.80%29.aspx + hennu loeng. Samas soovitab üldse massiividele üle minna.

Mäluhaldus http://msdn.microsoft.com/en-us/library/ff647790.aspx#scalenetchapt05_topic5 Kui luuakse uus objekt, siis peale new väljakutsumist eraldatakse sellele mälu. Objekti kasutatakse ja ta "sureb" peale seda kui tema väärtus sätitakse nulliks või "else going out of scope". Peale seda vabastatakse see osa mälust ja seda saavad kasutada teised objektid. Need tuleb luua nii hilja kui võimalik, sest see säästab mälu kasutust ja nii ei teki ohtu, et see säilib kaua. Peale seda kui objektiga on toimetused tehtud, pole meil seda enam vaja ning see tuleks "ära visata" ehk väärtus võrtsustada nulliga. Nii teab Garbage Collector, et seda objekti enam ei vajata ning saab selle varakult ära koristada. Mälu puhastatakse siis kui vaja ja korjatakse ära see, mida ei kasutata. Kogu mälu jagatakse neljaks generatsiooniks. Kõik värsked objektid saavad mälu 0 generatsioonis, kui see saab täis, siis tuleb GC neid koristama. Kõik need objektid, mis sellele ajal ei osutu prügiks, tõstetakse esimesse generatsiooni, kuna on vajalikud. Kui 0 generatsioonis ei ole midagi kustutada, liigutakse esimesele tasemele. Finalizerite loomine objektidele on väga ebasoovitatav, kuna nad jäävad GC töö käigus ellu. Nad tõstetakse Finalizer qeuesse. Allas järgmisel prügikoristamisel jõutakse neile. Jäävad ette alles siis kui, hakatakse puhastama järgmisesse. GC.SupressFinalizer(kas on nii põhjalikult vaja). IDisposable on eelistatav. Eelistatav konstruktsioon on "using", mis hoolitseb selle eest, et selle sees tehtud objekt kustutakse peale selle lõppu. Tee pikaajalised objektid kõige pealt. Generatsioon 2's. http://msdn.microsoft.com/en-us/library/ff647790.aspx#scalenetchapt05_topic5

Leitud võimaluste rakendamine

Töö praktilises osas tegeleb autor leitud optimeerimisvõimaluste rakendamisega ja tulemuste analüüsimisega. Läbiviidavad muudatused puudutavad eelkõige ERR'i teise põlvkonna .Net portaale. ASP.Net optimeerimisvõimalusi kasutatakse lehtedele news.err.ee ja rus.err.ee. News'i valiku põhjuseks on asjaolu, et selle baasil on loodud ka mitmeid teisi portaale. Seetõttu saab leitud võimalusi kergelt rakendada ka teistes sellel baseeruvatel lehtedel. Portaal rus.err.ee pidid algselt olema väike uudisteportaal, millest on praeguseks välja kasvanud meie üks suurima sisuga ERR .NET lehti. Lisaks on varem esinenud suurte koormuste puhul sellel portaalil märgatavaid jõudlusprobleeme. Prioriteediks on mõlema portaali puhul tegeleda esilehega, kuna need on võrreldes muude alamlehtedega sisuga kõige mahukamad. Lisaks korduvad mitmed esilehe komponendid alamlehtedel.

Kõigepealt plaanitakse uurida, milliseid päringuid on andmebaasis seni täidetud kõige rohkem ja kui kaua aega need võtavad. See info võetakse live andmebaasist. Esialgseks analüüsiks kasutatakse kasutusel oleva andmebaasi koopiat. Mahukamate päringute puhul analüüsib autore nende läbiviimist, proovib leida "pudelikaela" ja rakendada mõnda leitud optimeerimisvõimalustest. See võib endaga kaasa tuua muudatusi andmebaasis või rakenduse poolel, sõltuvalt sellest, kus see päring asub.

ASP.Net optimeerisvõimalustest proovitakse esmasjärjekorras väljundi puhverdamist, kuna sellega on võimalik vähendada pöörumisi andmebaasi poole ja seega parandada ka selle jõudlust. See eeldab enne komponentide prioriteetide analüüsi, mille alusel saab otusta, mida saab mällu salvestada ja kui kauaks. Lisaks proovitakse vähendada lehel viewstate'i suurust, mis on aktuaalne kui lahendust luuakse näiteks mobiilse saidi jaoks, kuna mobiilistandardite järgi ei tohiks lehed väga suured olla. Samuti tuleb kontrollida, et lehtedel kasutataks ASP.NET enda tööriistu kõige optimaalselt.

Kõige viimasena proovitakse rakendada .NET raamistiku vahenditest tulenevaid optimeerimisvõimalusi, kuna need ei pruugi anda alati nii suurt võitu võrrledes eelnevatega. Need mõjutavad ainult rakendusekihti, kui eelnevad aga mõlemat. Kontrollitakse veahaldust ja võrdlusi. Lisaks for ja foreachi, kuna tihti soovitatakse kasutada küll for'i, kuid .NET4 versioonis on juba foreach väga optimeeritud ja võib käituda isegi kiiremini. Kuna mõlemal testitaval veebirakendusel on puudulik andmekiht, siis structi ja klassi erinevusi ei saa testida.

Diplomitöö: ASP.NET veebirakenduse optimeermine meediaorganisatsiooni näitel