Testen van applicaties met veel gebruikers
steeds noodzakelijker
Belastingtests
brengen prestatieproblemen vroegtijdig aan het licht
De huidige client/server-applicaties moeten in staat
zijn duizenden gebruikers tegelijkertijd te bedienen.
En dat zonder aan betrouwbaarheid en/of snelheid in
te boeten. Maar hoe weet je op voorhand dat dat zo
is? Door de applicatie aan een zgn. 'load test' te
onderwerpen. In dit artikel wordt uit de doeken gedaan
wat een load test inhoudt, hoe een dergelijke testtool
is opgebouwd, wat ervoor nodig is en hoe je zo'n test
uitvoert.
Als voorbeeld nemen we een website van een boekverkoper.
Hier spelen onder meer de processen gerelateerd aan
het zoeken naar boeken, het bestellen van boeken en
het creëren van een account, een belangrijke rol.
Deze businessprocessen moeten geïdentificeerd en getest
worden in een omgeving die de werkelijkheid van straks
goed simuleert. Dit betekent dat de diverse processen
onder wisselende belasting (gebruikers die tegelijkertijd
de applicatie benaderen) worden getest. Er moet namelijk
zeker gesteld worden dat de prestaties onder alle
omstandigheden voldoen aan de verwachtingen en dat
knelpunten in de IT-infrastructuur tijdig worden gesignaleerd.
De ontwikkelaars leren zo hoe de applicatie 'schaalt'
met een toename van het aantal gebruikers en zullen
mede hierdoor in staat zijn problemen ten aanzien
van de prestaties te reproduceren. Verder zijn de
gegevens van tests onder belasting van groot nut bij
het specificeren van Service Level Agreements (SLA's).
Het testscenario
Om een dergelijk testscenario uit te kunnen rollen,
moet er dus een mechanisme zijn dat een groot aantal
gebruikers nabootst. Voor het opzetten en uitvoeren
van zo'n belastingtest zijn de volgende stappen nodig:
1. De businessprocessen moeten worden geïdentificeerd.
2. De businessprocessen moeten worden omgezet in code
(een script) om het proces te kunnen automatiseren.
Dit script kan worden geschreven en gegenereerd in
C, in perl, in java of in Visual Basic. Ieder script
representeert de actie van één gebruiker, die een
bepaald businessproces gebruikt.
3. Meerdere kopieën van deze scripts kunnen vervolgens
worden ingezet om een groot aantal gebruikers na te
bootsen.
4. Een aparte taak zorgt voor de coördinatie van het
testschema en het beheer van het aantal scripts dat
kan worden gedraaid. Door het op te slaan als een
scenario kan ook dit schema weer worden geautomatiseerd.
5. Een derde component wordt gebruikt om de belastingtest
te kunnen analyseren. Daarbij wordt gekeken naar de
resultaten die door de scripts worden geproduceerd
en worden rapporten gecreëerd. Het analyseprogramma
kan ook resultaten vanuit andere componenten (zoals
System Monitoring) gebruiken, om zo tot een zeer informatief
rapport te komen.
Voor de uitvoering van de bovengenoemde acties, zijn
speciale 'load testing tools' beschikbaar. In dit
artikel wordt uitgegaan van 'LoadRunner', een pakket
dat door Mercury Interactive op de markt wordt gebracht.
Testtools van andere fabrikanten zijn echter volgens
een vergelijkbare architectuur opgebouwd.
De onderstaande figuur toont de architectuur nodig
voor de opzet van een belastingtest. De hoofdcomponenten
hierin zijn:
• de scriptgenerator,
• de controller,
en
• het analyseprogramma.
De scriptgenerator
Dit programma genereert de scripts waarin de businessprocessen
zijn opgenomen. Wanneer het businessproces eenmaal ingevangen
is, kan het script in iedere gewenste taal worden gegenereerd.
Belangrijk is dat de opname niet indringbaar is, zodat
de ingevangen informatie niet wordt beïnvloed door het
opnameproces zelf.
Oracle
2-tier
Afhankelijk van de gebruikte protocollen, zijn er verschillende
technieken voor het invangen van de informatie. In een
Oracle 2-tier applicatie kan de client-applicatie worden
gemonitord door API-hooking te gebruiken. Deze benadering
wordt in de industrie veel gebruikt voor het monitoren
van calls, gemaakt door een Win32-applicatie. Wanneer
deze informatie is ingevangen, wordt een script gegenereerd.
In het script staan additionele stukjes informatie,
die helpen bij het identificeren van de start en het
einde van een businessproces. Onderstaande figuur toont
hoe een script eruit zou kunnen zien wanneer opgenomen
wordt vanuit de Oracle 2-tier applicatie SQL*Plus.
[Begin code box]
dbfunc1()
{
db_init(&init);
// Defines the start of a business process
// There can be more than one business process in a
script. start_businessprocess("selectemp");
db_open_connection(&conn, "ddalton", "password", "TNSORACLE");
db_select_stmt(&conn, "SELECT * FROM EMPLOYEE", &results1);
db_select_stmt(&conn, "SELECT count(*) FROM user_tables",
&results2);
db_close_connection(&Conn);
// defines the end of a business process
end_businessprocess("selectemp");
return OK;
}
[Einde code box]
[Begin code box]
appfunc1()
{
start_businessprocess("navigate");
app_open_connection("123.123.123.123", "9002", "module=
/u0/oracle/visappl/fnd/11.5.0/ forms/US/FN");
// Expand the Bank Reconciliation item
set_window("Navigator - Cash Management, Vision Payroll
(USA)");
list_activate_item("NAVIGATOR_LIST_0","+ Bank Reconciliation");
// Exit the client application by selecting File->Exit
menu_select_item
("N","File;Exit Oracle Applications");
popup_message_press("Caution","OK");
end_businessprocess("navigate");
return OK;
}
[Einde code box]
De bovenstaande scripts zijn gegenereerd in C, maar
kunnen ook (opnieuw) worden gegenereerd in andere talen,
voorzover die door de scriptgenerator worden ondersteund.
Deze benadering is niet exclusief voor SQL*Plus, maar
kan voor iedere Oracle-client worden toegepast. Het
kan bijvoorbeeld een 'maatwerk' client-applicatie zijn,
met veel gebruikers binnen de organisatie. Zodra de
gewenste scripts zijn gegenereerd, kan de controller
deze gebruiken om een situatie na te bootsen waarin
een groot aantal gebruikers de Oracle-database benadert,
terwijl deze de opgenomen businessprocessen uitvoert.
Oracle 3-tier
Ditzelfde mechanisme kan worden uitgebreid om ook Oracle
3-tier applicaties onder belasting te testen. Vandaag
de dag draaien de meeste applicaties via het web. De
scriptgenerator moet dus flexibel genoeg zijn om op
te nemen tegen webbrowsers en moet de protocollen die
in de communicatie worden gebruikt, kunnen begrijpen.
Figuur 3 toont hoe de gegenereerde code er uit zou kunnen
zien, wanneer deze wordt opgenomen tegen deze applicatie.
De functies die in het script worden gebruikt zijn onderdeel
van een API, die door de tool wordt ondersteund. Deze
functies zijn in staat de feitelijke gebruikersinteractie
met de client-applicatie na te bootsen.
De businessproces-functies (start_ businessprocess en
end_businessprocess) worden gebruikt om te meten hoe
lang het duurt om de stappen tussen de start- en end-functies
te doorlopen. Foutmeldingen die in deze stappen worden
gegenereerd worden vastgelegd (opgenomen) voor meldings-
en rapportagedoeleinden.
De API zelf is zodanig ontworpen, dat deze nauwelijks
bijdraagt aan de overhead. Om zeker te stellen dat de
handmatige scherminvoer op de juiste manier wordt geëmuleerd,
is het wel noodzakelijk dat de scriptgenerator-API gebruikmaakt
van dezelfde libraries als de client-applicatie. Ieder
script representeert de actie van één gebruiker waardoor
het script kan worden gezien als één virtuele gebruiker.
De controller
Dit programma wordt gebruikt om scripts over verschillende
'agents' uit te rollen. Een 'agent' is een machine die
één of meer verzoeken van een script draait, om de situatie
te simuleren waarbij een groot aantal gebruikers hetzelfde
businessproces uitvoert. De controller coördineert het
proces waarin onder meer wordt besloten hoeveel scripts
moeten worden gedraaid, met welke snelheid het aantal
scripts toeneemt, hoe lang de belastingtest zal duren,
enzovoort.
De agents sturen de resultaten van de virtuele gebruikers
terug, terwijl ze tegen de bedrijfsapplicatie draaien.
Het is tevens noodzakelijk de bedrijfsapplicatie te
monitoren om te kunnen peilen hoe deze zich gedraagt
ten opzichte van de belasting. Ook deze data wordt aan
de controller aangeboden, zodat een beter beeld ontstaat
van het gedrag van de volledige applicatie-infrastructuur.
Hoe beter het monitoren gebeurt, des te meer bruikbare
informatie de belastingtest zal opleveren. In een complexe
bedrijfsomgeving bijvoorbeeld, zal een hardware-infrastructuur
met load-balancers, routers, proxies, caching devices,
SSL-versnellers, disk arrays en dergelijke bestaan.
Daarnaast is er natuurlijk ook nog de software-infrastructuur,
met databases, J2EE applicatieservers, enzovoort. De
complexiteit van dit geheel maakt de aanwezigheid van
een goed gedefinieerd monitoring-mechanisme noodzakelijk.
Wanneer gedurende de test een probleem naar voren komt
— zoals het plotseling oplopen van de responsetijd
voor een businessproces — kan de monitoringdata
worden gebruikt om te achterhalen welk component hiervoor
verantwoordelijk was en kunnen knelpunten al vroeg in
het proces geïdentificeerd worden. De volgende figuur
geeft een idee van hoe een controller eruit zou kunnen
zien. In een venster worden de scripts die deel uit
maken van het scenario getoond, waarbij ook de actuele
status wordt weergegeven. De verschillende grafieken
tonen real-time data van iedere monitor.
Aan het eind van de test laat de controller de verzamelde
resultaten analyseren door het analyseprogramma, dat
tevens rapporten creëert.
De analyse-tool
De analyse-tool wordt gebruikt om de enorme hoeveelheid
data van de belastingtest samen te vatten, om van daaruit
grafieken en rapporten te genereren die de prestaties
van het systeem weergeven.
Hetzelfde tool kan worden gebruikt om verschillende
grafieken samen te voegen, waardoor de prestaties van
de infrastructuur nog duidelijker in beeld kunnen worden
gebracht.
Conclusie
De besproken tools vormen een integraal onderdeel van
een belastingtest-systeem. Het beschikken over een dergelijk
systeem maakt het mogelijk om prestatieproblemen aan
het licht te brengen, voordat de applicatie in productie
gaat of uitgeleverd wordt. LoadRunner van het Amerikaanse
Mercury Interactive is een van de tools die alle ideeën
implementeert die in dit artikel besproken werden. Dit
bekende en breed geaccepteerde test-tool is gebruikt
om de 'Oracle Applications standard benchmark' te creëren.
Deze benchmark is bereikbaar via:
www.oracle.com/apps_benchmark/
content.html.
|
