Load Testen van Sharepoint met VSTS 2008 en VSTT Load Agents – Deel 1

Het load testen van een Sharepoint omgeving is niet iets waar makkelijk over gedacht moet worden. Voor een test moet je toch al gauw 6 tot 8 weken uittrekken om het gedegen voor te bereiden. Dit is uiteraard allemaal afhankelijk van wat je precies wilt testen en hoeveel tests je uit wilt voeren. Een voorbeeldplanning voor een doorsnee test zou er als volgt uitzien:

1. Opstellen van een Testplan (5 dagen)
   1. Bepalen testscenarios
   2. Bepalen verwachte resultaten
   3. Planning en resources vaststellen
   4. Uitwerken testplan
2. Configureren testomgeving en test rig (5 dagen)
   1. Installeren testcontroller en agents
   2. Configureren testomgeving (sharepoint configuratie, aanmaken test accounts, dns etc)
3. Vullen testomgeving met testdata (5 dagen)
   1. Ontwikkelen data populatiescripts
   2. Verzamelen testdata van fileshares of andere media
   3. Vullen van de data
   4. Vullen van de Index
   5. Profile Import
4. Ontwikkelen webtests en load tests (10 dagen)
   1. Maken van de test scenario's
   2. Databindings maken voor webtests
   3. Testen van webtests
5. Uitvoeren van de loadtests (2 - 10 dagen)
   1. Uitvoering van verschillende tests
   2. Opnieuw uitvoeren van tests als verwachte resultaten uitblijven en aanpassing in infrastructuur vereist is.
6. Analyse van testresultaten (2 – 5 dagen)
7. Opschonen testdata (1 dag)

Zoals je ziet komt er veel bij kijken. Voornamelijk het ontwikkelen van de testscenario's en het vullen van de testomgeving met testdata is een zware taak. Webtests aanmaken in Visual Studio is namelijk niet zo gemakkelijk als het lijkt. Hier zal ik verder op ingaan in het 4^e deel van deze serie posts.

Voordat je ook maar begint met het uitvoeren van tests, moet je duidelijk zien te krijgen wat je precies wilt gaan testen en wat je verwacht te gaan scoren op elke test. Nu gaat deze reeks posts over Load testing, maar naast het testen van je applicaties en infrastructuur, moet je ook nadenken over het eventueel testen van procedures, processen en functionaliteit. Denk bijvoorbeeld aan het testen van een Disaster Recovery plan, het testen van High Availability mogelijkheden en het testen van je custom workflows. Puur en alleen load testen is niet voldoende om te bepalen of de architectuur die gekozen is, voldoet aan de verwachtingen van de business en de vastgestelde service levels, en goed aansluit op de structuur van de beheerorganisatie.

Goed… Er is dus besloten Load Tests uit te voeren, maar wat gaan we precies testen en wat verwachten we van de tests? Je kan voor verschillende doeleinden een load test uitvoeren. Je kan een smoketest uitvoeren om te zien of je applicatie werkt. Je zet deze onder lichte druk en controleert de responses, de logs en systeemcounters om te zien of er iets stuk is in de applicatie en deze doet wat je ervan verwacht. Je kan een stresstest uitvoeren waarmee je de applicatie onder zware druk zet om te bepalen waar de bottlenecks in de omgeving zitten en hoe ver je kan gaan voordat de omgeving omvalt. Tenslotte kan je nog performance of capacity tests uitvoeren waarmee je in stappen de omgeving onder druk zet om te bepalen hoe een omgeving zich houdt onder verschillende loads. Deze gegevens kunnen eveneens gebruikt worden om een stuk capaciteitsplanning te doen in de aanloopfase van een project of later in het project als de applicaties al op de uiteindelijke hardware geland zijn.

Wat voor type test je ook kiest, je zult van te voren moeten bepalen wat de verwachte resultaten zijn. Wil je de throughput van je omgeving (Requests per Second, ofwel RPS) of de gebruikerservaring meten ( Page Time, of ook wel Time To Last Byte)? Wil je het maximaal aantal geïndexeerde documenten per seconde, of Publishing Cache hit ratio meten? Er zijn zoveel verschillende redenen waarom je een Load Test zou willen uitvoeren. Hoe dan ook, het is belangrijk van te voren te bepalen wat je precies wilt gaan meten en wat de verwachte resultaten zijn. Verreweg de meest gekozen reden van een Load Test is om de throughput van de farm te bepalen of valideren; dus het aantal RPS. Laten we er voor het gemak van uit gaan dat we willen verifiëren of een omgeving gaat voldoen aan de throughput requirements van onze klant. Verder wil deze klant dat de requests voor de homepage en teamsites gemiddeld binnen 5 seconden zijn afgehandeld. In dit geval gaan we dus een performance test uitvoeren en zijn zowel Page Time als RPS van belang.

