Just do I(nformation)T(echnology) : WSS

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

mpriem — Tue, 19 May 2009 18:34:24 GMT

Het is al weer enige weken geleden dat ik mijn laatste post heb gedaan over het loadtesten van Sharepoint met Visual Studio Team Test. Deze post zal ik wijden aan het maken van webtests en het bundelen daarvan tot een loadtest.

De webtests zijn de losse acties die je wilt uitvoeren. Een simpele webtest is aan te maken door deze te recorden vanuit Visual studio en verder te bewerken via de GUI. Een geadvanceerde webtest zal veelal geprogrammeerd moeten worden. In deze post ga ik niet in op gecodeerde webtests. Het is met deze blogserie de bedoeling eenvoudig een loadtest uit te voeren op Sharepoint. Met de GUI kan je al aardig wat goede loadtests uitvoeren op basis collaboratie of web content management omgevingen, zonder ook maar een regel code te kloppen.

Het Test project

Begin met het aanmaken van een test project:

Als de configuratie gevolgd is uit mijn vorige blogpost zal er meteen een venster verschijnen voor het aanmaken van een loadtest. Selecteer Finish om de default instellingen te behouden. Selecteer in de Solution Explorer de properties van LocalTestRun.testrunconfig.
In de Web Test kies je bij Number of run iterations voor One run per data source row. Verder kan ervoor gekozen worden de default Browser type veranderen.

De WebTest

Om een webtest aan te maken kies je in het Visual Studio menu voor Test > New Test. Selecteer vervolgens de Web Test en geef de test een naam. Wanneer je er nu voor kiest de test aan te maken zal Internet Explorer openen om de test te recorden. Ik zal niet elke actie uit de testmix uit eerdere posts uitleggen, omdat deze post anders veel te groot wordt J (ok, ik ben gewoon te lui). Ik zal echter een redelijk complexe actie stap voor stap uitwerken, welke je kunt gebruiken als referentie voor de overige acties. De actie die ik ga gebruiken als voorbeeld is het Uploaden van een document.

Browse naar een teamsite en selecteer een document library. Upload vervolgens een document. Je zult nu in de linkerkolom alle opgenomen acties zien:

Stop vervolgens de recording door in de linkerkolom voor Stop te kiezen. Er vindt een analyse plaats van de output en je zult in de webtest de recording terugvinden. Als we nu de webtest opnieuw zouden uitvoeren, dan zouden we elke keer hetzelfde document uploaden naar dezelfde document library op dezelfde site. Dit is uiteraard niet wenselijk. We zullen dus een stukje databinding moeten doen. Voordat we dat doen, controleren we eerst onze recording. Als we hem draaien zou hij moeten werken.

Echter als we de test draaien krijgen we meteen een error:

Als we de requests bekijken, zie je een AccessDenied.aspx request. Sharepoint geeft dus aan dat je geen rechten hebt op de pagina. Dit komt omdat je vanuit gebruikers context de Visual Studio test uitvoert. Je kunt dit echter aanpassen door in het WebTest tabblad de security aan te passen:

Zou dit genoeg zijn???

Helaas, de volgende melding die we krijgen is als volgt:

Dit betekent dat Visual Studio het bestand niet kan vinden dat geupload moet worden. Om dit voor nu even op te lossen passen we de File Upload Parameter van het Upload.aspx request aan om het volledige pad naar het bestand te gebruiken:

LoadAgentKnownIssues.rtf wordt in mijn geval dus C:\Temp\LoadAgentKnownIssues.rtf

Als we de test nu draaien, gaat alles goed:

Op naar het Data Binden!!

Databinding

Ik maak gebruik van CSV bestanden maar je kunt ook een database of xml bestand gebruiken. Maak dus een CSV bestand aan en geef op de eerste regel headers op. In dit geval gebruik ik een enkele kolom met als header DocumentPath. Op de volgende regels zet ik de namen van de bestanden. Daarnaast heb ik nog een CSV bestand nodig met de verschillende sites die ik wil gebruiken. Geef het bestand de SiteName header en voeg de namen van de sites toe. Als laatste heb ik een bestand nodig met alle gebruikers en de wachtwoorden. We willen natuurlijk met meerdere accounts testen. Dit resulteert in de volgende drie bestanden:

