Systematische Aanpak Applicatie Performance

1,054 views
931 views

Published on

Een introductie tot applicatie performance en hoe die beter onder controle te krijgen is.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,054
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Systematische Aanpak Applicatie Performance

  1. 1. SystematischeAanpakApplicatiePerformanceeenintroductie<br />Peter HJ van Eijk<br />2 maart 2011<br />peter@digitalinfrastructures.nl<br />+31 6 22684939<br />
  2. 2. Waarom is performance belangrijk?<br />Gebruikersergerenzichaanvertraging<br />Trage response frustreertwerkprocessen<br />Capaciteitoverschotvoor performance is duur<br />Uit Google/Microsoft metingenblijktdatvanaf 0.5 secondenvertragingmeetbare business schadeontstaat, die oplooptnaarmate de vertraginggroterwordt<br />2-3-2011<br />2<br />
  3. 3. Waarom is performance management moeilijk?<br />Data deluge<br />Tientallencomponenten, tientallenmetingen per component, elke 5 minuten…<br />Analysis paralysis<br />De gegevenszijnnooitvolledig, het systeem is nooithelemaaltesnappen, de metingenzijnweleensonbetrouwbaar<br />Veel stakeholders, met conflicterendebelangen<br />Gebruikers, eigenaar, software leverancier(s), beheerorganisatie(s)<br />2-3-2011<br />3<br />
  4. 4. Waaromeen model?<br />Voorspellen<br />Reduceer het risico van een performance probleemin productie<br />Hoeveel hardware is nodig?<br />Wat is het effect van alternatieveconfiguraties in infrastructuur (DB, caching, solid state disk, …)?<br />Analyseren<br />Als het traag is, waarligtdatdanaan?<br />Waar zit de bottleneck?<br />Waarmoeten we metenvooreenstresstest?<br />Watmoeten we veranderen?<br />2-3-2011<br />4<br />
  5. 5. Risk based performance mgt<br />2-3-2011<br />5<br />Business Value wordtgerealiseerd door de ondersteuning van bedrijfsprocessen door applicaties<br />(opbrengst)<br />Infrastructuurbestaatuittechnischecomponenten die samen de applicatiesrealiseren<br />(kosten)<br />Hypotheses over de belangrijksterisico’s<br />Welkeprestatieszijn het meest van belang / kritisch?<br />(bijvoorbeeld dossier inzien)<br />Welkecomponentenzijn het meest van belang/ kritisch?<br />(bijvoorbeeld storage performance)<br />Performance en capaciteit<br />Model<br />
  6. 6. Voorbeelden van hypotheses<br />De interactieve response is het belangrijkste?<br />De batch doorzet is het belangrijkste?<br />We hebbeneensneller SAN nodig?<br />We hebbeneensnellernetwerknodig?<br />Erzittenteveelmensen op een terminal server?<br />Het ligtaan de software(leverancier)?<br />2-3-2011<br />6<br />
  7. 7. Een performance model<br />2-3-2011<br />7<br />Onderteverdelen in processen, typengebruikers en tijd van de dag<br /># gebruikers<br />Responstijd<br />÷<br />Volumes<br /># transacties/ sec<br />÷<br />÷<br /># DB queries / sec<br />Server CPU load<br />÷<br />÷<br /># IOPS (disk/SAN)<br />DB server load<br />
  8. 8. Risk based stress testen<br />Nietallecomponentenzijnuitputtendtetesten<br />Synthetische load is nooitwerkelijke load<br />Risico’svertellenwelkecomponenten van belangzijn.<br />Het model verteltwaarwelkecapaciteitennodigzijn<br />Gerichtestresstestenzijneenvoudiger en betrouwbaarderuittevoeren<br />2-3-2011<br />8<br />
  9. 9. Metingenvormen de invulling van uiteenlopendeinformatiebehoeftes<br />Grenswaardebewaking<br />bijvresponsetijd of belastingtbv incident management<br />Drill down in acute problemen<br />Waarwordtditprobleem nu door veroorzaakt?<br />Service level bewaking<br />Leverenwij/zijwelvolgensafspraak?<br />Capacity planning<br />Hoeveelspullenhebben we nodig, fysiekdanwelvirtueel?<br />Architectuuronderzoek<br />Welkearchitectuur is beter/sneller/goedkoper?<br />2-3-2011<br />9<br />
  10. 10. Waarom trends volgen?<br />Het aantalprocessenwaarin de applicatieeenrolspeeltneemt in de loop van de tijd toe, waardoorverhoudingengaanwijzigen. <br />Gebruikersmigreren van eenvoudiggebruiknaarintensievergebruik.<br />Dag cycli, week cycli<br />2-3-2011<br />10<br />
  11. 11. VraGEN?<br />2-3-2011<br />11<br />peter@digitalinfrastructures.nl<br />+31 6 22684939<br />www.digitalinfrastructures.nl<br />www.nlcmg.nl<br />@petersgriddle<br />
  12. 12. Appendix<br />2-3-2011<br />12<br />
  13. 13. Objecten, meetwaarden, en performance indicators<br />Gebruikersbeleving<br />Aantallenuniekegebruikers<br />Gebruikersbeoordeling<br />Door gebruikerwaargenomenresponstijd<br />Applicatie<br />Applicatie<br />Aantaltransacties per module/ per gebruiker<br />Top transacties<br />Hoe beleeft de applicatie de back-end performance<br />Infrastructuur<br />Server<br />CPU benutting<br />Memory utilisatie / Swap rate<br />Waargenomen disk performance<br />Applicatie server<br />Aantalingelogdegebruikers/sessies<br />DB server<br />Queries<br />Cache hit rate<br />Netwerk<br />Bandbreedtebenutting, round trip delays en error rates<br />SAN/Storage<br />IOPS liefst per LUN<br />Responsetijdenrespqueuelengte<br />Disk benutting<br />Elkearchitectuurheeftzijneigenmogelijkheden en uitdagingen<br />ERP<br />Web farm<br />Citrix<br />2-3-2011<br />13<br />
  14. 14. Maturity levels in het meten van performance indicators<br />2-3-2011<br />14<br />

×