DougHughes.net

As a follow up to my previous post about Apache’s Jmeter, today I will go over using the Jmeter proxy component to record your activities in Firefox and make a test plan. First thing we need to keep in mind as we build this plan, is our goal of actually simulating users. Sure, we could spin up a simple http sampler, setup a 40 thread group, and tell it to loop 100 times, but would this really simulate user load?  Real users have pauses between their actions, they may use your site search with a variety of keywords, or they may just wander aimlessly.  You also may notice trends in your log files, where you have 2 or more different general types of users. Lets setup a scenario today to simulate 2 of your theoretical user groups defined as follows:

Your site has an average of 100 concurrent users 65% of your users follow scenario A 35% of your users follow scenario B

     Lets start with a new test plan, and the first thing we want to do is to create thread groups to represent our different scenarios. Right click your test plan (root element), add -> thread group. Name the first group ‘Scenario A’, and set it to 65 threads, 15 second ramp up, and repeat forever. Setup another thread group called ‘Scenario B’, set it to 35 threads, 15 second ramp up, and also repeat forever. Next, lets add the proxy server by right clicking on your workbench (root object), choose ‘Non Test Elements’, then choose the ‘HTTP Proxy Server’. I set the server to listen on 8085 (any open port should work fine), and I chose the type of ‘HTTP Request HTTPClient’
. Now under ‘Target Controller’, choose ‘Test Plan > Scenario A’, and under grouping choose ‘Put each group in a new controller’. This tells the proxy server to simulate a connected browser, place all recorded requests under the Scenario A thread group, and to group each page request into a controller (just makes it easier to follow what is going on in the plan). Now press start, and lets switch to firefox.     You need to set Firefox to use your new proxy server.  Go to preferences -> Advanced -> Network -> Settings. Set firefox to connect for HTTP or HTTPS to localhost, on port 8085 (or whichever port you chose). Be sure to remove anything from the ‘no proxy for’ input box if you are testing locally, or this wont work =)   Now you are ready to perform your actions that will represent a user in Scenario A. Browse the site of your choice (I will be picking on Adobe.com for this test, please don’t everyone run out and run 100 threads against Adobe, I may become un-popular). Carefully perform only the actions that you want to be replicated in your test, then switch back to Jmeter and turn off the proxy to ensure no additional rogue web requests get captured. You should now have something that looks like this (I named my controllers just to make it easier to follow my plan).                         Now go back into your proxy object, configure it to record actions to the controller ‘Scenario B’. Restart the proxy and perform some other browsing actions that a typical user may do. Now we are ready to apply some ‘realistic’ touches to our test plan here. Looking at your test plan, you now see several controller groups under your ‘Scenario A’, each of which represents a web action.  As I am sure you know, when you click on a link or go to a web page, often times other pages or assets get loaded. Each sampler (they look like an eyedropper) under the controller represents an actual HTTP request that occured during the action you recorded.  Now, we want to add some human randomness here, because a machine slamming in web requests every 1 ms is really not a realistic test of your servers!Right click on an individual sampler object, choose ‘add timer’, then ‘add gaussian random timer’. Set your ‘constant delay offset’ to 2000 ms, then set the deviation to 1000 ms.  This will add a random delay to each action, in the range of 1000ms – 3000 ms (one to three seconds), which will more accurately represent a real person browsing your site.Now all that is left to do is add your listener elements, and run your tests! Remember, for good testing you always want to first get a baseline with your test of current performance, then test after making any site modifications. One of the hardest parts of creating a test is accurately modeling your real traffic. Search through user feedback, apache logs, google analytics exit logs, any data you can get to help you decide how you construct your test plan. The plan will do you no good at all if its not ‘real world’!Next time, I will discuss adding csv config elements so that user actions can pull search or post criteria from a file.