Zoals je ziet vervang ik slechts delen van de padnaam en de URL. Dit doe ik omdat door het minimale tekstdeel te vinden dat variabel gemaakt kan worden, de kans groter is dat het CSV bestand voor meerdere parameters gebruikt kan worden. Ik loop hierdoor ook minder tegen problemen aan met het URL encoden van parameters, maar dat merk je vanzelf als je vaker dit soort tests ontwikkelt.

Nu is het belangrijk om te onthouden dat je bij het uploaden van files de uploadbestanden beschikbaar moet hebben op de loadagent machines. Nu kan dat op de volgende 2 manieren:

De bestanden kunnen toegevoegd worden aan de solution. Je hoeft dan niet het volledige pad te gebruiken. Bij het uitvoeren van de test worden de bestanden gekopieerd naar de load agents (als de Copy to Output directory properies van de bestanden juist ingesteld staan).
De bestanden moeten handmatig op de loadmachines gezet worden. Je dient dan het volledige pad te gebruiken als waarde. Ik gebruik deze manier.

Kopieer dus de bestanden naar de gewenste directory op de loadagent(s) en kies vanuit de WebTest tab van het project voor Add Data Source:
"

Kies voor CSV en selecteer het eerder aangemaakte bestand. Je kunt nu nog bepaalde kolomen selecteren, maar we hebben er maar 1. Kies ervoor het bestand toe te voegen aan het project. Doe dit ook voor het tweede bestand. Nu ze toegevoegd zijn, kun je de waarden gebruiken in de webtest.

Om een waarde te gebruiken, kan je in de properties van de test kiezen voor een datasource, maar vaak wil je slechts een gedeelte van een property vervangen door een variable waarde. Dit kan ook; je dient dan de volgende syntax te gebruiken:

