An explanation will be posted next week.
In a previous article we went over variable extraction using Neoload. This article will cover how to use and update the extracted variables within a loop.
Here is the use case we will script:
Lets begin by recording the page in Neoload and setting up the extraction. In the variable extractor we will extract all occurrences that match our pattern.
Neoload automatically creates a ‘variablename_matchNr’ variable that contains a count of instances extracted. Since the name of our variable is extract_zipcode each instance that matches our pattern is saved as ‘variable_name_instance’ or extract_zipcode_1, extract_zipcode_2 and so on.
Continue reading
What can you tell from the below graph?
Let’s start with the obvious observations:
Now let’s look at what a performance engineer would focus on:
Both hits per second (hits/s) and throughput stopped increasing after the first minute of the test. Normally these would increase in line with virtual users This indicated that a bottleneck or choke point has been reached. As virtual users were added the hit rate and throughput did not increase. As you would expect response times just increased as more virtual users were added since the system is at capacity. You can also predict that if you add more users only response times will climb.
Common causes for this type of situation:
This calculator was created to assist performance test engineers with creating an initial load profile with a performance testing tool.
The calculator will give you:
All this data is critical in moving a load profile into a test scenario. Based on your smoke test results this calculator gives you a way to calculate VU counts for your full load profile.
Launch the virtual user calculator
The below image shows a screenshot of the calculator. 
Continue reading
Use Case / Script - These represent a user ‘path’ through a web application. An example could be searching for a product or booking a ticket.
VU – Virtual User - This refers to users simulated by load testing tools. Virtual users are controlled by scripts following specific use cases. These virtual users normally loop through your use cases for a set duration.
Iteration - An iteration is a single completion of a use case by a single VU (virtual user). A single VU will can complete multiple iterations over a time period. This can be measured by how many times a VU hits the last transaction or page is your use case.
Transaction - A transaction is the measurement of a logical piece of work being completed by virtual users. Many items can be defined as a transaction. A transaction can be an entire script, a page view, a search or a user login.
Continue reading
Challenge: Your scripting path brings you to a page that has multiple drop-down lists with similar source structure. You need to randomly select a value from both lists what will be used later in the script.
If you view the source of this page you will see that it has 2 drop down lists. The values in each are structured in the following way: <option value=”ABCD”>ABCD</option>.
The other day I decided to test the performance of my SSD (solid state device) against the performance of the hard drive in my home desktop. As expected the SSD device performed much better than the hard disk. I was surprised to find that the performance of the hard disk was different as you move across the disk. A little time on Google and I found three interesting facts.
You will encounter situations when you are asked to test an application / websites that will have unknown usage. Common situations causing unknown usage are first year applications or increased marketing for an application.
The purpose of this article is to give performance engineers a starting point to create a load profile (used in testing) based on incomplete production usage or projections.
You are asked to test an eCommerce application. Your are given the following data on projected production usage:
Continue reading
After some tweaks we were able to run 5000 users on a single load generator with the Neoload 64-bit agent (v3.2.4) for windows on both Windows 2008 R2 64-bit and Windows 7 64-bit.
From past experience we have observed that 1 simple http/html user in Neoload uses 2-3 MB of memory. To meet our target of 5000 VUs per load generator we build out the load generators to have 12 GB of Ram. 2 GB was allocated for the OS and the other 10 GB was allocated for the Neoload JVM. Next you have to configure Neoload to use the 10 GB of memory.
This applies to LR 11.x and LR 9.x using the web (http/html) protocol.
Sometimes it’s necessary in loadrunner to capture a large amount data with a web_reg_save_param function. Let’s say we want to capture an entire page response into a param for data extraction.
