Odată descărcat zip-ul cu MOSS Performance Load Tests va trebui sa facem o serie de modificări înainte de al putea rula. Proiectul folosește fișiere CSV pentru a tine datele de care are nevoie in vederea simulării load-ului dupa cum urmează:

• serverUrl.csv – sunt specificate URL-urile pe care dorim sa rulam;
• MySitePort.csv – contine portul folosit pentru mysite in situatia in care alegem sa utilizam aceasta componenta;
• adminUsers.csv  – sunt specificați utilizatorii cu drepturi de administratori in aplicația testata
• HierachyManagerUsers.csv – sunt specificați utilizatorii care au drepturi de a crea/modifica si șterge obiecte din aplicație (liste, workflows, etc);
• users.csv – sunt specificați utilizatorii care au doar drepturi de citire.

nota: utilizatorii trebuie sa fie in formatul DOMENIU\username,parola

Pentru a nu avea probleme editați fișierele csv atât din directorul root cat si din directorul OfficeServerTransactions.

Odata editate fișierele va trebui sa alegem tipul de test pe care dorim sa rulam in funcție de profilul aplicației. Putem alege intre un test doar cu operații de citire (MossReadMix) si cel cu operații mixte- citire si scriere (MossREadWriteMix) Pentru aceste exemplu am ales un test care sa genereze si operații de citire si scriere:

Din opțiunile de rulare se poate adapta modalitatea de rulare la contextul nostru ajutandu-ne sa simulam cat mai bine incarnarea reala de pe server (putem schimba parametri de incarnare putând edita durata de rulare, intervalul dintre operațiuni sau numărul de iterații)

Odata deschis rularea testului este simpla, acesta urmand pe baza fisierelor de configurare:

Analiza rezultatelor testului se poate realiza atât folosind counterele definite in test atât pentru agent cat si de pentru host sau putem folosi PAL  pentru o analiza mai completa folosind fișierele threshold pentru MOSS si SQL Server.

MOSS Performance Load Tests reprezintă doar un model pentru testarea de baza a aplicației însa poate fi extins pentru a cuprinde toate elementele dorite a fi analizate. Disponibil nu este doar partea cu tranzacții standard ci si pentru Excel Services. Idea principala este însa ca plecând de la aceste metode simple de testare a aplicației in condiții de incarcare putem preveni o mulțime de neplaceri in timp si de ce nu creste satisfacția utilizatorilor finali care nu vor avea impresia unei investii neprofitabile intr-o aplicare greoaie, eliminând aceste aspecte inca din faza de proiectare.

Dezvoltarea unei aplicații MOSS 2007 presupune planificarea resurselor alocate, numărul de servere, echipamentele hardware, echipamentele de stocare, spargerea rolurilor in funcție de dimensiune, profilul aplicației, numărul utilizatorilor s.a.m.d. De multe ori am observat ca se trece peste o etapa destul de esențiala in dezvoltare si anume testarea performantei. Exista multe resurse atât pe site-ul Microsoft dar si multe bloguri care fac referința la planificarea unui deployment si partea de sizing, însa chiar daca acestea sunt respectate de multe ori se trece peste partea efectiva de testare. Testarea ne poate confirma corectitudinea calculelor noastre si ne poate arata scăpările sau “bottleneckurile” existente in design. Exista multe referințe despre load testing si analiza performantei, una dintre ele fiind : Estimate performance and capacity requirements (Office SharePoint Server) document care îl putem folosi drept referința in testele noastre.

• Estimate performance and capacity requirements for Windows SharePoint Services collaboration environments (Office SharePoint Server)

• Estimate performance and capacity requirements for portal collaboration environments

• Estimate performance and capacity requirements for search environments

• Determine resource requirements to support Excel Services

• Estimate performance and capacity requirements for Internet environments (Office SharePoint Server) .

• Performance and capacity requirements for Hyper-V