Maar hoe bepaal je nu de gewenste RPS… Laten we dit voorbeeld verder uitwerken, want dit is vaak een groot vraagteken en je moet op z'n minst een weloverwogen schatting kunnen maken, om een zinnige test te kunnen doen.

DUS STEL…

Deze klant had, zoals zoveel klanten, geen duidelijk beeld van het gebruikersprofiel van hun gebruikers.
Ze gebruiken Windows Sharepoint Services voor basic collaboration en ze hebben 100.000 medewerkers.

Van deze gebruikers verwachten ze dat maximaal 50.000 medewerkers gedurende de dag gebruik gaan maken van de omgeving. Maximale concurrency wordt geschat op 5%, wat uitkomt op 2500 gebruikers.

Dit cursief gemarkeerde gedeelte is ongeveer het meest belangrijke gegeven dat een klant kan geven over hun gebruikers, want onthoudt het volgende:

Aantal gebruikers zegt helemaal niets!

Ik kan namelijk prima 100.000 gebruikers ondersteunen op mijn Virtual PC VM met 512 RAM op mijn 4 jaar oude laptop, als deze gemiddeld elke 12 uur een request doen. 100.000 request over 12 uur is namelijk slechts 2RPS.

Wat belangrijk is, is het gebruikersprofiel en de user concurrency.

Concurrency weten we nu dus, maar zoals ik al aangaf heeft de klant dus geen duidelijk beeld van het gebruikersprofiel van hun gebruikers. We kunnen hiervoor echter de voorbeeld profielen gebruiken die op technet te vinden zijn onder: https://technet.microsoft.com/en-us/library/cc261716.aspx Deze zijn opgesteld op basis van uitvoerige interne tests en tests met TAP en andere Enterprise klanten.

Dus, stel we gebruiken het volgende profiel:

Operation	Percentage of throughput
Get home page	15.00
Get cached document	15.00
Get static document	15.00
Get list page (HTML)	10.00
Get list page (grid)	10.00
Get list form	7.00
404 errors	5.00
Insert list item	2.00
Edit list item	2.00
Delete list item	2.00
Insert document	2.00
Synchronize with Outlook	2.00
Delete document	2.00
List URLs	2.00
DAV (Distributed Authoring and Versioning) open document for edit	1.00
DAV save document	1.00
FPRPC (FrontPage Server Extensions Remote Procedure Call) open document for edit	1.00
FPRPC Save document	1.00
Short-term check-out	1.00
Incoming e-mail	1.00
RSS (Really Simple Syndication)	1.00
Start workflow	0.75
Workflow task completion	0.75
Add/remove user	0.50

Dit profiel is een typisch profiel voor WSS collaboration scenarios: https://technet.microsoft.com/en-us/library/cc261795.aspx
Laten we verder stellen dat we de volgende gebruikerscategorieën hebben:

User load	Request rate
Light	20 requests per hour. An active user will generate a request (operation) every 180 seconds.
Typical	36 requests per hour. An active user will generate a request (operation) every 100 seconds.
Heavy	60 requests per hour. An active user will generate a request (operation) every 60 seconds.
Extreme	120 requests per hour. An active user will generate a request (operation) every 30 seconds.

Wanneer we de klant de gebruikers laten indelen in deze categorieën kwamen we tot de volgende resultaten:

	% users	Users	Active users	Concurrent Users	OPS per Users	Total OPS
Light	50%	50.000	25.000	1.250	0,0056	7
Typical	25%	25.000	12.500	750	0,0100	7,5
Heavy	20%	20.000	10.000	500	0,0167	8,35
Extreme	5%	5.000	2.500	125	0,0333	5,15
Total	100%	100.000	50.000	2.500	0,0112	28

Het blijkt dus dat met het huidige gebruikersprofiel en de maximale geplande concurrency, de omgeving geschaald moet zijn om 28 Operaties te ondersteunen en dat de pageloads binnen de 5 seconden moeten blijven. Operaties zijn echter nog geen RPS. Om dit te bepalen heb je ook weer een schatting nodig, want dit is sterk afhankelijk van de usageprofielen die je gaat simuleren in je webtests en de applicatie waartegen je gaat testen. Een redelijk normaal getal om te onthouden is 5 - 10 requests per operatie. Dus je verwacht tussen de 140 en 280 RPS te halen met pageloads binnen de 5 seconden.

Nogmaals: Onthoud dat je altijd uitgaat van de maximale concurrency, en dat aantallen gebruikers niets zeggen.

Nu je de tests in het vizier hebt, is het tijd om het complete testplan uit te werken. Zie dit testplan als een plan van aanpak. Hier hoort dus alles in te staan, wat je normaal gesproken in een plan van aanpak zou vinden, inclusief een complete beschrijving van de uit te voeren tests en de configuratie van de testomgeving en testrig.

Als het complete plan klaar is, en er overeenstemming over is bereikt, kan er begonnen worden met het prepareren van de testomgeving en de testrig. Meer hierover in deel 2 van deze serie.