1

Load Testing Guide

The following table is a high level guide to help with delivering an effective and efficient load/performance testing project:Description
Always ensure that the test environment is a mirror of the live !f this is not possible then ensure that the servers" etc are scalable or have a #uantifiable performance measure compared to the live bo$es or components %un one functional test machine at the same time the load is being generated (nsure that the workload model is derived from business users" transaction logs or similar )real life* activities Take account of peak times and transactions including end of year/period +apture any background processes that the user e$periences ,whether knowingly or not(nsure the Load/0erformance test tool is able to simulate 1223 of the anticipated user community Typical per virtual ,4T bo$- memory re#uirement is 1mb Try not to go much above 255 virtual users a bo$ ,however this depends on the Load Test product and test machine configuration- This would re#uire 255mb to service the virtual users" at least 62mb for the operating system and more for any other applications that may reside on the bo$ ,this should be kept to a minimum- (nsure the test clients will not be a bottleneck by checking the +0/ utilisation per test client !f the average is above 723 then the test client will be a bottle neck" reduce the amount of virtual users that client runs 8ual processors will typically give a 95 : 753 performance gain Try to have a 1;< monitor and a graphics card with =mb> This helps with monitoring several machines" reports" graphs" etc 12=mb of memory should be sufficient (nsure that the 0+ has ade#uate hard disk space due to the amount of data that can be collected during tests 8on*t run virtual users on the controller 0+ (nsure that there is sufficient bandwidth on the LA4 to run all the virtual users An e$ample would be if the average amount of data being submitted ,including images- by a virtual user was 22k and the test had to simulate a user community of 225 ,concurrently-" then the bandwidth re#uirement would be a minimum of in e$cess of 9mb/s 4ote no network Topology will be 1553 efficient in fact as clients increase on a LA4 segment the available bandwidth can drop to below 253 @o in this case a 15mb hub would not be sufficient !t is preferable to use a switch as this does not share the available bandwidth between clients !n most cases a 155mb switch will be sufficient (nsure that all test machines have 155mb 4etwork !nterface +ards ,4!+There are various resources that may be used to monitor system performance All load test tools will usually have an array of performance monitors or have access to the servers under tests own monitors Aowever to reduce network traffic it is best to only use basic monitors as supplied by the load tools These include response times ,transactions-" this has no network overhead as it measures the round-trip time of selected transactions 4ote: %esponse times do not usually include the time it takes the browser to render the returned response ,which can include several images- To measure this at least one test client should be included in the test to carry out functional tests while the system is under load This client should be built to the same specification as those in the live environment Also network/node-based monitors should be used to give a general indication of which segment of the system caused the most delay 'onitors should be set up on the local machine,s- as prescribed by system specialists !n some cases the tester may want to remotely monitor these on their machine" this can be achieved by using emulation software such as ($ceed or .4/ ,.4/ is free- (ach monitor that you run will degrade the performance of the machine it is run on This performance hit will be small but it should be known so that an account can be made of it in the test results Bou may get an estimate of this by closing all noncritical processes on the server and then run the monitor and see what the +0/ utilisation is with the monitor on and then what it is with it off The hit is ,appro$imately- the difference &hen a client opens a connection to a web server this is known as a session &hile the client continues to send and receive responses from the server" the session is maintained by a session !8 @essions can be maintained by a variety of methods !t is crucial to performance testing web-based applications to ascertain how the web server/application identifies the session as this will need to be used in subse#uent tests 8on*t use random number generators to produce uni#ue id*s for log on" etc as inevitably ,especially where e$tended tests are concerned-" it will generate two numbers that are the same !n any ATT0 traffic between client and server the C(T and 0D@T functions are the most important /se 'ean and @tandard 8eviation in preference to 'in and 'a$ values when analysing results 'in and 'a$ values are normally known as outliners and can skew results /sers are not normally concerned if once in a while they get a response time that is less than e$pected Aowever what does concern users is what the performance is )normally* Cet as much information as is possible Take your time to analyse the results with system specialists and rerun tests to confirm your findings

Term
Like Live &orkload 'odel .irtual /sers Load Test clients

+ontroller

?andwidth

'onitors

Load Test @cripts

Test %esults