Testnet Najaarsevent 2009
•
0 recomendaciones•208 vistas
Dit is de presentatie over Performance Profiling die ik op het Testnet Najaarsevenement 2009 heb gegeven
Recomendados
Recomendados
Más contenido relacionado
Similar a Testnet Najaarsevent 2009
Similar a Testnet Najaarsevent 2009 (20)
Testnet Najaarsevent 2009
- 1. Performance Profiling in verschillende werelden: van ontwikkelaar tot business Testnet najaarsevent Martijn Ruff 2009
- 2. Agenda › Verschillende werelden › Introductie Performance Profiling › Performance Profiling in de Levenscyclus › Performance Profiling en Communicatie › De Performance Profiling Specialist 2
- 3. Verschillende werelden… › Ontwikkelaars › ICT Architecten › Project- en programma management › (Functioneel) testteams › Beheerteams › Business 3
- 4. Verschillende werelden… › Ontwikkelaars › ICT Architecten › Project- en programma management › (Functioneel) testteams › Beheerteams › Business 3
- 5. Van ontwikkelaars… tot business 4
- 6. Van ontwikkelaars… tot business 4
- 7. Introductie Performance Profiling › Voorbeeld: hypotheek adviseur 5
- 8. Introductie Performance Profiling › Voorbeeld: hypotheek adviseur 5
- 9. Introductie Performance Profiling › Voorbeeld: hypotheek adviseur › De “Waarom?”-vraag 5
- 10. Introductie Performance Profiling › Voorbeeld: hypotheek adviseur › De “Waarom?”-vraag › Verdiepingsslag op bestaande performancetest en monitoring oplossing › Van Eindgebruikers-ervaring tot code › Van Eindgebruikers-ervaring tot infrastructuur 5
- 11. Introductie Performance Profiling › Voorbeeld: hypotheek adviseur › De “Waarom?”-vraag › Verdiepingsslag op bestaande performancetest en monitoring oplossing › Van Eindgebruikers-ervaring tot code › Van Eindgebruikers-ervaring tot infrastructuur › “Onder de motorkap kijken” onder productie belasting 5
- 12. Introductie Performance Profiling (code) 6
- 13. Introductie Performance Profiling (code) Totaal: 1 min 16 sec 6
- 14. Introductie Performance Profiling (code) Totaal: 1 min 16 sec Ophalen data uit database: 17 sec 6
- 15. Introductie Performance Profiling (code) Totaal: 1 min 16 sec Ophalen Sorteren data uit opgehaalde database: data: 30 sec 17 sec 6
- 16. Introductie Performance Profiling (code) Totaal: 1 min 16 sec Ophalen Sorteren Pagina data uit opgehaalde opbouwen database: data: 30 sec met data: 17 sec 29 sec 6
- 17. Introductie Performance Profiling (infra) 7
- 18. Introductie Performance Profiling (infra) WaitingThreadCount stijgt plots van 0 naar 50 7
- 19. Introductie Performance Profiling (mix) 8
- 20. Introductie Performance Profiling (mix) 1 van 6 instanties: Aantal “Long requests” loopt op 8
- 21. Introductie Performance Profiling (mix) 1 van 6 instanties: Aantal “Long requests” loopt op Threshold overschreden: Alert 8
- 22. Performance Profiling in de Levenscyclus Ontwikkeling Test Productie Acceptatie 9
- 23. PP in de Levenscyclus: Ontwikkeling › Profiling standaard onderdeel van systeemtest Ontwikkeling › Code kan al geoptimaliseerd worden voordat een release vrijgegeven wordt voor de testfase › Zonder systeembelasting worden potentiële performance issues al inzichtelijk 10
- 24. PP in de Levenscyclus: Test › Profiling als vroegtijdig performance onderzoek Test › Software aanpassingen of eventuele herziening van de architectuur zijn vroeg in het proces relatief goedkoop › Fase “Acceptatie” zal voorspelbaarder worden 11
- 25. PP in de Levenscyclus: Acceptatie › Profiling standaard onderdeel van acceptatie performancetest Acceptatie › Performance team kan gericht advies geven (positief en negatief) › Bij negatief advies kan sneller tot een oplossing gekomen worden › Bij negatief advies kunnen gericht IT specialisten aangestuurd worden 12
- 26. PP in de Levenscyclus: Productie › Profiling standaard onderdeel van Productie monitoring Productie › Alerting en rapportage a.d.h.v. Profiling data is mogelijk! › Oplostijd van incidenten kan sterk verminderd worden › Bij incidenten kunnen IT specialisten gericht ingezet worden 13
- 27. Performance Profiling en Profiling Introductie Performance Communicatie Ontwikkeling Test Acceptatie Productie 14
- 28. Performance Profiling en Profiling Introductie Performance Communicatie Ontwikkeling Test Acceptatie Productie 14
- 29. Performance Profiling en Profiling Introductie Performance Communicatie Flommen Ontwikkeling Test Acceptatie Productie 14
- 30. Performance Profiling en Profiling Introductie Performance Communicatie Flommen Uitdrukking binnen Informatisering voor onnodige verschuiving van de verantwoordelijkheid voor het afhandelen van incidenten, over de muur flikkeren. Ontwikkeling Test Acceptatie Productie 14
- 31. Performance Profiling en Profiling Introductie Performance Communicatie Ontwikkeling Test Acceptatie Productie 14
- 32. Performance Profiling en Communicatie › Performance Profiling bevat high-level én low-level informatie aan elkaar gerelateerd › Communicatie vanuit eindgebruikers perspectief (welke service lever ik de klant?) › Communicatie vanuit ontwikkelaars perspectief (welke code kan het beste geoptimaliseerd worden?) 15
- 33. Performance Profiling en Communicatie › Performance Profiling: één taal over de gehele levenscyclus › Uitwisseling van informatie tussen verschillende fasen vereenvoudigt › Acceptatie performance test levert input voor inrichting productie monitoring 16
- 34. De Performance Profiling Specialist › Performance Profiling is een specialisme › Ervaring met performance testen › Brede kennis van IT infrastructuren › Ervaring met ontwikkelmethodieken › Communicatief sterk, zowel richting techneuten als richting business › Ervaring met profiling tools › Kennis van processen binnen de organisatie 17
- 36. www.ymor.nl
Notas del editor
- Welkom Voorstellen Martijn Ruff, Ymor en Ytune
- Uitleg van het programma. - Verschillende werelden: teruggrijpen op het thema “ Testen in verschillende werelden” - Introductie PP: Wat is PP? - Levenscycli: Waar PP in te zetten? - Communicatie: Wat komt er kijken bij PP? - De PP Specialist: Als je PP in wilt zetten...
- In de IT zijn veel verschilende werelden, bijvoorbeeld Ontwikkelaars, ICT architecten, Project- en programma management, testteams, beheerteams en de business. Deze liggen vaak ver uit elkaar (thema: “Testen in verschillende werelden”). Dit komt omdat de verschilende menen in verschillende belevingswerelden leven en vaak een compleet andere taal spreken. Hierdoor gaat communicatie vaak mis en praten mensen vaak langs elkaar heen. [voorbeeld: XKCD over Ubuntu/Pokemon]
- In het volgende filmpje wordt dit allemaal een stuk duidelijker. Dit is een gedeelte van de eerste aflevering van de IT crowd. Voorstellen Roy, Moss en Jenn [na het filmpje:] Maar wat heeft dit met PP te maken? Als PP juist wordt ingezet, krijgt PP te maken met alle eerder genoemde partijen. PP is in alle fasen van de levenscyclus van een ICT systeem in te zetten. Maar, voor ik daar verder over uit ga wijden, wil ik jullie eerst een korte introductie tot PP geven, zodat duidelijk is wat PP is en welke voordelen er te behalen zijn
- Wat is PP? In mijn ogen is PP het neusje van de zalm in de wereld van Application Performance Management Aan de hand van een voorbeeld zal ik dit uitleggen. Stel, uw bedrijf verkoopt hypotheken. U heeft adviseurs in dienst die dagelijks contact hebben met uw klanten. Alleen... de adviseurs maken gebruik van een ICT systeem. En dat systeem is... traag. De klanten beginnen ongeduldig te worden als de adviseur ze al weer het derde kopje koffie aanbiedt terwijl de adviseur zich verontschuldigt voor het trage systeem. Gelukkig bent u niet voor een gat te vangen. Als regelmatige Testnet bezoeker weet u dat u een performance test uit kunt laten voeren. Maar wat nu als de uitkomst van de test de volgede is: het testrapport concludeert wat u eigenlijk al lang wist: Het systeem is te traag! U blijft echter met de belangrijkste vraag zitten: [volgende bullit] WAAROM? Dit is waar PP om de hoek komt kijken. [volgende bullit] PP is een verdiepingsslag op bestaande performance testen of productie monitoring. Waar deze twee voornamelijk eindgebruikerservaringen meten, kunt u met PP tot op code-niveau en tot op infrastructuurniveau meten en dit relateren aan de eindgebruikerservaring! Slecht performante code of verkeerd geconfigureerde infrastructuur kan zo geïdentificeerd worden. [volgende bullit] U kunt als het ware “onder de motorkap” kijken terwijl het systeem onder productie belasting staat. Wat voor informatie kunt u allemaal naar boven halen met PP? Aan de hand van drie praktijkvoorbeelden zal ik dat duidelijk maken
- Wat is PP? In mijn ogen is PP het neusje van de zalm in de wereld van Application Performance Management Aan de hand van een voorbeeld zal ik dit uitleggen. Stel, uw bedrijf verkoopt hypotheken. U heeft adviseurs in dienst die dagelijks contact hebben met uw klanten. Alleen... de adviseurs maken gebruik van een ICT systeem. En dat systeem is... traag. De klanten beginnen ongeduldig te worden als de adviseur ze al weer het derde kopje koffie aanbiedt terwijl de adviseur zich verontschuldigt voor het trage systeem. Gelukkig bent u niet voor een gat te vangen. Als regelmatige Testnet bezoeker weet u dat u een performance test uit kunt laten voeren. Maar wat nu als de uitkomst van de test de volgede is: het testrapport concludeert wat u eigenlijk al lang wist: Het systeem is te traag! U blijft echter met de belangrijkste vraag zitten: [volgende bullit] WAAROM? Dit is waar PP om de hoek komt kijken. [volgende bullit] PP is een verdiepingsslag op bestaande performance testen of productie monitoring. Waar deze twee voornamelijk eindgebruikerservaringen meten, kunt u met PP tot op code-niveau en tot op infrastructuurniveau meten en dit relateren aan de eindgebruikerservaring! Slecht performante code of verkeerd geconfigureerde infrastructuur kan zo geïdentificeerd worden. [volgende bullit] U kunt als het ware “onder de motorkap” kijken terwijl het systeem onder productie belasting staat. Wat voor informatie kunt u allemaal naar boven halen met PP? Aan de hand van drie praktijkvoorbeelden zal ik dat duidelijk maken
- Wat is PP? In mijn ogen is PP het neusje van de zalm in de wereld van Application Performance Management Aan de hand van een voorbeeld zal ik dit uitleggen. Stel, uw bedrijf verkoopt hypotheken. U heeft adviseurs in dienst die dagelijks contact hebben met uw klanten. Alleen... de adviseurs maken gebruik van een ICT systeem. En dat systeem is... traag. De klanten beginnen ongeduldig te worden als de adviseur ze al weer het derde kopje koffie aanbiedt terwijl de adviseur zich verontschuldigt voor het trage systeem. Gelukkig bent u niet voor een gat te vangen. Als regelmatige Testnet bezoeker weet u dat u een performance test uit kunt laten voeren. Maar wat nu als de uitkomst van de test de volgede is: het testrapport concludeert wat u eigenlijk al lang wist: Het systeem is te traag! U blijft echter met de belangrijkste vraag zitten: [volgende bullit] WAAROM? Dit is waar PP om de hoek komt kijken. [volgende bullit] PP is een verdiepingsslag op bestaande performance testen of productie monitoring. Waar deze twee voornamelijk eindgebruikerservaringen meten, kunt u met PP tot op code-niveau en tot op infrastructuurniveau meten en dit relateren aan de eindgebruikerservaring! Slecht performante code of verkeerd geconfigureerde infrastructuur kan zo geïdentificeerd worden. [volgende bullit] U kunt als het ware “onder de motorkap” kijken terwijl het systeem onder productie belasting staat. Wat voor informatie kunt u allemaal naar boven halen met PP? Aan de hand van drie praktijkvoorbeelden zal ik dat duidelijk maken
- Wat is PP? In mijn ogen is PP het neusje van de zalm in de wereld van Application Performance Management Aan de hand van een voorbeeld zal ik dit uitleggen. Stel, uw bedrijf verkoopt hypotheken. U heeft adviseurs in dienst die dagelijks contact hebben met uw klanten. Alleen... de adviseurs maken gebruik van een ICT systeem. En dat systeem is... traag. De klanten beginnen ongeduldig te worden als de adviseur ze al weer het derde kopje koffie aanbiedt terwijl de adviseur zich verontschuldigt voor het trage systeem. Gelukkig bent u niet voor een gat te vangen. Als regelmatige Testnet bezoeker weet u dat u een performance test uit kunt laten voeren. Maar wat nu als de uitkomst van de test de volgede is: het testrapport concludeert wat u eigenlijk al lang wist: Het systeem is te traag! U blijft echter met de belangrijkste vraag zitten: [volgende bullit] WAAROM? Dit is waar PP om de hoek komt kijken. [volgende bullit] PP is een verdiepingsslag op bestaande performance testen of productie monitoring. Waar deze twee voornamelijk eindgebruikerservaringen meten, kunt u met PP tot op code-niveau en tot op infrastructuurniveau meten en dit relateren aan de eindgebruikerservaring! Slecht performante code of verkeerd geconfigureerde infrastructuur kan zo geïdentificeerd worden. [volgende bullit] U kunt als het ware “onder de motorkap” kijken terwijl het systeem onder productie belasting staat. Wat voor informatie kunt u allemaal naar boven halen met PP? Aan de hand van drie praktijkvoorbeelden zal ik dat duidelijk maken
- Wat is PP? In mijn ogen is PP het neusje van de zalm in de wereld van Application Performance Management Aan de hand van een voorbeeld zal ik dit uitleggen. Stel, uw bedrijf verkoopt hypotheken. U heeft adviseurs in dienst die dagelijks contact hebben met uw klanten. Alleen... de adviseurs maken gebruik van een ICT systeem. En dat systeem is... traag. De klanten beginnen ongeduldig te worden als de adviseur ze al weer het derde kopje koffie aanbiedt terwijl de adviseur zich verontschuldigt voor het trage systeem. Gelukkig bent u niet voor een gat te vangen. Als regelmatige Testnet bezoeker weet u dat u een performance test uit kunt laten voeren. Maar wat nu als de uitkomst van de test de volgede is: het testrapport concludeert wat u eigenlijk al lang wist: Het systeem is te traag! U blijft echter met de belangrijkste vraag zitten: [volgende bullit] WAAROM? Dit is waar PP om de hoek komt kijken. [volgende bullit] PP is een verdiepingsslag op bestaande performance testen of productie monitoring. Waar deze twee voornamelijk eindgebruikerservaringen meten, kunt u met PP tot op code-niveau en tot op infrastructuurniveau meten en dit relateren aan de eindgebruikerservaring! Slecht performante code of verkeerd geconfigureerde infrastructuur kan zo geïdentificeerd worden. [volgende bullit] U kunt als het ware “onder de motorkap” kijken terwijl het systeem onder productie belasting staat. Wat voor informatie kunt u allemaal naar boven halen met PP? Aan de hand van drie praktijkvoorbeelden zal ik dat duidelijk maken
- Het eerste praktijkvoorbeeld komt bij een van onze klanten in de financiële wereld vandaan. Met een bepaalde applicatie waren al geruime tijd performance problemen, maar met zat met een grote “WAAROM”-vraag. De business zat met vragen of de externe leverancier zijn verplichtingen wel waar maakte, het klant contactcentrum zat met ontevreden klanten aan de lijn, de verschillende beheerteams waren druk bezig de applicatie in de lucht te houden. Iedereen wist dat er problemen waren maar niemand kon aangeven waar het aan lag. Bij gebrek aan bewijs werden verschillende ‘verdachten’ aangewezen. Het grootste probleem zou in de database zitten. Deze figuur geeft een PP analyse weer voor een van de eindebruikersacties van deze applicatie. Van links naar rechts wordt de tijd weergegeven, van boven naar beneden de verschillende functies/methodes die aangeroepen worden in de programmacode. De bovenste balk is het verzoek van de eindgebruiker geweest. In dit geval heeft dat 1 minuut en 16 seconden geduurd. Voor iedereen moet duidelijk zijn dat dit onacceptabel is. Analyse wijst uit dat de hoofdverdachte, de database, in 17 seconden klaar is. Dit is lang, maar vergeleken met de totale 1 min 16 is het relatief snel (22% van de totale tijd). Het blijkt dat een sorteermechanisme van de opgehaalde data 30 seconden duurt, en het opbouwen van de pagina met alle data ook nog eens 29 seconden. Na dit PP onderzoek zijn er een aantal veranderingen in gang gezet: - Onnodige data is verwijderd, waardoor de eerste 17 seconden teruggebracht zijn tot enkele seconden - Het sorteermechanisme is door een alternatief vervangen, waardoor de tweede 30 seconden ook tot een paar seconden teruggebracht - In de versie die nu getest wordt, is de schermopbouw aangepakt, waardoor ook de laatste 29 seconden sterk verbeterd zouden moeten zijn
- Het eerste praktijkvoorbeeld komt bij een van onze klanten in de financiële wereld vandaan. Met een bepaalde applicatie waren al geruime tijd performance problemen, maar met zat met een grote “WAAROM”-vraag. De business zat met vragen of de externe leverancier zijn verplichtingen wel waar maakte, het klant contactcentrum zat met ontevreden klanten aan de lijn, de verschillende beheerteams waren druk bezig de applicatie in de lucht te houden. Iedereen wist dat er problemen waren maar niemand kon aangeven waar het aan lag. Bij gebrek aan bewijs werden verschillende ‘verdachten’ aangewezen. Het grootste probleem zou in de database zitten. Deze figuur geeft een PP analyse weer voor een van de eindebruikersacties van deze applicatie. Van links naar rechts wordt de tijd weergegeven, van boven naar beneden de verschillende functies/methodes die aangeroepen worden in de programmacode. De bovenste balk is het verzoek van de eindgebruiker geweest. In dit geval heeft dat 1 minuut en 16 seconden geduurd. Voor iedereen moet duidelijk zijn dat dit onacceptabel is. Analyse wijst uit dat de hoofdverdachte, de database, in 17 seconden klaar is. Dit is lang, maar vergeleken met de totale 1 min 16 is het relatief snel (22% van de totale tijd). Het blijkt dat een sorteermechanisme van de opgehaalde data 30 seconden duurt, en het opbouwen van de pagina met alle data ook nog eens 29 seconden. Na dit PP onderzoek zijn er een aantal veranderingen in gang gezet: - Onnodige data is verwijderd, waardoor de eerste 17 seconden teruggebracht zijn tot enkele seconden - Het sorteermechanisme is door een alternatief vervangen, waardoor de tweede 30 seconden ook tot een paar seconden teruggebracht - In de versie die nu getest wordt, is de schermopbouw aangepakt, waardoor ook de laatste 29 seconden sterk verbeterd zouden moeten zijn
- Het eerste praktijkvoorbeeld komt bij een van onze klanten in de financiële wereld vandaan. Met een bepaalde applicatie waren al geruime tijd performance problemen, maar met zat met een grote “WAAROM”-vraag. De business zat met vragen of de externe leverancier zijn verplichtingen wel waar maakte, het klant contactcentrum zat met ontevreden klanten aan de lijn, de verschillende beheerteams waren druk bezig de applicatie in de lucht te houden. Iedereen wist dat er problemen waren maar niemand kon aangeven waar het aan lag. Bij gebrek aan bewijs werden verschillende ‘verdachten’ aangewezen. Het grootste probleem zou in de database zitten. Deze figuur geeft een PP analyse weer voor een van de eindebruikersacties van deze applicatie. Van links naar rechts wordt de tijd weergegeven, van boven naar beneden de verschillende functies/methodes die aangeroepen worden in de programmacode. De bovenste balk is het verzoek van de eindgebruiker geweest. In dit geval heeft dat 1 minuut en 16 seconden geduurd. Voor iedereen moet duidelijk zijn dat dit onacceptabel is. Analyse wijst uit dat de hoofdverdachte, de database, in 17 seconden klaar is. Dit is lang, maar vergeleken met de totale 1 min 16 is het relatief snel (22% van de totale tijd). Het blijkt dat een sorteermechanisme van de opgehaalde data 30 seconden duurt, en het opbouwen van de pagina met alle data ook nog eens 29 seconden. Na dit PP onderzoek zijn er een aantal veranderingen in gang gezet: - Onnodige data is verwijderd, waardoor de eerste 17 seconden teruggebracht zijn tot enkele seconden - Het sorteermechanisme is door een alternatief vervangen, waardoor de tweede 30 seconden ook tot een paar seconden teruggebracht - In de versie die nu getest wordt, is de schermopbouw aangepakt, waardoor ook de laatste 29 seconden sterk verbeterd zouden moeten zijn
- Het eerste praktijkvoorbeeld komt bij een van onze klanten in de financiële wereld vandaan. Met een bepaalde applicatie waren al geruime tijd performance problemen, maar met zat met een grote “WAAROM”-vraag. De business zat met vragen of de externe leverancier zijn verplichtingen wel waar maakte, het klant contactcentrum zat met ontevreden klanten aan de lijn, de verschillende beheerteams waren druk bezig de applicatie in de lucht te houden. Iedereen wist dat er problemen waren maar niemand kon aangeven waar het aan lag. Bij gebrek aan bewijs werden verschillende ‘verdachten’ aangewezen. Het grootste probleem zou in de database zitten. Deze figuur geeft een PP analyse weer voor een van de eindebruikersacties van deze applicatie. Van links naar rechts wordt de tijd weergegeven, van boven naar beneden de verschillende functies/methodes die aangeroepen worden in de programmacode. De bovenste balk is het verzoek van de eindgebruiker geweest. In dit geval heeft dat 1 minuut en 16 seconden geduurd. Voor iedereen moet duidelijk zijn dat dit onacceptabel is. Analyse wijst uit dat de hoofdverdachte, de database, in 17 seconden klaar is. Dit is lang, maar vergeleken met de totale 1 min 16 is het relatief snel (22% van de totale tijd). Het blijkt dat een sorteermechanisme van de opgehaalde data 30 seconden duurt, en het opbouwen van de pagina met alle data ook nog eens 29 seconden. Na dit PP onderzoek zijn er een aantal veranderingen in gang gezet: - Onnodige data is verwijderd, waardoor de eerste 17 seconden teruggebracht zijn tot enkele seconden - Het sorteermechanisme is door een alternatief vervangen, waardoor de tweede 30 seconden ook tot een paar seconden teruggebracht - In de versie die nu getest wordt, is de schermopbouw aangepakt, waardoor ook de laatste 29 seconden sterk verbeterd zouden moeten zijn
- Het eerste praktijkvoorbeeld komt bij een van onze klanten in de financiële wereld vandaan. Met een bepaalde applicatie waren al geruime tijd performance problemen, maar met zat met een grote “WAAROM”-vraag. De business zat met vragen of de externe leverancier zijn verplichtingen wel waar maakte, het klant contactcentrum zat met ontevreden klanten aan de lijn, de verschillende beheerteams waren druk bezig de applicatie in de lucht te houden. Iedereen wist dat er problemen waren maar niemand kon aangeven waar het aan lag. Bij gebrek aan bewijs werden verschillende ‘verdachten’ aangewezen. Het grootste probleem zou in de database zitten. Deze figuur geeft een PP analyse weer voor een van de eindebruikersacties van deze applicatie. Van links naar rechts wordt de tijd weergegeven, van boven naar beneden de verschillende functies/methodes die aangeroepen worden in de programmacode. De bovenste balk is het verzoek van de eindgebruiker geweest. In dit geval heeft dat 1 minuut en 16 seconden geduurd. Voor iedereen moet duidelijk zijn dat dit onacceptabel is. Analyse wijst uit dat de hoofdverdachte, de database, in 17 seconden klaar is. Dit is lang, maar vergeleken met de totale 1 min 16 is het relatief snel (22% van de totale tijd). Het blijkt dat een sorteermechanisme van de opgehaalde data 30 seconden duurt, en het opbouwen van de pagina met alle data ook nog eens 29 seconden. Na dit PP onderzoek zijn er een aantal veranderingen in gang gezet: - Onnodige data is verwijderd, waardoor de eerste 17 seconden teruggebracht zijn tot enkele seconden - Het sorteermechanisme is door een alternatief vervangen, waardoor de tweede 30 seconden ook tot een paar seconden teruggebracht - In de versie die nu getest wordt, is de schermopbouw aangepakt, waardoor ook de laatste 29 seconden sterk verbeterd zouden moeten zijn
- Het eerste praktijkvoorbeeld komt bij een van onze klanten in de financiële wereld vandaan. Met een bepaalde applicatie waren al geruime tijd performance problemen, maar met zat met een grote “WAAROM”-vraag. De business zat met vragen of de externe leverancier zijn verplichtingen wel waar maakte, het klant contactcentrum zat met ontevreden klanten aan de lijn, de verschillende beheerteams waren druk bezig de applicatie in de lucht te houden. Iedereen wist dat er problemen waren maar niemand kon aangeven waar het aan lag. Bij gebrek aan bewijs werden verschillende ‘verdachten’ aangewezen. Het grootste probleem zou in de database zitten. Deze figuur geeft een PP analyse weer voor een van de eindebruikersacties van deze applicatie. Van links naar rechts wordt de tijd weergegeven, van boven naar beneden de verschillende functies/methodes die aangeroepen worden in de programmacode. De bovenste balk is het verzoek van de eindgebruiker geweest. In dit geval heeft dat 1 minuut en 16 seconden geduurd. Voor iedereen moet duidelijk zijn dat dit onacceptabel is. Analyse wijst uit dat de hoofdverdachte, de database, in 17 seconden klaar is. Dit is lang, maar vergeleken met de totale 1 min 16 is het relatief snel (22% van de totale tijd). Het blijkt dat een sorteermechanisme van de opgehaalde data 30 seconden duurt, en het opbouwen van de pagina met alle data ook nog eens 29 seconden. Na dit PP onderzoek zijn er een aantal veranderingen in gang gezet: - Onnodige data is verwijderd, waardoor de eerste 17 seconden teruggebracht zijn tot enkele seconden - Het sorteermechanisme is door een alternatief vervangen, waardoor de tweede 30 seconden ook tot een paar seconden teruggebracht - In de versie die nu getest wordt, is de schermopbouw aangepakt, waardoor ook de laatste 29 seconden sterk verbeterd zouden moeten zijn
- Het eerste praktijkvoorbeeld komt bij een van onze klanten in de financiële wereld vandaan. Met een bepaalde applicatie waren al geruime tijd performance problemen, maar met zat met een grote “WAAROM”-vraag. De business zat met vragen of de externe leverancier zijn verplichtingen wel waar maakte, het klant contactcentrum zat met ontevreden klanten aan de lijn, de verschillende beheerteams waren druk bezig de applicatie in de lucht te houden. Iedereen wist dat er problemen waren maar niemand kon aangeven waar het aan lag. Bij gebrek aan bewijs werden verschillende ‘verdachten’ aangewezen. Het grootste probleem zou in de database zitten. Deze figuur geeft een PP analyse weer voor een van de eindebruikersacties van deze applicatie. Van links naar rechts wordt de tijd weergegeven, van boven naar beneden de verschillende functies/methodes die aangeroepen worden in de programmacode. De bovenste balk is het verzoek van de eindgebruiker geweest. In dit geval heeft dat 1 minuut en 16 seconden geduurd. Voor iedereen moet duidelijk zijn dat dit onacceptabel is. Analyse wijst uit dat de hoofdverdachte, de database, in 17 seconden klaar is. Dit is lang, maar vergeleken met de totale 1 min 16 is het relatief snel (22% van de totale tijd). Het blijkt dat een sorteermechanisme van de opgehaalde data 30 seconden duurt, en het opbouwen van de pagina met alle data ook nog eens 29 seconden. Na dit PP onderzoek zijn er een aantal veranderingen in gang gezet: - Onnodige data is verwijderd, waardoor de eerste 17 seconden teruggebracht zijn tot enkele seconden - Het sorteermechanisme is door een alternatief vervangen, waardoor de tweede 30 seconden ook tot een paar seconden teruggebracht - In de versie die nu getest wordt, is de schermopbouw aangepakt, waardoor ook de laatste 29 seconden sterk verbeterd zouden moeten zijn
- Het tweede praktijkvoorbeeld komt bij een van onze klanten in de transportsector vandaan. Tijdens een test bleek de performance ineens drastisch te verslechteren, wat uiteindeijk resulteerde in onbeschikbaarheid. Het PP onderzoek wees uit dat op het moment dat de eindgebruikers een verslechterde performance ervoeren, er een meetpunt in de infrastructuur afwijkend gedrag vertoonde: De “WaitingThreadCount” steeg ineens naar van 0 naar 50. Verder onderzoek wees uit dat er een gedeelte van de code was wat door meerdere parallele taken (threads) uitgevoerd moest worden, maar waar maar een taak tegelijkertijd gebruik van mocht maken. Normaal gesproken hoeft dat geen probleem te zijn, maar als dat gedeelte van de code om wat voor reden dan ook vertraagd wordt, betekent dit dat de overige taken die ook gebruik willen maken van dit gedeelte programmacode ook vertraging oplopen nog voordat ze de code uit kunnen voeren. Vervolgens ontstaat er een sneeuwbal-effect wat desastreus is voor de eindgebruikerservaring.
- Het laatste praktijkvoorbeeld komt bij een andere financiële insteling na. Waar de vorige twee voorbeelden voortkwamen uit PP onderzoeken die tijdens een performance test werden uitgevoerd, gebruikt deze klant PP als verdiepingsslag op productiemonitoring, om incidenten sneller op te kunnen lossen. Deze applicatie draait met 6 instanties in productie. Er is gebleken dat regelmatig terugkerende productie verstoringen altijd door een bepaald patroon vooraf gaan. Voordat een instantie ‘down’ gaat, stijgt eerst het aantal zgn. “Long Requests”, dwz het aantal requests wat 3 minuten of langer in het systeem blijven hangen. In dit geval is dat niet altijd iets waar de eindgebruiker wat van merkt. Als dit aantal te hoog wordt, houden deze Long Requests de beschikbare systeemresources bezet, waardoor andere acties niet meer mogelijk zijn. Door in productie op dit soort Profiling data Alerts in te richten, krijgen de beheerteams een signaal voordat er een verstoring optreedt, en kan er tijdig actie ondernomen worden. Tegelijkertijd loopt er een traject om aan de hand van PP onderzoek de oorzaak van deze Long Requests te achterhalen, om zo een stabielere productie omgeving neer te kunnen zetten. Hierdoor kan er weer een betere service aan de klanten geleverd worden.
- Het laatste praktijkvoorbeeld komt bij een andere financiële insteling na. Waar de vorige twee voorbeelden voortkwamen uit PP onderzoeken die tijdens een performance test werden uitgevoerd, gebruikt deze klant PP als verdiepingsslag op productiemonitoring, om incidenten sneller op te kunnen lossen. Deze applicatie draait met 6 instanties in productie. Er is gebleken dat regelmatig terugkerende productie verstoringen altijd door een bepaald patroon vooraf gaan. Voordat een instantie ‘down’ gaat, stijgt eerst het aantal zgn. “Long Requests”, dwz het aantal requests wat 3 minuten of langer in het systeem blijven hangen. In dit geval is dat niet altijd iets waar de eindgebruiker wat van merkt. Als dit aantal te hoog wordt, houden deze Long Requests de beschikbare systeemresources bezet, waardoor andere acties niet meer mogelijk zijn. Door in productie op dit soort Profiling data Alerts in te richten, krijgen de beheerteams een signaal voordat er een verstoring optreedt, en kan er tijdig actie ondernomen worden. Tegelijkertijd loopt er een traject om aan de hand van PP onderzoek de oorzaak van deze Long Requests te achterhalen, om zo een stabielere productie omgeving neer te kunnen zetten. Hierdoor kan er weer een betere service aan de klanten geleverd worden.
- Wanneer zou je PP nu in moeten zetten? Het ideaalbeeld is als PP over de hele levenscyclus van een applicatie ingezet wordt. Echter, voordat dit helemaal is ingevoerd in een bestaande organisatie, zal er een hoop tijd omgegaan zijn. Het is daarom aan te raden een pragmatische aanpak te gebruiken. Het meeste gebruikelijk punt om PP in te zetten is daar waar er pijn is. Op die plekken waar performance problem zijn die niet makkelijk te doorgronden zijn, of waar de “Waarom” vraag nog niet beantwoord kan worden. Bij onze klanten is dit meestal in de Productie of Acceptatie fase van de levenscyclus begonnen. Feit is dat als er eenmaal een start met PP gemaakt is, en mensen de toegevoegde waarde van PP met eigen ogen zien, er vanuit de meest onverwachte hoeken vragen komen om PP op andere producten/systemen en in andere fasen van de levenscyclus van zo’n product/systeem in te zetten. Een levenscyclus bestaat grofweg uit 4 fases die elkaar steeds opvolgen (voor het gemak worden business anlyse en specificatie hier buiten beschouwing gelaten). Een product wordt eerst ontwikkeld. Of het hier om nieuwbouw of om een upgrade gaat is in de voorbeeld niet van belang. In de figuur wordt duidelijk dat hiet van losse componten een pakketje wordt gebouwd. Als dit gereed is, word het over gedragen naar de volgende fase: test. Het pakketje of component wordt op functionaliteit beoordeeld (doet het wat het moet doen?) Als de resultaten van deze fase positief zijn, kunnen de verschillende geteste componenten in een groter geheel gepaatst worden. Koppelingen met andere systemen worden gelegd. In deze fase vindt ook de traditionele load- en strsstest plaats. Als alle testen in deze acceptatiefase postief zijn, wordt er een positief advies voor inproductiename afgegeven, en kan er in productie geïmplementeerd worden. Zoals al gezegd, in alle fasen die hier beschreven zijn, is PP in te zetten. Op de volgende 4 slides zal ik daar wat dieper op in gaan.
- Door PP een standaard onderdeel van de ontwikkelfase te maken, kan code al geoptimaliseerd worden voor een release vrijgegeven wordt voor de testfase. Hierdoor zal de kwaliteit van de opgeleverde release aanzienlijk hoger komen te liggen. Het aantal bevindingen in de testfase kan hiermee omlaag gebracht worden. Ontwikkelaars kunnen direct zien wat de mogelijke impact op performance gebied is van de code die ze ontwikkelen, wat het totale ontwikkelproces weer ten goede komt. Met PP is het voor een ontwikkelaar goed te doen om potentiële performance problemen op te sporen zonder dat er belasting op het systeem wordt aangebracht. Dit zal niet voor alle issues gelden, maar een groot deel kan al in deze fase aangepakt worden.
- In de testfase kan er een vroegtijdig PP onderzoek plaatsvinden. In deze fase worden componenten voor het eerst als een geheel getest. Hierdoor kunnen er issues ontstaan die tijdens PP in de ontwikkelfase niet naar voren zijn gekomen. Door deze issues in deze fase af te vangen, is een software aanpassing of herziening van de architectuur die uit deze issues voortvloeien relatief goedkoop. Een bijkomend voordeel is dat de volgende fase, “Acceptatie”, veel voorspelbaarder zal worden. Dit is ook wat we gezien hebben bij onze klanten die dit op deze manier doen. Doordat er intensief een vroegtijdig PP onderzoek was gedaan, is het aantal hertesten in de Acceptatie fase enorm omlaag gegaan.
- De Acceptatie fase is een van de fasen waarin PP als eerste ingezet wordt. Dit is begrijpelijk, omdat dit de fase is waar traditioneel de performance testen plaats vinden. Systemen die met een paar gebruikers probleemloos werken, kunnen onder een productie belasting heel anders gedrag vertonen. PP biedt de mogelijkheid dit gedrag te verklaren, zodat er snel een oplossing gemaakt kan worden! Omdat PP gericht een probleemgebied aan kan wijzen, is het ook veel makkelijk de juist IT specialist aan te sturen. De noodzaak voor taskforces van 20 mensen waarbij ieder team een afgevaardige stuurt wordt een stuk kleiner. Door PP in de Acceptatiefase in te zetten, beschikt een performance consultant over veel meer informatie om een goed onderbouwd advies te geven voor implementatie. Dit geldt zowel voor een positief als een negatief advies.
- Door PP in de productiefase in te zetten, wordt het mogelijk om de gedetaileerde informatie die met PP naar boven wordt gehaald in te zetten voor alerting en rapportage! Een voorbeeld hiervan heb ik u al laten zien m.b.t. de long requests in het laatste praktijkvoorbeeld wat ik heb laten zien. Op deze manier kan er pro-actief beheer worden uitgevoerd op een niveua dat zonder PP niet mogelijk is. Er kan ook gerapporteerd worden aan de hand van PP gegevens. Een voorbeeld hiervan is hoe vaak in het zojuist aangehaalde voorbeeld er long requests per maand zijn geweest. Gecombineerd met de beschikbaarheidscijfers is dit een mooie indicator van de volwassenheid van de beheerteams. Door de inzet van PP kan de oplostijd van incidenten sterk verminderd worden. Omdat een productie omgeving geen statisch gegeven is, maar steeds aan verandering onderhevig, kan het nodig zijn een PP onderzoek uit te voeren naar performance problemen. Wellicht heeft een beperkt geteste minor release meer inpact gehad dan gedacht, of is een hotfix op de applicatieserver de oorzaak van de problemen. Omdat heel gericht gezocht kan worden, kunnen de juiste mensen gericht ingezet worden. Dit is in deze fase nog crucialer dan in de voorgaande Acceptatie fase.
- Als we naar de verschillende fasen van de levenscyclus van een ICT systeem kijken, is er eigenlijk een verschijnsel wat je de meeste organisaties tegenkomt: [animatie vallende muren] Er staan grote muren tussen de verschillende fasen. In iedere fase wordt die specifieke fase tot het takenpakket van de mensen die daarin zitten gezien, en, nog belangrijker, alles wat daar buiten zit als niet tot het takenpakket en verantwoordelijkheden behorend. Er begint een gedrag te ontstaan waar ze bij een van onze klanten een heel mooi woord voor hebben bedacht, wat ze zelfs in de officiële afkortingen en begrippenlijst hebben opgenomen. [Flommen] Heeft iemand enig idee wat dit zou kunnen betekenen? [Uitleg] Uitdrukking binnen Informatisering voor onnodige verschuiving van de verantwoordelijkheid voor het afhandelen van incidenten, over de muur flikkeren. [verdwijnen van muren] Het inzetten van PP in meerdere fasen van de levenscyclus van uw ICT systeem kan een aandeel vormen in het verminderen van dit gedrag, waardoor muren kunnen gaan verdwijnen. Hoe dat kan gebeuren? Dat zal ik u uitleggen in de volgende twee slides.
- Als we naar de verschillende fasen van de levenscyclus van een ICT systeem kijken, is er eigenlijk een verschijnsel wat je de meeste organisaties tegenkomt: [animatie vallende muren] Er staan grote muren tussen de verschillende fasen. In iedere fase wordt die specifieke fase tot het takenpakket van de mensen die daarin zitten gezien, en, nog belangrijker, alles wat daar buiten zit als niet tot het takenpakket en verantwoordelijkheden behorend. Er begint een gedrag te ontstaan waar ze bij een van onze klanten een heel mooi woord voor hebben bedacht, wat ze zelfs in de officiële afkortingen en begrippenlijst hebben opgenomen. [Flommen] Heeft iemand enig idee wat dit zou kunnen betekenen? [Uitleg] Uitdrukking binnen Informatisering voor onnodige verschuiving van de verantwoordelijkheid voor het afhandelen van incidenten, over de muur flikkeren. [verdwijnen van muren] Het inzetten van PP in meerdere fasen van de levenscyclus van uw ICT systeem kan een aandeel vormen in het verminderen van dit gedrag, waardoor muren kunnen gaan verdwijnen. Hoe dat kan gebeuren? Dat zal ik u uitleggen in de volgende twee slides.
- Als we naar de verschillende fasen van de levenscyclus van een ICT systeem kijken, is er eigenlijk een verschijnsel wat je de meeste organisaties tegenkomt: [animatie vallende muren] Er staan grote muren tussen de verschillende fasen. In iedere fase wordt die specifieke fase tot het takenpakket van de mensen die daarin zitten gezien, en, nog belangrijker, alles wat daar buiten zit als niet tot het takenpakket en verantwoordelijkheden behorend. Er begint een gedrag te ontstaan waar ze bij een van onze klanten een heel mooi woord voor hebben bedacht, wat ze zelfs in de officiële afkortingen en begrippenlijst hebben opgenomen. [Flommen] Heeft iemand enig idee wat dit zou kunnen betekenen? [Uitleg] Uitdrukking binnen Informatisering voor onnodige verschuiving van de verantwoordelijkheid voor het afhandelen van incidenten, over de muur flikkeren. [verdwijnen van muren] Het inzetten van PP in meerdere fasen van de levenscyclus van uw ICT systeem kan een aandeel vormen in het verminderen van dit gedrag, waardoor muren kunnen gaan verdwijnen. Hoe dat kan gebeuren? Dat zal ik u uitleggen in de volgende twee slides.
- Als we naar de verschillende fasen van de levenscyclus van een ICT systeem kijken, is er eigenlijk een verschijnsel wat je de meeste organisaties tegenkomt: [animatie vallende muren] Er staan grote muren tussen de verschillende fasen. In iedere fase wordt die specifieke fase tot het takenpakket van de mensen die daarin zitten gezien, en, nog belangrijker, alles wat daar buiten zit als niet tot het takenpakket en verantwoordelijkheden behorend. Er begint een gedrag te ontstaan waar ze bij een van onze klanten een heel mooi woord voor hebben bedacht, wat ze zelfs in de officiële afkortingen en begrippenlijst hebben opgenomen. [Flommen] Heeft iemand enig idee wat dit zou kunnen betekenen? [Uitleg] Uitdrukking binnen Informatisering voor onnodige verschuiving van de verantwoordelijkheid voor het afhandelen van incidenten, over de muur flikkeren. [verdwijnen van muren] Het inzetten van PP in meerdere fasen van de levenscyclus van uw ICT systeem kan een aandeel vormen in het verminderen van dit gedrag, waardoor muren kunnen gaan verdwijnen. Hoe dat kan gebeuren? Dat zal ik u uitleggen in de volgende twee slides.
- Als we naar de verschillende fasen van de levenscyclus van een ICT systeem kijken, is er eigenlijk een verschijnsel wat je de meeste organisaties tegenkomt: [animatie vallende muren] Er staan grote muren tussen de verschillende fasen. In iedere fase wordt die specifieke fase tot het takenpakket van de mensen die daarin zitten gezien, en, nog belangrijker, alles wat daar buiten zit als niet tot het takenpakket en verantwoordelijkheden behorend. Er begint een gedrag te ontstaan waar ze bij een van onze klanten een heel mooi woord voor hebben bedacht, wat ze zelfs in de officiële afkortingen en begrippenlijst hebben opgenomen. [Flommen] Heeft iemand enig idee wat dit zou kunnen betekenen? [Uitleg] Uitdrukking binnen Informatisering voor onnodige verschuiving van de verantwoordelijkheid voor het afhandelen van incidenten, over de muur flikkeren. [verdwijnen van muren] Het inzetten van PP in meerdere fasen van de levenscyclus van uw ICT systeem kan een aandeel vormen in het verminderen van dit gedrag, waardoor muren kunnen gaan verdwijnen. Hoe dat kan gebeuren? Dat zal ik u uitleggen in de volgende twee slides.
- Als we naar de verschillende fasen van de levenscyclus van een ICT systeem kijken, is er eigenlijk een verschijnsel wat je de meeste organisaties tegenkomt: [animatie vallende muren] Er staan grote muren tussen de verschillende fasen. In iedere fase wordt die specifieke fase tot het takenpakket van de mensen die daarin zitten gezien, en, nog belangrijker, alles wat daar buiten zit als niet tot het takenpakket en verantwoordelijkheden behorend. Er begint een gedrag te ontstaan waar ze bij een van onze klanten een heel mooi woord voor hebben bedacht, wat ze zelfs in de officiële afkortingen en begrippenlijst hebben opgenomen. [Flommen] Heeft iemand enig idee wat dit zou kunnen betekenen? [Uitleg] Uitdrukking binnen Informatisering voor onnodige verschuiving van de verantwoordelijkheid voor het afhandelen van incidenten, over de muur flikkeren. [verdwijnen van muren] Het inzetten van PP in meerdere fasen van de levenscyclus van uw ICT systeem kan een aandeel vormen in het verminderen van dit gedrag, waardoor muren kunnen gaan verdwijnen. Hoe dat kan gebeuren? Dat zal ik u uitleggen in de volgende twee slides.
- Als we naar de verschillende fasen van de levenscyclus van een ICT systeem kijken, is er eigenlijk een verschijnsel wat je de meeste organisaties tegenkomt: [animatie vallende muren] Er staan grote muren tussen de verschillende fasen. In iedere fase wordt die specifieke fase tot het takenpakket van de mensen die daarin zitten gezien, en, nog belangrijker, alles wat daar buiten zit als niet tot het takenpakket en verantwoordelijkheden behorend. Er begint een gedrag te ontstaan waar ze bij een van onze klanten een heel mooi woord voor hebben bedacht, wat ze zelfs in de officiële afkortingen en begrippenlijst hebben opgenomen. [Flommen] Heeft iemand enig idee wat dit zou kunnen betekenen? [Uitleg] Uitdrukking binnen Informatisering voor onnodige verschuiving van de verantwoordelijkheid voor het afhandelen van incidenten, over de muur flikkeren. [verdwijnen van muren] Het inzetten van PP in meerdere fasen van de levenscyclus van uw ICT systeem kan een aandeel vormen in het verminderen van dit gedrag, waardoor muren kunnen gaan verdwijnen. Hoe dat kan gebeuren? Dat zal ik u uitleggen in de volgende twee slides.
- Als we naar de verschillende fasen van de levenscyclus van een ICT systeem kijken, is er eigenlijk een verschijnsel wat je de meeste organisaties tegenkomt: [animatie vallende muren] Er staan grote muren tussen de verschillende fasen. In iedere fase wordt die specifieke fase tot het takenpakket van de mensen die daarin zitten gezien, en, nog belangrijker, alles wat daar buiten zit als niet tot het takenpakket en verantwoordelijkheden behorend. Er begint een gedrag te ontstaan waar ze bij een van onze klanten een heel mooi woord voor hebben bedacht, wat ze zelfs in de officiële afkortingen en begrippenlijst hebben opgenomen. [Flommen] Heeft iemand enig idee wat dit zou kunnen betekenen? [Uitleg] Uitdrukking binnen Informatisering voor onnodige verschuiving van de verantwoordelijkheid voor het afhandelen van incidenten, over de muur flikkeren. [verdwijnen van muren] Het inzetten van PP in meerdere fasen van de levenscyclus van uw ICT systeem kan een aandeel vormen in het verminderen van dit gedrag, waardoor muren kunnen gaan verdwijnen. Hoe dat kan gebeuren? Dat zal ik u uitleggen in de volgende twee slides.
- Als we naar de verschillende fasen van de levenscyclus van een ICT systeem kijken, is er eigenlijk een verschijnsel wat je de meeste organisaties tegenkomt: [animatie vallende muren] Er staan grote muren tussen de verschillende fasen. In iedere fase wordt die specifieke fase tot het takenpakket van de mensen die daarin zitten gezien, en, nog belangrijker, alles wat daar buiten zit als niet tot het takenpakket en verantwoordelijkheden behorend. Er begint een gedrag te ontstaan waar ze bij een van onze klanten een heel mooi woord voor hebben bedacht, wat ze zelfs in de officiële afkortingen en begrippenlijst hebben opgenomen. [Flommen] Heeft iemand enig idee wat dit zou kunnen betekenen? [Uitleg] Uitdrukking binnen Informatisering voor onnodige verschuiving van de verantwoordelijkheid voor het afhandelen van incidenten, over de muur flikkeren. [verdwijnen van muren] Het inzetten van PP in meerdere fasen van de levenscyclus van uw ICT systeem kan een aandeel vormen in het verminderen van dit gedrag, waardoor muren kunnen gaan verdwijnen. Hoe dat kan gebeuren? Dat zal ik u uitleggen in de volgende twee slides.
- Als we naar de verschillende fasen van de levenscyclus van een ICT systeem kijken, is er eigenlijk een verschijnsel wat je de meeste organisaties tegenkomt: [animatie vallende muren] Er staan grote muren tussen de verschillende fasen. In iedere fase wordt die specifieke fase tot het takenpakket van de mensen die daarin zitten gezien, en, nog belangrijker, alles wat daar buiten zit als niet tot het takenpakket en verantwoordelijkheden behorend. Er begint een gedrag te ontstaan waar ze bij een van onze klanten een heel mooi woord voor hebben bedacht, wat ze zelfs in de officiële afkortingen en begrippenlijst hebben opgenomen. [Flommen] Heeft iemand enig idee wat dit zou kunnen betekenen? [Uitleg] Uitdrukking binnen Informatisering voor onnodige verschuiving van de verantwoordelijkheid voor het afhandelen van incidenten, over de muur flikkeren. [verdwijnen van muren] Het inzetten van PP in meerdere fasen van de levenscyclus van uw ICT systeem kan een aandeel vormen in het verminderen van dit gedrag, waardoor muren kunnen gaan verdwijnen. Hoe dat kan gebeuren? Dat zal ik u uitleggen in de volgende twee slides.
- Omdat PP een verdiepingsslag is op de ‘standaard’ performance test of productie monitoring, is het mogelijk de high-level informatie die uit de ‘standaard’ performance test of productie monitoring komt te relateren aan de de low-level informatie die uit PP naar boven komt. Hierdoor kan een performance probleem vanuit verschillende perspectieven bekeken worden. Vervolgens kan er ook vanuit deze verschillende perspectieven gecommuniceerd worden, zodat mensen van verschillende afdelingen iets met de informatie kunnen doen. Door vanuit het eindgebruikersperspectief te communiceren, kan de vraag “Welke service lever ik de klant?” beantwoord worden. Dit is vraag die vooral op business en management niveau leeft en ook beantwoord moet worden. Door vanuit het ontwikkelaarsperspectief te communiceren, kan aan ontwikkelaars duidelijk gemaakt worden in welke code de meeste optimalisatie te behalen valt. Door beide te combineren, kan er op management niveau gerichte vragen richten de ontwikkelaars gesteld worden. Het management kan prioriteren op basis van bijvoorbeeld eindgebruikersimpact, en het ontwikkelteam kan met de extra informatie een gerichte planning afgeven. Dit is een effectieve manier om muren te slechten!
- Een voordeel van het inzetten van PP in alle fasen van de levenscyclus is dat er een gemeenschappelijke taal gesproken wordt in de verschillende fasen. Dit bevordert de communictie tussen deze fasen en is dus ook een manier om de muren tussen deze fasen te slechten. Communicatie wordt op deze manier wat eenvoudiger. Daarnaast kan er informatie van de ene naar de andere fase op gang komen. Zo kan de acceptatie performance test bijvoorbeeld input leveren voor de inrichting van productie monitoring. Aan de andere kant wordt het makkelijker een productie probleem op een acceptatie omgeving na te spelen. Nu ik u dit zo heb laten zien en u wellicht overtuigd bent van de voordelen van PP, kan ik me voorstellen dat u een vraag heeft als “maar wat komt hier dan allemaal bij kijken?” Daarvoor neem ik u mee naar de volgende slide...
- PP is heel interessant, maar het is wel een specialisme. Hier volgt een korte opsomming van punten waar een goede PP specialist volgens mij aan zou moeten voldoen. Allereerst ervaring met Performance testen. Aangezien PP een verdiepingsslag is op bestaande testen (of productie monitoring) is het belangrijk die basis in huis te hebben. In het verlengde daarvan, moet de PP specialist een brede kennis hebben van verschillende IT infrastructuren. Omdat er op dit niveau veel informatie verzameld wordt, is het belangrijk te begrijpen wat er gemeten wordt. Hetzelfde geldt voor verschillende ontwikkelmethodieken. Omdat PP code inzichtelijk kan maken, is het belangrijk in ieder geval een basisbegrip te hebben van wat er gemeten wordt. Omdat er zo veel verschillende partijen betrokken zijn bij een PP onderzoek, zal de PP specialist communicatief sterk moeten zijn en aan zowel techneuten als aan de business uit kunnen leggen wat de bevindingen van het PP onderzoek. Daarnaast moet de PP specialist advies kunnen inwinnen bij de juiste personen, of dit nu techneuten zijn of business mensen. De PP specialist heeft uiteraard ook ervaring nodig van de profililng tool die wordt ingezet voor het PP onderzoek. Ten slotte heeft de PP specialist kennis nodig van de processen binnen de organisatie. Hoe verlopen de verschillende fasen van de levenscyclus van een ICT systeem? Hoe krijg je toegang tot de benodigde personen om profiling software te installeren, of de personen die op een onderdeel van de infrastructuur of programma code advies kan geven? Ik hoop dat ik u de toegevoegde waarde van PP duidelijk heb kunnen maken. Voor mij blijft PP het neusje van de zalm in Application Performance Management en een van de interessantste deelgebieden in het prachtige vak wat testen is. Als u nog vragen hebt, wil ik u nu in de gelegenheid stellen vragen te stellen.
- U kunt uw vragen ook per mail of via twitter sturen, dan zal ik uw vraag beantwoorden.
- Hartelijk dank dat u naar deze presentatie bent wezen luisteren.