Iedere performancetester heeft er wel eens mee te maken. Je start een testrun maar na een tijdje krijg je in de gaten dat het systeem zich niet zo gedraagt als dat je gewend bent. Natuurlijk kan dit best gebeuren wanneer er een nieuwe release is geweest waarin een aantal nieuwe bottlenecks is geïntroduceerd, maar wellicht is er iets anders aan de hand… Weigerende stubs, volgelopen disks, volgelopen queues en andere omgevingsgerelateerde zaken spelen vaak een rol in het wel of niet slagen van een performancetest. Het kan, ondanks dat je een goede voorbereiding hebt, toch altijd gebeuren dat de testomgeving niet zo klaar was voor de testrun als dat jij dat was... De vraag is: moet deze testrun als verloren worden beschouwd of kun je er nog iets mee?
De eerste reactie van de betrokken beheerders om je heen is vaak ‘Heb je het weer gesloopt?’ en ik zou liegen als zulke situaties bij mij nooit voor zouden komen maar ik heb wel ondervonden dat zo’n fuck-up zeker niet altijd volkomen zinloos is. De verleiding is natuurlijk groot om alles op te schonen en opnieuw te beginnen zodat je wel aan het einde van je dag de testresultaten op kunt leveren maar ondanks deze onvoorziene afloop van een testrun zie ik de waarde van zulke momenten soms wel in.
Ten eerste krijg je meer informatie over systeemgedrag in onvoorziene omstandigheden; worden de CPU-cores volledig belast doordat er een loggingdisk vol is geraakt of wordt de applicatie wellicht zelfs helemaal afgesloten? Ten tweede kan het van grote betekenis zijn om na een crash te proberen om zonder opschoningswerkzaamheden alles toch weer aan de praat te krijgen. Helemaal natuurlijk wanneer het gaat om systemen waar dataverlies in een productieomgeving geen optie is. Een logfile weggooien om ruimte te maken is niet wenselijk en bijvoorbeeld een transactie verwijderen in een two phase commit (XA) omgeving waar een message queue is volgelopen kan klantimpact betekenen!
Het kan dus, wanneer de testomgeving niet meer reageert, geen kwaad om te proberen deze weer in de lucht te brengen zonder dataverlies. Het kan immers ook in een productieomgeving een keer fout gaan (klanten zijn nog altijd vrij goed in kapotmaken) en dan wil je goed voorbereid zijn. Wat kun je doen? Disks vergroten, queues dieper maken of iets anders creatiefs. Een situatie ‘in het echt’ kan veel stress opleveren en door de oefeningen op een testomgeving kan het beheerteam ervaring op doen en is er veel meer bekend over gevolgen na een dergelijke crash. Het gevolg is dat tijdens een calamiteit bepaald grillig gedrag beter valt te voorspellen en daar kan je dan beter op reageren of het wellicht zelfs voor zijn.
Concluderend durf ik te stellen dat disaster recovery vaak een ondergeschoven kindje is die zeker grote raakvlakken heeft met Load- en Stresstesten en dat er genoeg mogelijkheden zijn om eens van meer te leren van een ‘foutje’.