{{<datasourcenaam>.<table>.<kolom>}} à {{Sites.sites#csv.SiteName}}

Als we nu in elk request de Url en Expected Response Url properties parametriseren hebben we de webtest bijna zover aangepast dat we hem kunnen draaien voor alle sites in ons CSV bestand. Voor en na is als volgt:

De test is nog niet helemaal gereed om tegen alle sites in ons CSV bestand te draaien. Als je het nu draait, mislukken alle iteraties behalve de eerste. Als je naar het mislukte request kijkt, dan krijg je de melding:

Request failed: Context parameter '$HIDDEN1.__EVENTARGUMENT' not found in test context

Dit betekent dat er schijnbaar een parameter gevuld had moeten zijn via een Hidden Field Extraction rule. Het gaat dus ergens eerder al mis, ondanks dat Visual Studio aangeeft dat de eerdere requests goed zijn afgehandeld. Als we van onder naar boven de requests aflopen komen we meteen in het vorige request de boosdoener tegen:

Schijnbaar kan Sharepoint een bepaalde List niet vinden. Als je vervolgens requests eens nader bekijkt, zie je dat er in de POST continu dezelfde List parameter wordt meegegeven. Aangezien elke list in een content database een unieke GUID heeft, zal Sharepoint de list in combinatie met een bepaalde site alleen kunnen terugvinden voor de eerste iteratie. We zullen de post parameter dus moeten parametriseren. Als we in voorgaande requests kijken is er nergens een GUID als parameter opgenomen. We kunnen hem dus niet direct uit te recording halen. Als we echter de ListID opzoeken in het ruwe Responses van de eerste iteratie, dan zien we dat in het response van het AllItems.aspx request de GUID een aantal malen voorkomt. We kunnen hem dus uit de response HTML plukken via een Extraction Rule:

Nu kan je het met een extraction rule op verschillende manieren aanvliegen, maar de makkelijkste is via een Text Extraction. Gebruik de volgende configuratie:

Een andere manier is om een Regular Expression te gebruiken. Ik gebruik dan als regular expression:

\{[A-Fa-f0-9]+\-[A-Fa-f0-9]+\-[A-Fa-f0-9]+\-[A-Fa-f0-9]+\-[A-Fa-f0-9]+\}

De index (welke occurance hij moet gebruiken) is voor OOTB Sharepoint teamsites 2.

Als we de Extraction Rule hebben aangemaakt voor het AllItems.aspx request, kunnen we hem gebruiken als QueryString parameter voor onze POST requests richting Upload.aspx. Zorg dus dat de List parameters als waarde onze GUID parameter gebruiken ( {{GUID}} ).

Zoals je hierboven kunt zien, zijn er nog meer request parameters die aangepast kunnen worden, namelijk RootFolder en Source. Zorg ervoor dat deze ook geparametriseerd zijn.

Een andere actie is dat we moeten zorgen dat niet steeds hetzelfde bestand wordt geupload. De laatste databinding is dus voor de te uploaden file. Als we de requests eens nader bekijken zie je in de context parameters van het tweede Upload.aspx request het File Upload Parameter.

Deze passen we aan met {{Files.files#csv.DocumentName}} is het Data Binden gereed. Het complete overzicht van mijn test ziet er als volgt uit:

Als we nu de webtest starten, gaat alles goed:

Als je de requests 1 voor 1 doorloopt, zie je in de context parameters dat er op elke site een ander document wordt gebruikt. Je kunt via de opties op de Data Sources nog bepalen of de files iteratief of random worden gekozen.

Als laatste binden we de user accounts. Dit gaat via het menu, waar we eerder het gebruikers account wijzigde:

Nu het Data Binden klaar is, zijn we nog niet klaar. We gaan nu onze webtest opschonen.

Opschonen

De bedoeling is het uploaden van het bestand te meten. Ik wil alles wat daar niet mee te maken heeft, uit de test hebben. Dit betekent dat alle resources (gif, css en scriptbestanden) niet meegenomen worden, en dat alle voorlooprequests (voor zover ze geen properties vullen) uit de recording gehaald worden. Ik doe dit om mijn meetresultaten niet te overspoelen met deze veelal lichte acties. Ieder heeft hier zo zijn eigen ideeen over, en ik zal niet pretenderen dat dit de enige manier is, maar meetresultaten zien er altijd veel mooier uit als je al die andere requests wel meeneemt, en ik heb altijd "Hope for the best, but plan for the worst". Uiteindelijk komen die requests toch bijna altijd uit clientcache of servercache.

Goed… Voordat ik begin met het opschonen, sla ik de WebTest altijd even op onder een andere naam als backup.

Het opschonen vereist een beetje gezond verstand. Bekijk de requests, probeer de structuur te achterhalen, en het zin van het onzin te scheiden. Het feitelijke uploaden is een POST naar Upload.aspx. Daar ik begonnen ben met het openen van de rootsite en van daaruit gebrowsed ben naar de document library, vertelt mij dat ik die requests normaal gesproken eigenlijk al niet nodig. Je ziet eveneens dat er geen properties zijn opgeslagen aan het ontbreken van de + voor het request. Dit betekent dat er geen waardes in de web context zijn opgeslagen die gebruikt kunnen worden in het volgende request:

Ik verwijder het eerste request dus!

Wat ik vervolgens meestal doe is tijdens het opschonen elke keer de test gewoon nog een keer aftrappen, om te controleren of de test nog steeds werkt.

Misschien valt het op dat de resource requests niet zichtbaar zijn in de recording. Dat klopt, maar bij uitvoering worden ze wel opgehaald. Om dit te voorkomen, dien je in de properties van de requests Parse dependent requests op false te zetten (elk request apart):

De webtest is zo voldoende opgeschoond. We zijn nu bijna klaar met de webtest. Er rest nog 1 belangrijke taak, namelijk het aanmaken van validation rules.

Validation Rules

Zoals we al een aantal malen hebben gezien geeft Visual Studio soms aan dat een request goed is uitgevoerd, terwijl we niet het verwachte response hebben gekregen. Denk maar aan de AccessDenied.aspx pagina. We kregen successful request van Visual Studio terug, maar dat is niet wat we willen. We zullen hier wat validatie moeten toepassen via Validation Rules.

Zo begin ik met een validation rule voor dat specifieke geval op elk request. Het makkelijkst is dat via een Text Found rule. Ik gebruik de volgende:

Hou er rekening mee dat Pass If Text Found op False moet staan. Hij moet namelijk failen als die tekst wordt gevonden op de pagina. Een andere die ik altijd op elke request toepas is een Text Found rule die zoekt naar de tekst: Troubleshoot issues with Windows SharePoint Services. Deze tekst staat namelijk op de Error pagina die Sharepoint gebruikt (tenzij je custom error pages gebruikt, of volledige errormeldingen toestaat in Web.config).

Met deze twee validation rules vang je bijna alles af. Standaard triggert Visual Studio al een failure op http status codes als 500 en 404.

Wat ik persoonlijk in dit scenario nog toevoeg is een Text Found rule voor de filename die geupload wordt. Ik parametriseer de tekst waarop gezocht wordt met {{Files.files#csv.DocumentName}}.

Nu is onze webtest eindelijk klaar!!

Als we nu meerdere tests gemaakt hebben kunnen we de LoadTest gaan configureren:

Load Test configuratie

Met meerdere webtests kunnen we gaan loadtesten. De configuratie is redelijk eenvoudig. In de solution explorer hebben we onze load test staan (bestand eindigt op .loadtest). Hernoem en dubbelklik deze om een tabblad te krijgen. Standaard ziet de configuratie er zo uit:

De belangrijkste settings zijn de Test Mix, de Browser Mix, de Network Mix en het Load Pattern. De Test Mix staat er nog niet tussen, maar hierin bepaal je welke tests en met welke verdeling uitgevoerd dienen te worden. Verder kunnen we met de browser Mix bepalen welke type browsers gesimuleerd dienen te worden, en met de Network Mix welke type netwerken (Deze laatste knijpt echter alleen de bandbreedte en doet niets met latencies en is daardoor dus niet echt spannend.). De Loadpattern bepaalt welke load er op de omgeving gezet wordt.

In deze test laat ik de Browser Mix en Network Mix default en zet ik de LoadPattern op een Step Load. Een stepload stelt mij in staat over een bepaalde periode telkens een aantal gebruikers op te schalen. Dit is aan te bevelen om de de te testen omgeving de Sharepoint en IIS caches te laten opbouwen. Met een constant userload, zet je meteen de maximale load op de omgeving, wat dus tot problemen zou kunnen leiden. Een typische step configuratie ziet er zo uit:

Met deze configuratie wordt er begonnen met 10 users en wordt er elke 10 seconde 10 users bijgeschakeld totdat we aan het maximum van 200 users zitten.

Nu is het de bedoeling testen toe te voegen aan de loadtest. Dit gaat door het aanmaken van een testmix. Kies voor Edit Test Mix van het context menu van de load test:

In de Test Mix kan je voor een aantal modellen kiezen, maar de Test Mix op basis van het aantal tests is het meest voor de hand liggende. Ik heb twee tests toegevoegd, welke ik met een 90% - 10% percentage verdeel. Dit betekent dat 90% van de acties het benaderen van de homepage is:

Nu is eigenlijk mijn load test al klaar. Ik kan via de Counter Settings nog System Counters toevoegen. Hiervoor moet het visual studio account rechten hebben op de machine (minimaal Performance Log User), en moeten de firewall rules juist zijn ingesteld. Via de Run Settings kunnen we bijvoorbeeld bepalen hoe lang de loadtest moet duren (Timing), maar ook bijvoorbeeld SQL tracing configureren of de connectie pool instellingen aanpassen.

De Timing instellingen zijn altijd van belang. Je bepaalt met Run Duration de looptijd, met de Sample Rate met welke interval performance counters worden gelogd en met Warm-Up Duration en Cool-down Duration hoe lang het duurt voordat er begonnen wordt met het verzamelen van meetgegevens en hoe lang voor het eind er gestopt wordt. Het opwarmen van cache en het opstarten van applicatie pools vervuilen immers alleen de meetresultaten.

Als dit alles is geconfigureerd, kan er begonnen worden met het load testen. Meer hierover in het volgende en laatste deel van deze blogserie J

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

mpriem — Sun, 15 Mar 2009 01:49:00 GMT

Deze post gaat over het installeren van je testrig en (slechts beknopt) over het vullen van de testomgeving met data.

Voor een testrig heb je in principe drie componenten nodig. Dat zijn de Test Controller, de Test Agent en de machine waar je Visual Studio Team System 2008 Test Edition draait. Nu kan uiteraard alles op 1 machine worden geïnstalleerd, dus voor deze reeks posts gebruik ik een enkele machine. Normaal gesproken werk je in ieder geval met een losse controller en losse agents. Visual studio voor het aansturen van de tests wordt nog wel regelmatig op de controller geïnstalleerd. De vereisten voor de componenten zijn als volgt:

Software:

Component		Software
Test agent		Windows Server 2003 RTM*, Vista, XP Sp2 Visual Studio Team System 2008 Load Agent SQL 2008 Express edition
Test Controller		Windows Server 2003 RTM*, Vista, XP Sp2 Visual Studio Team System 2008 Load Controller (SQL Server 2008 optioneel. SQL vereist Windows Server 2003 SP2)
Tester PC		Visual Studio Team System 2008 Test Edition SP1

* Test Agents en Controllers vereisen Windows Server 2003 RTM of hoger service pack. Windows Server 2008 wordt officieel niet ondersteund. Windows Vista echter wel, dus het zal waarschijnlijk ook wel werken op Server 2008, maar waarom zou je je niet aan de prerequisites houden?

Mocht je voor de Tester PC Windows Server kiezen, dien je de 'Internet Explorer Enhanced Security' uit te zetten. Dit voorkomt dat je problemen krijgt bij het recorden van de test scenario's.

Hardware:

Bij het kiezen van de hardware moet je er rekening mee houden dat de Load Agents voornamelijk de zwaarste last leggen op de machines. Ze zijn zeer hongerig naar CPU cycles en geheugen; dus het is aan te raden gewoon hele dikke bakken te nemen, met minimaal een moderne dual core, draaiend op 64 bits architectuur met 8GB aan geheugen. Verder is het testen op een Gigabit verbinding eigenlijk ook wel vereist, daar zware tests een flinke hoeveelheid bandbreedte kunnen verbruiken. Dit ligt uiteraard aan het type test en de test scenario's, maar houd er rekening mee. Vaak moet hardware ruime tijd van tevoren worden aangevraagd en je wilt niet tegen beperkingen aanlopen als het testplan toch anders wordt dan vooraf gedacht. Je zou er ook aan kunnen denken om hardware te huren. Met virtuele machines is geen ervaring, waardoor het lastig is in te schatten of dit een goede optie is. Dit zou getest moeten worden.

Configuratie	Component	CPU	HD	Memory
< 1000 virtual users	Test agent	2.6 GHz	10 GB	4 GB
< 2000 virtual users	Test agent	Dual proc 2.6 GHz	10 GB	8 GB
*N 2000 virtual users**	Test agent	Scale out N agents elk met Dual 2.6 Ghz	10 GB	8 GB
< 30 servers in test (test agents en te testen servers).	Test Controller	2.6 GHz	Met SQL : (N* 24 uur testdata * 10GB) + 10GB Zonder SQL : < 1 GB	Met SQL : 4 GB Zonder SQL : 2 GB
*N 30 computers in the test environment. This includes agents and servers under test.**	Test Controller	N* 2.6 GHz processors	Met SQL : (N* 24 uur testdata * 10GB) + 10GB Zonder SQL : < 1 GB	Met SQL : 4 GB Zonder SQL : 2 GB
	Tester PC	2.0 GHz	3GB	1 GB

In principe geeft deze tabel aan dat je dus een extra Test Agent moet bijschalen voor elke 2000 actieve users. Voor elke 30 agents heb je een controller nodig.

Netwerk

Voor de simulaties heb je in ieder geval een tweetal accounts nodig voor de agents en de controller (we gaan even uit van een Domain installatie. Workgroup is ook mogelijk). Maak dus twee service accounts aan voor de controller en voor de agents. Het controller account moet minimaal toegevoegd zijn aan de Performance Log Users op de machines die getest gaan worden (dus de sharepoint farm servers). Houd er ook rekening mee dat de Windows Firewall in de weg kan zitten. Voor Windows Server 2008 en Vista zal je meer stappen moeten verrichten zoals beschreven in http://blogs.msdn.com/edglas/pages/load-agent-and-load-controller-installation-and-configuration-guide.aspx Daar staat de Firewall standaard aan en de services die nodig zijn om de counters te loggen standaard uit.

Als je een testscenario met NTLM of Kerberos authenticatie providers wilt maken, zal je ook test users moeten aanmaken. Een voorbeeld is te vinden op : http://www.petri.co.il/create_users_for_testing_purposes.htm Nu hoef je niet voor elke virtual user een testuser aan te maken, maar voor elke 25 users zou ik toch wel een account willen hebben, met een minimum van 10. Dus 10.000 virtual users maakt 400 user accounts. Dit om toch enigszins het effect van authenticatie op de Sharepoint omgeving te kunnen benaderen, MySites en ook om het effect van audiencing mee te kunnen nemen in de tests.

Installatie Visual Studio

De installatie van Visual Studio spreekt redelijk voor zich. Alle prerequisites worden door de installer zelf geïnstalleerd. Visual studio is een zeer uitgebreid product, maar voor onze tests heb je in principe alleen de testing tools en 1 van de language tools nodig. Deze laatste is om de VS IDE te verkrijgen. Kies daarom alleen de Team System Test Tools categorie en een taal naar keuze (in mijn geval C#). De rest van de installatie spreekt voor zich. Installeer verder SP1 en de laatste fixes.

Installatie Load Agents en Load Controller

Voor de installatie van de Load Agents en de Load controller zijn de twee service accounts vereist die eerder zijn aangemaakt. Bij het starten van de installatie zal je de keuze krijgen een Agent of Controller te installeren.

Eerst installeer je de Test Controller. Deze zal meteen ook SQL Express installeren, maar die heb ik niet nodig aangezien ik de volledige versie van SQL ga installeren. Bij het starten van de controller installatie vraagt de installer alleen om de credentials van het controller service account. De rest van de installatie spreekt voor zich. Na installatie is de Controller als windows service geïnstalleerd en kan je hem configureren via Visual Studio.

Vervolgens installeer je de Agent software. Tijdens deze installatie wordt enkel gevraagd naar het agent service account en de naam van de agent controller. Geef dus de servernaam op waar de controller draait, in dit geval de lokale machine.

Installatie Visual Studio Service Pack 1

Na het installeren van de agents en controllers, moet Service Pack 1 voor Visual Studio geinstalleerd worden. Dit omdat anders SQL Server 2008 niet zal installeren. Deze vereist namelijk SP1 voor Visual Studio. SP1 update zowel de IDE als de controller en agents.

Voor het installeren van Service Pack 1 heb je echter ook de Visual Studio 2008 Service Pack Preparation tool nodig. Deze is te vinden op http://www.microsoft.com/DOWNLOADS/details.aspx?familyid=A494B0E0-EB07-4FF1-A21C-A4663E456D9D&displaylang=en . Service Pack 1 (ISO) op http://www.microsoft.com/DOWNLOADS/details.aspx?familyid=27673C47-B3B5-4C67-BD99-84E525B5CE61&displaylang=en

Installatie SQL Server

Net zo makkelijk als de installatie voor Visual Studio is de installatie van SQL Server 2008, mocht je daarvoor kiezen. De installer installeert zelf de prerequisites, en bij het kiezen van de componenten draait het alleen om de Database Engine en de management tools. Verder kan je de SQL Server Agent gewoon onder NETWORK SERVICE en de SQL Server Service onder LOCAL SYSTEM laten draaien. De rest van de installatie spreekt voor zich.

Configuratie Controller

Na installatie van de software dient de controller via Visual Studio geconfigureerd te worden. Maar maak eerst een LoadTest database aan op de SQL server instance door loadtestresultsrepository.sql uit te voeren op de SQL server (gebruik SQLCMD of dubbelklik en execute via de SQL Management Studio). Pas wel op… Als er reeds een LoadTest database bestaat, wordt deze gedropped. Na het aanmaken van de database dien je nog het Controller service account db_datawriter of db_owner rechten te geven op deze database.

Vervolgens start je Visual Studio en configureer je de IDE en de test controller voor de webtests. Kies bij het opstarten voor de Team Test Settings om de IDE voor testprojecten te optimaliseren.

Ga vervolgens naar Tools > Options > Test Tools > Test Project in de menubalk en configureer het standaard project template:

Creëer daarna een nieuw project via File > New > Project in de menubalk en kies voor een test project.

Het project wordt aangemaakt en je krijgt een wizard voor je kiezen. Negeer deze even en configureer eerst de controller agent door te kiezen voor Test > Administer Test Controllers in de menubalk. Voer de naam van de server in het controller veld. Een enter zou het scherm moeten refreshen. Als je problemen hebt met het benaderen van de controller service, probeer deze dan een keer te herstarten. Controlleer ook of je dezelfde versies van de controller en agent gebruikt door de versie van Microsoft.VisualStudio.QualityTools.LoadTestFramework.dll te controleren. Een mismatch kan ervoor zorgen dat de agent als disconnected in de agent lijst komt:

Zoals je in het venster hierboven kan zien, zal de controller standaard de SQL EXPRESS installatie gebruiken als datastore. Als je de stappen voor het aanmaken van de LoadTest database in SQL goed hebt uitgevoerd kan je deze nu veranderen. Gebruik dus de … knop om deze te veranderen naar de juiste SQL instance:

Datapopulatie

Ik ga in deze post niet geheel uit de doeken doen hoe je een testomgeving voorziet van de juiste testdata, maar ga er nu wel kort bij stil staan.
Om goed te kunnen testen moet je een goed gevulde testomgeving hebben. Ik kies er zelf voor om minimaal 25% van de uiteindelijke datagrootte te verkrijgen. Dus voor 1TB aan uiteindelijke data, wil ik minimaal testen op 250GB testdata. Ik vul de omgeving volgens de capaciteitsplanning die vastgelegd is voor de omgeving. Als er in de Architectuur gekozen wordt voor sites van maximaal 500MB, ga ik daar niet overeen. Idem voor de grootte van de contentdatabases. Probeer zo goed mogelijk de uiteindelijke structuur van de omgeving na te bootsen. Hierbij wat tips voor het vullen van de data:

Gebruik http://www.codeplex.com/sptdatapop om sites aan te maken, en lists te vullen. Op deze site staan eveneens veel voorbeelden.
Gebruik powershell om scripts te maken om makkelijk documenten te uploaden naar document libraries. (ik zal binnenkort wat scripts delen)
Gebruik powershell om mysites te genereren.
Gebruik echte data. Probeer van de klant data van fileservers te verkrijgen.
Probeer zoveel mogelijk unieke data te gebruiken. Als het even kan alle data. Het hergebruiken van data op meerdere plekken heeft een negatieve invloed op de testresultaten bij Search tests, daar een duplicate niet zorgt voor een groeiende index, slechts voor extra pointers voor de geïndexeerde chunks. Toch kan het soms niet anders, en moet je een dataset meerdere keren gebruiken. Voor search zou je er nog voor kunnen kiezen om een externe datasource te indexeren als het mogelijk is, om toch een redelijke index te hebben voor wat search tests. Toch is dat niet helemaal hetzelfde omdat security trimming daar niet plaats vindt.
Zorg voor goed gevulde sites, maar hou je aan de capaciteits adviezen in http://technet.microsoft.com/en-us/library/cc262787.aspx . Dus geen lists van meer dan 5000 items.

Dit is het einde van deel 2. In de volgende post zal ik laten zien hoe je test scenarios aanmaakt. Tot dan!

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

mpriem — Sat, 14 Mar 2009 22:19:00 GMT

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:

Opstellen van een Testplan (5 dagen)
1. Bepalen testscenarios
2. Bepalen verwachte resultaten
3. Planning en resources vaststellen
4. Uitwerken testplan
Configureren testomgeving en test rig (5 dagen)
1. Installeren testcontroller en agents
2. Configureren testomgeving (sharepoint configuratie, aanmaken test accounts, dns etc)
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
Ontwikkelen webtests en load tests (10 dagen)
1. Maken van de test scenario's
2. Databindings maken voor webtests
3. Testen van webtests
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.
Analyse van testresultaten (2 – 5 dagen)
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: http://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: http://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.

Load Testen van Sharepoint met VSTS 2008 en VSTT Load Agents – Proloog

mpriem — Fri, 13 Mar 2009 12:15:44 GMT

Onlangs ben ik gevraagd voor een grote klant een testplan te ontwikkelen voor een nieuwe omgeving in ontwikkeling. Daar ik in het verleden wel wat testplannen had geschreven voor Exchange en ook wel wat IIS testen had gedaan, dacht ik dat wel even te doen. Op dat moment stond ik net op het punt te vertrekken naar Amerika voor een intern event, waar een van de senior architecten van ons Sharepoint Online platform een presentatie zou houden over het load testen van Sharepoint. Na deze sessie stond ik weer met beide benen op de grond. Het "Dat doe ik wel even" gevoel had plaatsgemaakt voor "HELP, dat is ingewikkelder dan ik dacht". Nu schuw ik een uitdaging nooit, dus vol goede moed ben ik aan de slag gegaan, en uiteindelijk pakte het zeer goed uit. De komende reeks posts zal ingaan op hoe een test voor te bereiden en uit te voeren, gebruik makend van Visual Studio Team System 2008 Test Edition en de Visual Studio Team System 2008 Load Agents.

Het eerste deel zal gaan over de vereisten voor een gedegen test en opstellen van een basisplanning. Het tweede deel zal vervolgens ingaan op de installatie van de test machines (de controller en load agents). Het derde deel zal ingaan op het ontwikkelen van de test scenario's en het bundelen van deze scenario's tot een load test. In het laatste deel behandel ik het uitvoeren van een load test.

Hou daarom de komende weken deze blog in de gaten…

February Uber Packages zijn uit

mpriem — Tue, 10 Mar 2009 11:54:00 GMT

Zoals onderhand wel bekend is, is het patchbeleid veranderd voor Sharepoint patches. Er wordt vanaf December om de 2 maanden een rollup pack uitgebracht en eventuele tussentijdse critical (security) updates. Ook zijn de localized versies van de patches er niet meer. Alle localized MSPs en global MSPs zitten nu in 1 Uber package voor WSS en 1 package voor MOSS.

De februari releases zijn onlangs vrijgegeven en kunnen gevonden worden op:

February Cumulative Update Uber Package for Windows SharePoint Services 3.0 (Version: 12.0.6341.5000)

http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=961755

February Cumulative Update Uber Package for Microsoft Office SharePoint Server 2007 (Version: 12.0.6341.5002)

http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=961756

Virtualisatie support voor Sharepoint Server en SQL server producten

mpriem — Sat, 08 Nov 2008 16:11:00 GMT

Gisteren ben ik terug gekomen van een 60+ uur durende critsit bij een klant in Oostenrijk, waar zij MOSS in single-server configuratie op VMWare Server (dus de gratis versie… In productie J ) draaien op 40+ locaties.

Gedurende deze critsit kwam ik, zoals vele malen eerder, in de discussie terecht over het support van Microsoft op VMWare producten. Dit is de aanleiding dat ik het nu luid en duidelijk probeer neer te zetten in deze post.

Microsoft heeft beperkte support op niet-microsoft hardware virtualisatie producten voor onze Windows Server besturingssystemen. Dit houdt in dat wij FULL support leveren op onze eigen producten en alle producten die onder het Server Virtualization Validation Program (SVVP) (http://go.microsoft.com/fwlink/?LinkId=125649&clcid=0x409).

Op dit moment zijn dat:

Cisco WAAS Virtual Blades 4.1.1
Citrix XenServer 5 Embedded Edition
SUSE Linux Enterprise Server 10 SP2
VMware ESX 3.5 Update 2
XenServer 5

Naast het FULL support leveren wij BEST EFFORT support voor PREMIER klanten voor producten die niet onder het SVVP vallen. Let wel, dit is dus best effort, en alleen voor klanten met een premier contract, en alleen voor Windows Server besturingssystemen.

http://support.microsoft.com/kb/897615

Voor onze Server applicaties gelden aparte regels. Elk product team kan zelf bepalen wat deze regels inhouden.

Voor Sharepoint en voor SQL server zijn deze als volgt

http://support.microsoft.com/kb/909840

http://support.microsoft.com/KB/956893

Uiteindelijk bleek het probleem dus ook mede veroorzaakt te worden doordat SQL gevirtualiseerd was en de VM problemen had met de hardware klok en 461 identieke items aanmaakte in de database wanneer er een workflow gestart werd.

Sharepoint updates

mpriem — Wed, 04 Jun 2008 17:47:00 GMT

Voordat je hotfixes of service packs wilt installeren voor Sharepoint....

Volg altijd eerst de volgende artikelen:

Deploy software updates for Windows SharePoint Services 3.0
http://technet2.microsoft.com/windowsserver/WSS/en/library/91649a7e-6b5a-4e5a-9ee5-51951f4b857f1033.mspx

Deploy software updates for Office SharePoint Server 2007
http://technet2.microsoft.com/Office/en-us/library/f484f5f2-35bb-4d70-bf56-dd1c4c287c721033.mspx

Succes.