Din pacate insa etapa de load testing si analizarea rezultatelor se realizează de multe ori doar in companii specializate in livrarea de soluții MOSS, unde exista atât resursa umana necesara dar si cunostiintele pentru a putea formula scenarii de test si analiza rezultate lor. Liam Cleary [SharePoint MVP] are o serie de articole foarte interesante despre Visual Studio Team Suite Edition si load testing pentru MOSS (http://www.helloitsliam.com/archive/tags/Testing/default.aspx) si chiar recomand la toata lumea sa arunce o privire,  insa ce putem face daca nu avem la dispozitie resursele necesare pentru testarea performantei, a scalabilitatii si identificarea potențialelor probleme?

Cea mai la indemana soluție ar fi sa folosim  MOSS Performance Load Tests disponibile împreuna cu SharePoint 2007 Test Data Population Tool pe codeplex. Pentru analiza rezultatelor putem folosi PAL. Despre PAL am mai scris in posturile anterioare astfel incat nu voi intra in detaliu despre ce poate face, denumirea fiind concludenta ( Performance Analysis of Logs ).MOSS Performance Load Tests va simula load-ul a 50 de utilizatori si permite atat efectuarea de actiuni mixte (read and write) sau doar simple (read).

Visual Studio Team Suite Edition  ofera multe facilitati pentru testare inclusiv utilizarea si masurarea counterelor in timpul run-ului insa in situatia de fata vom utiliza PAL pentru analiza. Putem folosi atat counterele care vin cu testul cat si analiza logurilor din perfmon ulterior.

Pentru configurarea counterelor pe care apoi le vom urmări in timpul run-ului vom edita fișierul de threshold din PAL (MOSS 2007) lasand doar componentele necesare pentru serverul respectiv si vom crea cate un Threshould pentru fiecare rol de MOSS instalat (FrontEnd, SQL Server, Index, Search Server, etc).

Odata definite fisierele pentru serverele din ferma, le exportam  ca templateuri pentru a le putea apoi importa in perfmon.

Daca avem MOSS instalat pe Server 2008 pentru a putea importa fisierele de tip html va trebui sa facem cativa pasi suplimentari (Server 2008 necesita fisiere template in format xml nu html.)  Va trebui sa importam template-ul pe o masina cu Server 2003 iar de pe severul MOSS va trebui sa rulam 

 logman query -s <server2003 machine mane>

pentru a afisa lista cu counterele importate , iar apoi :

logman export -n "MOSS counter log name" -xml mossDB.xml -s <server2003 machine mane>

Odata importate fișierele care conțin counterele dorite, următorul pas va fi configurarea masinii de test care ne va genera activitatea.  Configurarea si rularea testului precum si analiza rezultatelor le voi acoperi insa intr-un post viitor.

PAL – sau cum luam pulsul unui sistem

In ultimele posturi am tot descris countere si cum  ele ne pot prezenta o imagine de ansamblu asupra potențialei problemei, analizând simptomele, corelând valori ale mai multor countere si trăgând o concluzie.  Insa de multe ori avem nevoie de o analiza mai detaliata întinsa pe o perioada mai lunga de timp (zile, saptamani sau chiar luni) pentru a trage o concluzie. E clar ca in astfel de situații nu ne mutam la servici deschidem perfmonul si încercam sa urmarim valorile. Avem nevoie de o metoda mai eficienta pentru a putea analiza logurile de performanta. Poate cel mai bun instrument pentru analiza este PAL (Performance Analysis of Logs)

Pentru a utiliza PAL aveti nevoie de Log Parser 2.2 care va parsa logurile  si Microsoft Office Web Components 2003 pentru a genera grafice. PAL poate fi descarcat de pe codeplex, la fel ca si documentatia de utilizare.

PAL folosește ca imput pentru analiza fișiere XML (Threshold files) unde ne putem defini toata logica de analiza si expertiza pe care o avem. Folosind GUI-ul putem chiar crea fisierele de analiza, utilizând cunostiintele pe care le avem si particularitatea aplicației pe care o vom analiza.

Revenind la discutia inițiala, PAL ofera posibilitatea de a exporta in format HTML lista cu countere pentru ca apoi, sa putem înregistra datele in perfmon  folosind un counter log pentru a lua masuratori. Pentru a importa fisierul, din meniul Actions alegem optiunea “New Log Settings From” si selectam fișierul exportat.

Va trebui totusi sa fim foarte atenti in momentul stabilirii duratei dintre masuratori. Valoarea implicita este de 15 secunde insa de obicei este bine sa o marim la 30 secunde, 1 minut sau chiar mai mult, in special deca avem un numar mare de countere si dorim sa analizam o perioada mai îndelungata. Multi pot cadea in capcana de a captura cat mai multa infomatii stabilind un interval foarte mic, insa sa nu uitam ca luarea de masutatori consuma resurse si sub nici un caz, o masuratoarea nu ar trebui sa creeze spike-uri in CPU mari astfel riscam ca analiza sa nu fie valida. La fel daca dimensiunea logurilor va fi foarte mare  generarea raporatelor poate dura destul de mult si exista riscul ca scriptul VB din spate sa nu faca fata. Scopul nostru in analiza nu este de a prinde toate spike-urile ci de stabili trenduri si a studia valorile medii pe perioade cat mai semnificate pentru problema pe care o analizam.

Pentru a realiza analiza va trebui sa pornim interfața de PAL, iar apoi vom selecta logul pe care dorim sa-l analizam si intervalul de analiza. Urmatorul pas consta in algerea fisirului de configurare pentru analiza (Threshold file). GUI-ul va genera un o comanda care va apela scripul de analiza (un script VB) trimițândui  parametri stabiliti.

Scriptul va analiza logurile si pe baza fișierului de analiza, va construi un raport cu analiza counterelor selectate si afișând alerte daca valorile definite vor fi atinse.

PAL ofera o modalitate foarte eficienta de a lua “pulsul” unui sistem si de a ne oferi indicii cu privire la bottleneck-urile de pe sistem. PAL mai ofera, in afara posibilitatii de a ne defini fișierele de configurație aplicate specificului aplicatiilor analizate, o serie de configurari predefinite care ne pot ajuta sa luam pulsul pentru SQL Server, IIS, Project Server, Hyper-V, Exchange, Biztalk, AD sau Sharepoint.

Astazi am fost nevoit la servici sa-mi schimb parola ca la fiecare 3 luni. Bun pana aici nici o problema insa cum am un obicei prost de ma loga pe masini si a ramane logat acolo, cam din ora in ora contul meu era blocat. Enervat am deschis putin powershell-ul si m-am apucat sa-mi scriu o functie care sa ma delogheze de pe toate masinile.

Cand vorbim despre cauzele performantei scazute primul gand, ne zboara spre resurse hardware insuficiente, insa de multe ori cauzele sunt foarte variate si solutiile la fel de variate. Pentru a ajunge insa la cauze trebuie sa analizam efectul iar apoi pe baza informațiilor vom trage o concluzie. Sunt multe situații cand planificarea corecta in funcție de particularitățile aplicației ne scutește de astfel de probleme, sunt situații când un Bug in aplicație ne da totul peste cap sau sunt situații când fie trebuie sa aplicam un update, un hotfix sau un workaround pentru a rezolva problemele. Indiferent de rezolvare va trebui sa identificam simptomele si cu ajutorul lor sa punem un diagnostic problemei.

Revenind la subiectul principal si anume cum colectam date despre CPU pentru a obține informații mai clare despre simptome, încercând pe baza acestor date sa gasim vinovatul problemei sau macar sa restrângem aria de căutare a problemei.

Perfmon ne pune la dispoziție ca pentru toate componentele o serie de countere pe care le putem observa pentru a identifica o potențiala problema a carei actiuni se regăsește si la nivelul CPU-ului:

• Processor\% Processor Time – reprezintă procentul din timp in care nu rulează thread-ul idle (este un thread care ruleaza pe fiecare procesor in momentul cand nu mai se executa nimic) si se calculează scăzând din timpul total timpul in care a rulat thread-ul Idle.In general trebuie sa urmărim daca valoarea de utilizare a procesorului depaseste 60% utilizare constanta, iar apoi sa observam unde petrece cea mai mare parte din timp (user mode sau kernel mode). Daca petrece majoritatea timpului in user mode va trebui sa analizam fiecare process in parte si mai departe cu un profiler dupa ce identificam procesul. Daca in schimb petrece cea mai mare parte din timp un kernel mode probabil exista un alt motiv iar activitatea intensa din CPU este doar un efect. In kernel mode se executa funcții de sistem (disc I/O, memorie, rețea, etc.)
• System\Processor Queue Length – reprezintă numărul de fire de execuție (thread-uri) aflate in coada procesorului. Pentru sisteme multiprocessor sau multicore va trebui sa impartim valoarea la numarul de core-uri de pe sistem. In general in fuctie de nivelul de procesare o coada o coada cu peste 10 fire de executie care asteapta in medie pentru perioade prelungite corelata cu timpul in care executa fie in kernel mode sau user mode ne poate duce la concluzia daca performanta sistemului va beneficia prin cresterea puterii de procesare. Sau se poate reduce numarul de fire de executie care asteapta sa fie rulate pe processor la nivelul aplicatiilor care ruleaza pe sistem.
• Processor ()\% Privileged Time – timpul pe care procesorul il petrece executand in kernel mode, executand operatii la nivel de sistem cum ar fi functii de disc I/O , network I/O sau alocare de memorie, spe exemplu. Utilizarea excesiva a procesorului in kernel mode, sugerează o posibila problema la nivelul memoriei, discului sau a retelei care cauzeaza activitatea ridicata la nivel de sistem, determinantul  sa petreacă foarte mul timp deservind I/O la nivel de sistem, ramanand mult mai putin timp alocat executiei aplicațiilor in user mode.
• System\Context Switches/sec – devine o problema daca este corelat cu utilizarea ridicata a procesorului in kernel mode si un nivel ridicat de utilizare in general. Context switching se petrece atunci cand un fir de execuție cu o prioritate mare opreste execuția unui fir cu o prioritate mai mica sau cand schimba intre executia in user mode si kernel mode. Valoarea de unde trebuie sa fim atenti este peste 15,000 pe secunda ar trebui sa ne puna in garda. In general un numar mare de fire de executie care schimba contextual intrand in kernel mode are la baza o problema legata de I/O unde ar trebui sa mergem mai departe pentru a gasi problema reala.
• Process (*)\% Processor Time – ne arata cat timp din procesor consuma fiecare process in parte. Daca suspectam un bottleneck pentru executia in user mode, putem identifica procesul care consuma excesiv de mult si apoi putem folosi un profiler pentru a analiza procesul respective.
• Processor\% Interrupt Time – indica timpul pe care procesorul il petrece pentru a primi si deservi întreruperi hardware la intervalele prestabilite. In general dispozitivele care genereaza intreruperi sunt mouse-ul driverele pentru disc, ceasul de sistem, NIC-urile sau alte dispozitive periferice. De obicei dispozitivele respective întrerup firul normal de execuție a procesorului cand fie au terminat un task sau necesita atenție. O creștere dramatica a valorii counterului ne sugerează o potențiala problema hardware.

Cele mai dese bottleneck-uri intalnite, in contextul actual, sunt cele legate de disc si I/O, in special in aplicatii care citesc sau scriu intensiv pe disk (SQL Server, Exchange,etc). Evoluția calculatoarelor a ajuns intr-un punct unde subansamblul de disc este cea mai înceata componenta dintr-un sistem. Daca vrem a face o comparație, latenta pentru diskuri in situații ideale este undeva la 10-15 milisecunde in timp ce pentru RAM este la 5 nanosecunde (de 2000 – 3000 ori mai rapide). De multe ori se ajunge la saturarea SAN-urilor in special de aplicații care utilizează intens I/O,  fie din cauza saturației discului  in special când aplicația nu are exclusivitate pentru LUN si intervine concurenta foarte mare pentru I/O (virtualizarea este un exemplu unde acesta problema este foarte comuna).  Am observat chiar si in producție datorita paginării si concurentei I/O ajungerea chiar si la valori peste 1 secunda (latenta pentru un floppy disk este sub 900 milisecunde). In special aplicații care consuma mult I/O gen SQL Server, Exchange, SharePoint vor trebui planificate corespunzător din punctul de vedere al accesului la sistemul de disc pentru a obține un nivel optim de performanta. Dar sa revenim la metodele disponibile pentru analiza performanta diskului. Perfmon ne pune la dispoziție multe countere adresate monitorizării discului dar in majoritatea situațiilor sunt 6 countere de care trebuie sa ținem cont in orice situație:

• LogicalDisk\% Free Space – masoara procentul de spațiu liber disponibil pe discul logic selectat. In general daca acesta scade sub 10% avem spatiu insuficient disponibil pe disk si e posibil sa afecteze nivelul de performanta al OS-u,l acesta nemaiavând spațiu pentru a fișierele critice. Valabil in special pentru discul logic unde se afla OS-ul
• PhysicalDisk\% Idle Time – masoara procentul de timp in care discul nu era folosit in intervalul monitorizat. Recomandarea spune ca daca valoarea scade sub 20% diskul este saturat si ar trebui înlocuit cu un disk mai rapid.
• PhysicalDisk\Avg. Disk Sec/Read – masoara timpul mediu in secunde pentru a citi date de pe disk. Daca valoarea este mai mare de 25 milisecunde , atunci diskul are probleme de latenta in momentul citirii de pe disk . Pentru LOB servere cum ar fi SQL Server sau Exchange valoarea maxima scade la 10 ms.  Daca trece de 50 milisecunde nu e bine.
• PhysicalDisk\Avg. Disk Sec/Write – masoara timpul mediu in secunde pentru scriere pe disc . Madia va trebuie sa fie pana in 25 ms, iar daca depaseste 50 milisecunde aven o problema care trebuie investigata. Pentru servicii LOB valoarea acceptata este de aproximativ 10ms.

• PhysicalDisk\Avg. Disk Queue Length – masoara cate operații I/O așteaptă pentru ca discul sa devina disponibil. Daca valoarea depaseste de doua ori numărul de diskuri din array (daca avem un singur disk valoarea nu ar trebui sa depaseasca 2 operatii care sa astepte in caoda) putem lua in calcul o problema legata de performanta discurilor si va trebui sa intram mai mult in detaliu privind o potentiala problema.
• Memory\Cache Bytes indica cantitatea de memorie folosita de cache-ul din sistem. Putem considera o problema daca valoarea depaseste 300MB.

Cand analizam problemele legate de memorie trebuie sa avem in vedere doua componente: user space memory and kernel (system) space memory.

Pentru user space memory avem doua countere care trebuie sa ne intereseze in mod special. Primul este Memory\Pages/sec despre care am discutat in postul anterior (Probleme apar la peste valori peste 1000 intr-o perioada îndelungata de utilizare). Al doilea counter de interes este Memory\Avaible Mbytes(MB). Acesta indica memoria fizica imediat disponibila in vederea alocării spre un proces sau pentru sistem. In mod normal ar trebui sa existe cel putin 50 MB memorie imediat disponibila in orice moment.  Utilizand ambele countere putem trage o concluzie privind limitarea memoriei, Pages/sec fiind inselator iar manifestari pot aparea in mai multe situatii in special pentru programe care utilizeaza in mod intensiv memoria gen SQL Server unde presiunea ar putea fi datorita memoriei alocate per instanta sau Exchange.

Pentru componenta referitoare la memoria de sistem avem:

Memory\Pool Paged Bytes fiind portiunea din memorie partajata care poate fi paginate in fisierul de paginare din windows. Paged Pool este creat la initializarea sistemului fiind folosit de componentele care rulează in modul sistem pentru alocarea memoriei.

Memory\Pool Nonpaged Bytes sunt adresele virtuale păstrate in memoria fizica care pot fi accesate de la oricare spatiu de adresare virtual fara a folosi paging de pe disk. La fel este si ea initializata la startup si este folosita de componentele sistem pentru alocarea memoriei de sistem.

Memory\Free System Page Table Entries * Adresele in memoria virtuala ale fișierelor de paginare sunt mapate la memoria fizica folosit System Page Table. Aplicațiile vor folosi apoi acest PTE pentru a mapa aceste sistem pages.

Valorile pentru cate trebuie sa fim atenți la memoria sistem sunt descrise cel mai bine in următorul tabel (tabel disponibil pe technet intr-o forma mai detaliata)

Utilizând aceste valori putem diagnostica o posibila problema la nivelul memoriei si putem lua astfel o decizie legata de cantitatea de memorie alocata sau alocarea ei către aplicații. Ar mai trebui zis ca pe sisteme x64 optiunile din boot.ini descrise nu isi mai au rostul programele putand beneficia de mai mult de 2 GB memorie alocata per proces.

Voi continua in urmatorul post analiza counterelor de baza analizand eventualele probleme legate de disk.

Windows pune la dispoziție o unealta ideala pentru diagnosticarea astfel de probleme: perfmon sau mai bine zis Peformance Monitor.

Din momentul deschiderii, Perfmon ne oferă un diagnostic in timp real asupra ce se întâmpla la nivelul OS-ului având trei indicatori porniți:

• Pages/sec indica rata la care sunt scrise sau citite “paginile” de pe disk ( “hard page faults”) altfel zis datele care nu exista in memorie si trebuie incarcate din pagefiles aflate pe disk. Ideea cu acest counter este următoare: cu cat este mai mica valoarea cu atât este mai bine neavând presiune asupra memoriei iar mașina se mișca bine. Insa când valoarea creste si avem peste 1000 pages/second avem o problema. Sigur ca nu putem trage o concluzie doar pe baza acestui counter însa depășirea acestei valori in general ne spune ca avem o problema legata de memorie care ar trebui investigata înainte sa aruncam banii pe mai mult RAM.
• Avg. Disk Queue Lenght este un counter pentru monitorizarea diskului  luând masuratori de I/O la nivelul ansamblului de disk. Acest counter este de fapt o medie dintre timpului mediu de răspuns al dispozitivelor care alcătuiesc ansamblul de disk si rata I/O. El estimează numărul de cereri neprocesate adresate diskului la nivelul logic sau fizic. Acestea includ cererile care sunt momentan efectuate la nivelul dispozitivului la care se adăuga cererile care așteaptă accesul la dispozitiv. In general putem estima o problema la nivelul diskului daca counterul depaseste valoarea 2 pentru perioade extinse de timp (minim 15 minute) pentru fiecare disk din ansablul de diskuri. Partea interesanta pentru ansamblele de disk configurate in array este ca valoarea pe care PerfMON o afișează va trebui impartita la numărul de diskuri din Array înainte de a trage o concluzie (se poate discuta si aici mai ales daca avem SQL Server instalat pentru ca sunt multe variabile, însa impartirea la numarul de diskuri este in general valabila) Spre exemplu daca avem un sistem RAID 5 cu 5 diskuri iar Avg. Disk Queue Length este 9 atunci valoarea reala a acestui counter este 1.8, sub valoarea recomandata de 2 per disk fizic.
• % Processor Time determina procentul de timp in care procesorul este ocupat calculanduse ca diferența dintre perioada de timp in care rulează thread-ul procesului Idle  si scăzând valoarea din 100. In general ar trebui sa ne punem un semn de întrebare când utilizarea procesorului depaseste 70-80 % pentru perioade îndelungate de timp, însa nu întotdeauna procesare crescuta arata o problema reala.

Perfmon ne poate oferi destul de multe informatii despre condiția sistemului nostru numai deschizândul si aruncând o privire pe cele trei countere. Însa ca orice lucru in analiza performantei acestor countere, singure nu ne spun mare lucru exceptând poate un semnal de alarma in zona respectiva unde am putea avea o problema, reala sau doar de moment. Ca reguli de baza in monitorizarea stării  unei mașini  trebuie insasi sa reținem ca nici un counter nu ar trebui luat izolat pentru a formula o concluzie. 

In următoarele posturi voi merge puțin mai departe si vom discuta mai in detaliu despre counterele de care avem nevoie pentru a ne forma o părere corecta despre starea unei mașini si cum putem crea rapoarte pe baza acestor date.