Cache, memory en… de testdataset!
Om intensieve en veel herhaalde handelingen te verlichten op systemen, om back-end-calls te verminderen en een flinke verbetering in responstijd te behalen, worden er vrijwel altijd caches op één of ander niveau (meestal zelfs meerdere) toegepast. Gebruikers blij, beheerders blij: management blij.
Win-Win-Win! Maar houd je hiermee wel goed rekening bij het testen?
Je bent zeker van het loadprofiel, de machines in je testomgeving zijn gelijk aan die van productie (mogelijk geschaald tot minder in aantal, zie andere blogs voor deze onderwerpen) en de testen verliepen succesvol…
Toch laat productie iets anders zien dan je testomgeving?
Misschien wel de ergste vrees van test- en capaciteitsmanagers: de werkelijkheid voldoet bij verre niet aan de verwachting en daardoor zijn er veel te dure systemen aangeschaft, of nog erger: de systemen, die de load volgens de uitgevoerde testen op hun gemak zouden aankunnen, gaan onderuit en het bedrijf loopt flinke omzet mis!
Het zou natuurlijk kunnen dat een reclamecampagne voor een veel hogere piek zorgt dan men verwachtte, maar ook dat wil je zo goed mogelijk vóór zijn en daar probeer je dus zo goed mogelijk op te speculeren. Wanneer de afwijking in resultaten echter komt door onvoldoende variatie in je testdata, betekent dit in feite dat je niet voldoende, of niet goed hebt getest. Nu blijkt dat je in werkelijkheid veel meer resources nodig op je systemen met de ingestelde cache-strategie, of werkt die ingestelde cache-strategie helemaal niet?!
Niet alleen bij de eindgebruiker, maar caching door de hele keten
Cache is het beste merkbaar bij front-end performance: snelle responstijden, onder andere door het inladen van tijdelijk lokaal opslagen, herbruikbare bestanden, vanuit het geheugen of vanaf de harde schijf van de eindgebruiker zelf. Testtools bieden al verscheidene mogelijkheden om hiermee om te gaan, maar dit is niet de enige niveau waar caching wordt toegepast. Ook de applicatie kan op server (redelijk) statische data bewaren (disk, geheugen of beide) en zijn er externe aanbieders die statische content opslaan, om het netwerkverkeer naar hun klanten te ontlasten. Zo worden er ook berekeningen, locaties of zoekstrategieën opgeslagen om bestanden of vaak verzochte data aan te leveren. Een goed voorbeeld daarvan zijn indexen zoals in databases.
Ik heb een index, maar de database gebruikt hem niet??
Een Oracle database, bijvoorbeeld, heeft zijn eigen manieren om de performance al vooraf te verbeteren met behulp van statistieken en executieplannen om de efficiëntie van query’s naar gelang te vergroten en steeds beter de juiste indexen te kunnen kiezen. Het is belangrijk om hiervan bewust te zijn bij het opzetten en uitvoeren van performancetesten. Als de statistieken en executieplannen niet representatief zijn, of afwezig, kan het zijn dat het als snel lijkt alsof er een performanceprobleem bij Oracle ligt, maar… er is helemaal niets veranderd aan de database en in productie zijn deze problemen er niet!
Over het algemeen ziet een DBA-er dergelijke issues al snel in en kunnen ze de test-database zodanig klaarstomen dat dit representatief klaar staat voor de test. Ook zijn datageneratoren een uitkomst, zowel om de database te vullen als om testdata voor de test aan te leveren. Een datagenerator zou ook een script kunnen zijn dat d.m.v. reguliere systeemfuncties de data inlaadt, wat inconsistentie voorkomt.
Zowel datageneratie als het draaien van statistieken op een database kunnen een lange doorlooptijd hebben, maar databases hebben vaak handige features om goede regressietesten uit te voeren (snapshots, restore points). Maak daar gebruik voor performancetesten! Zo bespaar je een hoop op de nodige tijd voor een goede testopzet…
Voor caches en representatief resource gebruik is het van belang om te letten op de grootte van de database, de variatie en hoeveelheid aan beschikbare testdata en, daar waar backends vervangen worden door stubs, dat responses ook met een representatieve vertraging worden teruggeven.
Aandacht voor database-inhoud...
De database-inhoud zou een goede afspiegeling moeten zijn van productie ten tijde van het moment waarvoor getest wordt. Bijvoorbeeld het moment waarop het product naar verwachting weer vervangen kan worden. Stelt de eis dat het product het komende jaar moet kunnen draaien, betekent dit dat ook de toename van data in de database voor dat jaar meegenomen zou moeten worden voor de test. Vandaar dat datageneratoren (al dan niet via reguliere systeemfuncties) vaak een uitkomst bieden.
Testdataset-variatie…
Bij een kleine testdataset is er soms al snel performanceverbetering waar te nemen door de efficiëntieslagen die op basis van de opgebouwde statistieken of gevulde caches tot stand komen. Bij een té kleine testdataset zal je dan wellicht merken dat de responstijd- en resourcegebruik-metingen tijdens de test veel positiever uitvielen dan uiteindelijk in productie blijkt.
en back-end delays…
Wanneer je een (externe) backend vervangt voor een stub, om wat voor reden dan ook, is het voor performancetesten aan te raden de stub op een ander systeem te plaatsen en de respons met een (variabele) representatieve vertraging terug te laten geven. Zo neem je het netwerkverkeer en het resourcegebruik voor dat request (bv. openstaande connecties) ook mee tijdens je test. Ook is het verstandig bij backends te testen wat jouw applicatie doet wanneer die backend (extra) traag is, of niet beschikbaar. Werken je time-outs en worden threads en connecties wel op tijd vrijgegeven?
Conclusie
Test onder piekload met een goed gevulde cache, maar ook met een lege cache. Als één machine uitvalt tijdens zo’n piekmoment, zou je die machine het liefst zo snel mogelijk weer in de lucht brengen en dan is het goed om te weten wat de impact van die lege cache is.
Door tijdens de test, vanuit een representatieve data-pool, een representatieve variatie aan data op te vragen voorkom je dat je in productie (direct of na verloop van tijd) ernstige vertraging of resourcegebrek te verduren krijgt en vervroegd tot vervanging moet overgaan via Incident- en Problem Management.
Meer interessante artikelen over verschillende vormen van caching en performance (-testen):
Browser-caching:
- http://radar.oreilly.com/2013/07/caching-strategies-for-improved-web-performance.html
- http://www.refreshyourcache.com/nl/cache/
CPU Caching & Performance:
Cache & Security:
Oracle Performance Tuning :
- http://www.oracle.com/technetwork/articles/sql/11g-caching-pooling-088320.html
- https://docs.oracle.com/cd/B19306_01/server.102/b14211/perf_overview.htm#g1009625
- http://www.orafaq.com/wiki/Oracle_database_Performance_Tuning_FAQ
