• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Fundamentals of jmeter
 

Fundamentals of jmeter

on

  • 9,435 views

 

Statistics

Views

Total Views
9,435
Views on SlideShare
9,435
Embed Views
0

Actions

Likes
7
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Fundamentals of jmeter Fundamentals of jmeter Document Transcript

    • Apache JMeter Manual Fundamentals of Apache Jmeter Author: Atul & Prerana Contact: Atul Bangalore, India Phone: 7760527730 Email: jmeter4u@gmail.com Web: www.jmeter4u.com
    • Table of Contents Chapter 1: Introduction ................................................................................................................................ 4 Overview of Performance Testing ............................................................................................................ 4 Purpose of Performance Testing .............................................................................................................. 4 Key Types of Performance Testing............................................................................................................ 4 Performance Management ....................................................................................................................... 5 Performance Testing Life Cycle ................................................................................................................. 6 Why to use performance Testing tool? .................................................................................................... 6 Performance Symptoms and Issues .......................................................................................................... 6 Challenged with Performance Testing ...................................................................................................... 7 Chapter 2: Get Started .................................................................................................................................. 8 What is Jmeter? ........................................................................................................................................ 8 What is Jmeter? ........................................................................................................................................ 8 Installing Jmeter ........................................................................................................................................ 8 Setting up Environment ............................................................................................................................ 9 Running Jmeter ......................................................................................................................................... 9 Chapter 3: Introduction to Elements of Jmeter Test Plan .......................................................................... 10 Test Plan .................................................................................................................................................. 10 Thread Group .......................................................................................................................................... 10 Controllers............................................................................................................................................... 11 Samplers.................................................................................................................................................. 11 Logic Controllers ..................................................................................................................................... 12 Listeners .................................................................................................................................................. 12 Timers ..................................................................................................................................................... 13 Assertions................................................................................................................................................ 13 Configuration Elements .......................................................................................................................... 14 Pre-Processor Elements .......................................................................................................................... 14 Post-Processor Elements ........................................................................................................................ 15 Chapter 4: Building a Web Test Plan........................................................................................................... 16 Adding Users ........................................................................................................................................... 16 Adding Default HTTP Request Properties ............................................................................................... 17 Adding Cookie Support ........................................................................................................................... 17 © Jmeter4u Page 1
    • Adding Http Requests ............................................................................................................................. 18 Adding Post-Processor for Correlation ................................................................................................... 18 Adding a Listener to View/Store the Test Results .................................................................................. 19 Chapter 5: Load/Performance Testing of Websites.................................................................................... 20 Preparing for Load Testing ...................................................................................................................... 20 Need to Know ......................................................................................................................................... 20 Some Helpful Tips to Get Better Results ................................................................................................. 20 Using Jmeter Components ...................................................................................................................... 21 Recording HTTP Requests ....................................................................................................................... 21 Creating the Test Plan ............................................................................................................................. 26 Adding Listeners...................................................................................................................................... 28 Running the Test Plan ............................................................................................................................. 29 Interpreting the Results .......................................................................................................................... 29 Monitoring the Server's Performance .................................................................................................... 31 Chapter 6: Handling the Dynamic Server Values ........................................................................................ 33 What is Correlation ................................................................................................................................. 33 Why Correlation ...................................................................................................................................... 33 Using Regular Expression Extractor in Jmeter Tests ............................................................................... 33 Chapter 7: Parameterize with test data ...................................................................................................... 35 What is Parameterization ....................................................................................................................... 35 Why Parameterize .................................................................................................................................. 35 Identifying the test data on AUT ............................................................................................................. 35 Using the CSV Data Config in Jmeter Tests ............................................................................................. 35 Chapter 8: Adding Assertions to the test script .......................................................................................... 39 What is Assertion? .................................................................................................................................. 39 Why Assertion? ....................................................................................................................................... 39 Types of Assertion in Jmeter ................................................................................................................... 39 Running the tests and analyzing the Assertion results ........................................................................... 40 Chapter 9: Advanced Features .................................................................................................................... 42 Testing a Database Server....................................................................................................................... 42 Testing an FTP Server .............................................................................................................................. 43 Chapter 10: Best Practices .......................................................................................................................... 45 © Jmeter4u Page 2
    • Limit the Number of Threads .................................................................................................................. 45 Using Cookie Manager ............................................................................................................................ 45 Using the Authorization Manager........................................................................................................... 46 Reducing resource requirements............................................................................................................ 46 Bean Shell Server .................................................................................................................................... 47 Distributed Testing .................................................................................................................................. 47 Sever Monitoring Tools (PerfMon) ......................................................................................................... 49 Database Monitoring Tool (Jet Profiler) ................................................................................................. 50 © Jmeter4u Page 3
    • Chapter 1: Introduction Overview of Performance Testing Performance testing is a type of testing intended to determine the responsiveness, throughput, reliability, and/or scalability of a system under a given workload. Performance testing is commonly conducted to accomplish the following:      Evaluate against performance criteria Compare performance characteristics of multiple systems or system configurations Find the source of performance problems Support system tuning Find throughput levels Purpose of Performance Testing Performance Testing ensures that your application works under real-world loads before your customers find out that it doesn't! Key Types of Performance Testing Performance Test Purpose: To determine or validate speed, scalability, and/or stability. Load Test Purpose: To verify application behavior under normal and peak load conditions. Stress Test Purpose: To determine or validate an application’s behavior when it is pushed beyond normal or peak load conditions. Endurance Test Purpose: To determine the performance characteristics of the product under test over an extended period of time. Volume/Capacity Test To determine how many users and/or transactions a given system will support and still meet performance goals. Scalability Test To measure system performance while steadily increasing user load. © Jmeter4u Page 4
    • Performance Management There are two approaches of managing the performance testing activities, either after the development of the complete application after the system testing (Reactive Approach) or doing the performance testing throughout the Software Development Life Cycle (Proactive Approach). Both approaches have their advantages and disadvantages listed below. Reactive Approach Performance Testing is most often approached in a reactive way where performance testing is only done after the System testing. Advantage  Cost effective Disadvantages  Difficult to resolve the performance bottlenecks after the complete development.  Defect removal cost is exponentially increased.  Whole system can be useless. Proactive Approach In proactive approach every performance parameter is analyzed and addressed in testing environment before it really impact the production system and fix it before launching the application. Following activities are performed in each phase of the Software Development Life Cycle (SDLC). Non-functional requirements gathering phase - Start thinking of performance goals. Design phase - Define system performance matrices and their explicit goals. Development phase - Frequently perform performance testing on partially complete features to validate defined performance goals. Test Execution phase - Perform detailed performance testing to verify systems performance goals. Maintenance - Run a performance testing cycle after specific interval and also with every new release to validate the system performance. Advantage  Lower performance bottleneck mitigating cost.  All performance bottlenecks are resolved before launching the application.  Complete peace of mind and confidence before launch. Disadvantages  More cost associated with performance testing activities when they are exercised in each phase of the SDLC. © Jmeter4u Page 5
    • Performance Testing Life Cycle 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Establish Performance Test Objectives Prepare test environment Baseline the database(s) Create and modify scripts Execute Performance test Monitor impact of load on servers/databases Analyze results Tune system Repeat Deploy mission critical application with confidence Why to use performance Testing tool?  Performance testing is almost impossible without one!  Performance testing without a tool relies on massive hardware and personnel to generate load, generally with wildly inaccurate results.  Without a tool, no end reports are created.  Reponses Time  CPU Utilization  Disk I/O  Network I/O  Other  The cost of repeating a 'manual' test never diminishes. When using a performance testing tool, costs go down as you repeat your tests. Performance Symptoms and Issues Performance bottlenecks could appear on various areas of the applicationinfrastructure. Following is the list of performance symptoms that could appear at various levels of an application. Symptoms of web application performance problems          Long response time Memory leaks High CPU usage Too many open connections Length queues for requests Too many table scans of database Database deadlocks HTTP errors Pages not available © Jmeter4u Page 6
    • Typical database problems     Insufficient indexing: Tune database indexing to improve query processing Fragmented databases: Place table records into adjacent pages Out-of-date statistics: Degrade query optimizer performance Faulty application design: Excessive DB calls, excessive data requests Typical Web Server problems  Poor server design: Inefficient data or page caching  Memory problems: Physical memory constraints Typical app server problems     Poor database tuning: Application server sending too many DB requests Poor cache management: Produces high CPU usage, disk access Poor session management: Produces high CPU usage, disk access, Time-outs Poor security design: Excessive use of https protocol Network problems     Potential sources of network problems: Firewall throughput Internet access throughput Load balancers, gateways, routers Challenged with Performance Testing Conducting a successful performance test is not a piece of cake. There are many challenges that you need to successfully face to conduct a successful performance test. Following is a list of these challenges:           Test environment setup Collection and Analysis of huge data Bottleneck root cause identification Cooperative effort required (Product vendors, Architects, Developers, Testers, Database administrators, System administrators, Network administrators) Obtaining accurate results Client involvement Testing inside the firewall Performance testing of new technologies Testing on live environment Expensive © Jmeter4u Page 7
    • Chapter 2: Get Started What is Jmeter? The Apache JMeter desktop application is open source software, a 100% pure Java application. It may be used to test performance both on static and dynamic resources such as static files, Java Servlet, CGI scripts, Java objects, databases, FTP servers, and more. JMeter can be used to simulate a heavy load on a server, network or object to test its strength or to analyze overall performance under different load types. What is Jmeter? Jmeter tests all kind of application (not only Java)         Web Application SOAP Web Services, REST, XML-RPC JAR files LDAP Databases (via JDBC) JMS SMTP FTP Installing Jmeter The easiest way to begin using JMeter is to first download the latest production release from (http://jmeter.apache.org/download_jmeter.cgi) and install it. To install a release build, simply unzip the zip/tar file into the directory where you want Jmeter. The installation directory structure should look something like this (for version 2.7): Apache-jmeter-2.7 Apache-jmeter-2.7/bin Apache-jmeter-2.7/docs Apache-jmeter-2.7/extras Apache-jmeter-2.7/lib/ Apache-jmeter-2.7/lib/ext Apache-jmeter-2.7/lib/junit Apache-jmeter-2.7/printable_docs You can rename the parent directory (i.e. apache-jmeter-2.7) if you want, but do not change any of the sub-directory names. © Jmeter4u Page 8
    • Setting up Environment Jmeter have simple environment: Jmeter Master Jmeter Slave - 1 Jmeter Slave - 2 Jmeter Slave - 3 Jmeter Slave - 4 Application under Test (AUT) Running Jmeter To run JMeter, run the jmeter.bat (for Windows) or jmeter (for Unix) file. These files are found in the bin directory. After a short pause, the JMeter GUI should appear. There are some additional scripts in the bin directory that you may find useful.         jmeter.bat - run JMeter (in GUI mode by default) jmeter-n.cmd - drop a JMX file on this to run a non-GUI test jmeter-n-r.cmd - drop a JMX file on this to run a non-GUI test remotely jmeter-t.cmd - drop a JMX file on this to load it in GUI mode jmeter-server.bat - start JMeter in server mode mirror-server.cmd - runs the JMeter Mirror Server in non-GUI mode shutdown.cmd - Run the Shutdown client to stop a non-GUI instance gracefully stoptest.cmd - Run the Shutdown client to stop a non-GUI instance abruptly The JVM_ARGS environment variable can be used to override or set additional JVM options. HEAP settings: JVM_ARGS="-Xms1024m -Xmx1024m" jmeter -t test.jmx [etc.] © Jmeter4u Page 9
    • Chapter 3: Introduction to Elements of Jmeter Test Plan Test Plan A Test Plan defines and provides a layout of how and what to test: the web application as well as the client server application. A test plan includes elements such as thread groups, logic controllers, sample-generating controllers, listeners, timers, assertions, and configuration elements. A test plan must have at least one thread group. Test Plan User Defined Variables Here you can define static variables that allow you to extract repeated values throughout your tests, such as server names, port number, etc. For example, if you are testing an application on server www.example-jmeter.net, then you can define a variable called "server" with the value of www.example-jmeter.net. This value will replace variable "${server}" found anywhere in the test plan. Thread Group A Thread Group is the starting point of a Test Plan, and it should contain all other JMeter elements. A thread group controls the threads that will be created by JMeter to simulate simultaneous users. Thread Group © Jmeter4u Page 10
    • Number of Threads It simulates the number of user(s) or connection(s) to your server application. Ramp-Up Period It defines how long it will take JMeter to get all threads running. For example, if there are 10 threads and a ramp-up period of 60 seconds, then each successive thread will be delayed by 6 seconds. Loop Count It defines the number of times to execute the test. By default, the test is executed once but you can adjust as needed. Clicking the Forever checkbox causes the test to run repeatedly until stopped manually. Scheduler checkbox Once selected, the Scheduler Configuration section will appear at the bottom of the control panel. Scheduler Configuration Here you can set the start and end time of running the test. Once you start the test, it will not execute any elements until the start time is reached. After each execution cycle, unless the end-time is reached, in which case the run is stopped, the iteration will continue until the loop count limit. The startup delay field allows JMeter sometime before a thread is started and the duration field lets you define the duration of the whole test. The former overrides start-time, while the latter overrides end-time. Controllers JMeter has two types of Controllers Samplers These allow JMeter to send specific types of requests to a server. Samplers © Jmeter4u Page 11
    • Logic Controllers These allow you to customize the logic that JMeter uses to decide when to send requests. Logic Controllers Listeners Listeners let you view the results of the Samplers in the form of tables, graphs, trees or simple text in some log files. Listeners provide means to view, save, and read saved test results. All Listeners that save data into the same file shows the same data differently. Listeners © Jmeter4u Page 12
    • Configure button Use the "Configure" button to choose the information to write to the file for later use, or whether to save (with .jtlextension) in XML or CSV format—the latter being smaller and less detailed. This button is found in each Listener added to the Test Plan tree. Browser button Select this if you want to read and display a previously saved result. Timers It causes JMeter to pause for a certain amount of time between two successive requests that a Thread Group makes. Timer Assertions Assertions allow you to include some validation test on the response of your request made using a Sampler. They are inserted as a child component of a Sampler. Assertions © Jmeter4u Page 13
    • Configuration Elements Configuration Elements allow you to create defaults and variables to be used by Samplers. They are used to add or modify requests made by Samplers. Configuration Elements Pre-Processor Elements Pre-processors allow you to modify the Samplers in their scope. They are often used to modify the settings of a Sample Request just before it runs, or to update variables that are not extracted from response text. Pre-Processor © Jmeter4u Page 14
    • Post-Processor Elements Post-processors execute after a request has been made from a Sampler. A good way is to place them as a child of a Sampler, to ensure that it runs only after a particular Sampler, not to Sampler afterwards. Post-Processor © Jmeter4u Page 15
    • Chapter 4: Building a Web Test Plan Adding Users 1. Simply right-click on the Test Plan icon on the left panel and selectAdd |Thread Group. 2. Rename the Thread Group using a more suitable name. Let's name this Group My Users. 3. For now, we will simulate the default: one-time connection and having one user (or connection/thread). 4. Change the Ramp-Up Period to 0, meaning the User will start running immediately. If you have more than one user, having Ramp-Up Period 0 will cause all users to start running immediately and simultaneously. Adding Users Adding Users © Jmeter4u Page 16
    • Adding Default HTTP Request Properties 1. Right-click the My Users element to get the Add menu, and select Add | Config Element | HTTP Request Defaults. 2. Select this new element to view its Control Panel. 3. Rename the Element to My URL. 4. In the Server Name or IP field, enter a URL: www.mocksite.net (or any other URL that you like to use). We will leave all other values as they are. Setting the HTTP Request Default Element will cause all other Request Sampler within this My Users to access to the same server. However, it does not make requests—it simply sets the request default for this Thread. HTTP Request Default Adding Cookie Support 1. To add cookie support, simply add an HTTP Cookie Manager to each Thread Group in your test plan. 2. This will ensure that each thread gets its own cookies, but shared across all HTTP Request objects. Adding Cookie Support © Jmeter4u Page 17
    • Adding Http Requests 1. Change the Name field to "Home Page". 2. Set the Path field to "/". Remember that you do not have to set the Server Name field because you already specified this value in the HTTP Request Defaults element. Adding HTTP Requests Adding Post-Processor for Correlation 1. Add a sampler. 2. Right click on sampler add Pro-Processor. Adding Post-Processor © Jmeter4u Page 18
    • Adding a Listener to View/Store the Test Results 1. This element is responsible for storing all of the results of your HTTP requests in a file and presenting a visual model of the data. 2. Add Listeners. Adding Listeners © Jmeter4u Page 19
    • Chapter 5: Load/Performance Testing of Websites Preparing for Load Testing In preparing for load testing it is utterly important to address a number of concerns with regards to the target server under test. As load testing helps to benchmark performance behavior of a server, it is important to be able to identify the general expectations and other matters that would normally be taken into account in order to carry out a successful load testing. Need to Know As noted earlier, load testing in this matter subjects the application server to work approaching its limits. Obviously, the limits will need to be clearly defined, understood, and agreed upon by the stakeholders, namely your superior(s). In addition, performance metrics need to be clear in order to keep the performance goals in check. Important expectations as for any load testing include:  A suitable time to load-test the application, for instance when no development work is taking place on the server (load testing may cause the server to crash) and/or no other users are accessing the server (else the testing results would not yield the correct measures)  The performance metrics, accepted levels, or SLAs and goals  Objectives of the test  The Internet protocol(s) the application is (are) using (HTTPS, HTTP, FTP, etc.)  If your application has a state, the method used to manage it (URL rewriting, cookies, etc.)  The workload at normal time and at peak time. It is often advisable that any form of performance testing, inclusive of load testing, is performed on a functionally stable application, regardless of the environment where the application is located. Load testing is best done when the functionality of the Application under Test (AUT) is stable enough to yield consistent and correct results. Some Helpful Tips to Get Better Results  Use meaningful test scenarios (use cases are helpful) to construct test plans with 'real-life' test cases.  Run JMeter on a machine other than that running the application you are testing.  Make sure that the machine running JMeter has sufficient network bandwidth, so the network connection has little to no impact on the results. Also, the machine running JMeter should have enough computing power (memory, CPU) to generate load. © Jmeter4u Page 20
    •  Let JMeter Test Plan run for long time periods, hours or days, or for a large number of iterations. This may yield a smaller standard deviation, giving better average results. In addition, this practice may test system availability rate and may highlight any decay in server performance.  Ensure that the application is stable and optimized for one user before testing it for concurrent users.  Incorporate 'thinking time' or delays using Timers in your JMeter Test Plan.  Conduct tests under a monitored and controlled environment, to prevent other users from affecting JMeter results.  Keep a close watch on the four main things: processor, memory, disk, and network.  Only run JMeter against servers that you are assigned to test, else you may be accused of causing DoS attacks. Using Jmeter Components For practical and realistic reasons, we will use an existing remote server to test its performance. First of all, we will create some useful scenarios as the baseline of our test. First, we will need to determine the test cases. Generally, we will test five key scenarios: 1. Homepage 2. Keyword Search—New Visitor making a keyword search 3. Create Account—New Visitor creating an Account 4. Select a Title—Registered Visitor selecting a featured title 5. Add to Cart—Registered Visitor adding selection to cart These scenarios will be included in a single JMeter Test Plan, for simplicity reasons. Recording HTTP Requests A fast way to capture the HTTP pages of this application is to record every request made to the server. For this we will need to use a special-purpose Configuration Element: HTTP Proxy Server. Note that the Proxy Server element is only available in the Workbench element. Since Proxy Server element records any page requests, besides user requests, it will also record background requests made by the browser as modern browsers do. As we would like the Proxy element to record only requests to the target server, consider setting web filter to allow the current browser to make requests only to that server. Otherwise, unnecessary requests will only clutter your recording. You may find these web filters as an option in any Internet security tool or software currently running on your machine. © Jmeter4u Page 21
    • Run JMeter (double-click JMeter.bat from jmeter/bin folder). You will see the default Elements, which are Test Plan and Workbench. 1. Right-click on Workbench 2. Select Add | Non Test Elements | HTTP Proxy Server Add HTTP Proxy Server An HTTP Proxy Server configuration Element will appear as a child of Workbench. Bear in mind that child elements of Workbench are not saved as part of Test Plan, but you can save them separately. In the HTTP Proxy server configuration Target Controller lets you determine where the recorded requests will be placed and the Grouping option allows the recorded pages to be grouped or left as individual requests. Notice that the port we are using is the default port, following the browser setting in the next instructions. HTTP Proxy Server Next, we will change the setting of your favorite browser to access a proxy (in our case JMeter HTTP Proxy), listening to the same port. You may also use port 90 for both the browser and JMeter Proxy setting. © Jmeter4u Page 22
    • The following figure shows the setting for Mozilla Firefox: Proxy Settings Mozilla The following screenshot shows the setting for IE: Proxy Settings IE We are expecting that a single page request will make several embedded requests for images, JavaScript files, CSS files, etc. Therefore for a more managed recording, it is a good practice to create controllers that can contain the sub-requests for each request. 1. Right-click on HTTP Proxy Server 2. Select Add | Logic Controller | Simple Controller © Jmeter4u Page 23
    • Repeat so we have five Controllers, or you can simply copy and paste. Name each Controller: Homepage, Keyword Search, Create Account, Select Title, and Add to Cart. Then configure the Target Controller to HTTP Proxy Server | Homepage, while the other defaults remain. Select Target Controller Now we are ready to record our first page request. As we return to JMeter, simply press the Start button at the Element Controller, and use your browser. Remember that JMeter records all HTTP requests from the browser you are using; therefore, with all the rich browsers and with all the add-ons we have today, you might want to filter that only requests to the targeted server are allowed. You may configure your browser or firewall to do so. Click the Start button, and type the URL of the server you want to test in the Address bar. You will see that JMeter has begun to record the request to the homepage and its sub-requests into Homepage Controller. Requests Target Controller © Jmeter4u Page 24
    • Next, on the Target Controller, select HTTP Proxy Server | Keyword Search, return to the browser and type in a keyword and click search. JMeter will record the following search page and its sub-requests in the Keyword Search Controller and nowhere else. Requests another Target Controller Repeat for the Create Account, Select Title, and Add to Cart Controllers, switching to the respective Target Controllers. The final recording screenshot is as shown in the following figure: Requests of Last Target Controller Once the recording is over, we will save these by right-clicking on the HTTP Proxy Server Controller and saving it in a folder of your choice. As you will see, each request may or may not generate sub-requests for files. The caching feature of today's web browsers allows these files (*.png, *.jpg, *.css, *.js, etc.) to be stored in the browser's cache the first time they are downloaded. Unless there were changes in the main request, the browser will not make new requests for these cached files as it will simply load them from the local cache. How is this feature helpful in benchmarking the performance of an application? To iterate, this has become a test goal decision to make whether the application should be tested to evaluate performance for first-time visitors or existing visitors. If we are testing for first-time visitors, we can use the first recording to simulate first-time users. Subsequent recordings can be used to simulate existing users. © Jmeter4u Page 25
    • Alternatively, we can configure the Proxy Server Configuration Element to exclude recording of particular file type(s), as the following figure indicates URL to Exclude Subsequent recording of similar actions using the new configuration of HTTP Proxy Server will exclude the caching files. To remove elements, highlight the Controllers in the Test Plan and press delete. Creating the Test Plan We will begin by creating a single Thread Group (Users Group) that we will configure later as we expand the Test Plan. 1. Right-click on the Test Plan element 2. Select Add | Thread Group A Thread Group Element will appear. Configure the Number of Threads to 10, Ramp-Up Period to 1 second, and Loop Count to 50. If you wish, you can set the Scheduler so your test plan can run automatically on the pre-determined time and date. We want each request to target only one server, therefore, we set a request default to serve this purpose. Add to the Test Plan Config Element | HTTP Request Defaults: Add HTTP Request Defaults © Jmeter4u Page 26
    • JMeter provides this capability by Pre-Processor | User Parameter Element or Config Element | CSV Data Set Config. The User Parameter Element allows the user to specify unique values for User Variables specific to individual threads. The CSV Data Set Config element serves the same purpose; however, these values are read from lines from a file, and split into variables that later can be used throughout the life of the thread. For providing a large number of users, CSV Data Set Config would be a better choice. The following figure will compare both the elements. Add User Parameters Add CSV Data Config Since we need to create 500 unique accounts, the natural choice would be using CSV Data Set Config Element. It is advisable that the CSV file created for this test be located in the same directory as the Test Plan. This element gives you the option to define the delimiter of your data file. Since we want only these 500 unique accounts created and nothing more, we do not choose recycle on EOF, which would reread these pairs from the beginning of the file once the whole file is parsed. These data will need to be parsed into the appropriate parameter(s) using the function syntax: ${VARIABLE-Name}. We will use these account pairs in Create Account | /login Sampler where you see the corresponding variable names or parameters (email, password, confirm password) are captured in the Sampler. © Jmeter4u Page 27
    • In the following figure you may notice the Value for these parameters corresponds with Variable Names defined earlier in the CSV Data Set Config Element. Parameterized the appropriate Parameter Adding Listeners We are now ready to add Listeners to our Test Plan. As we are evaluating performance based on scenarios, each scenario Controller will have its own Listener. One Listener is sufficient to capture the performance data, as the saved data can be represented in various ways according to the Listener selected to view these data. The following steps will give you a better walk through. 1. Right-click on the Homepage Controller 2. Select Add | Listener Add Listeners In the Filename text-field simply type the name of the XML or JTL file, along with its extension, that will store the results for the requests in this Controller. By default this will be located in the bin folder of your JMeter installation path; however, you may choose to specify a different location. Follow similar steps for all other Controllers. © Jmeter4u Page 28
    • Running the Test Plan We are now ready to run the Test plan we have built. We may rename the Thread Group to "10 Users" for better documentation. Look at the tiny gray indicator box at the top right of the Control Panel. The numbers beside the box indicate number of active threads vs. total number of threads in the Thread Group. JMeter requires saving the Test Plan before running; unless indicated otherwise, it will save the Test Plan in the bin folder of your JMeter installation path. To run the Test Plan, go to the Run menu and select Start. As soon as it runs, the gray box will turn green as JMeter ramps up the total number of active threads to 10. You will see that JMeter takes approximately 5 seconds to activate the total number of users with a delay of 100ms (1000ms per 10 users) between subsequent threads. This demonstrates the 1 second ramp-up time we have set in Thread Group earlier. Add View Results in Table Interpreting the Results Once the test is completed, we can now retrieve the results we have saved for each Controller. With the exception of the Assertion Result Listener, the saved data can be viewed in numerous forms. Let us use HomePage.xml as our specimen dataset. Add more Listeners to this Controller: Summary Report, Aggregate Result, and Graph Results. To retrieve the results for this Sampler, type in the name of the file to which you saved data for this Sampler, and press Enter. The following snapshots show the result views. For Graph Results, the Data legend shows us the widely dispersed data, representing the large value of the Standard Deviation across all samples for this Homepage Sampler. In the case where the results are highly skewed or not symmetrical using 'mean' would result in inaccurate representation of response time. The Median value, which is found in Aggregate Report and Graph Results would closely approximate the response time. © Jmeter4u Page 29
    • Add Graph Results The saved results can be viewed in various forms. The following snapshot is of the saved test result viewed using the Summary Report Listener. Add Summary Report In the case where data distribution is even, or follows the 'bell' distribution, median and average will have the same or only slightly different values. We can see the data distribution pattern by adding a Spline Visualizer Listener using the filename of the file used to store the sampler results. The following shows us the distribution graph for requests to this page. Add Spline Visualizer © Jmeter4u Page 30
    • The following snapshot is of the saved test result viewed using the Aggregate Report Listener. Note that Summary Report and Aggregate Report display the same set of test results differently, following different computation over the same data. Add Aggregate Report Monitoring the Server's Performance The JMeter Plugins project provides us with the tools necessary to integrate critical performance data directly into our JMeter test plan. When used in conjunction with a JMeter Monitor Test Plan for retrieving statistics from the Java Application Server, we should be able to identify any resource related bottlenecks that exist in the system and take action accordingly. Deploy the JMeter Plugins Downloaded the latest version of JMeter plugins from Google code. To extend JMeter functionality, it is a simple matter of extracting the JMeterPlugins.jar file from the archive into the /lib/ext directory of the JMeter installation. JMeter Plugins © Jmeter4u Page 31
    • JMeter 2.7 We can add the Server Monitor component to any of our JMeter Test Plans by selecting the 'jp@gc Servers Performance Monitoring' (JMeter Plugins @ Google Code) component from Listeners. You can configure the Thread Group with the default settings. The listener only captures data while any thread group is running, so it isn't necessary to configure it specifically. Add Server Monitoring Add PerfMon Metrics For more details check the below link: https://code.google.com/p/jmeter-plugins/wiki/PerfMon © Jmeter4u Page 32
    • Chapter 6: Handling the Dynamic Server Values What is Correlation A Correlation is a Connection or Association.Capturing thedynamic data that is being generated by the server is called correlation. Why Correlation It is the process to handle dynamic values in performance testing. If you simply record and playback a script in Jmeter, you might encounter errors in your playback. Often, those errors are related to the session values which aresent by the server to the client to identify that particularsession. Why error? Well, session values will change with every playback of the script. To overcome this we need a way which can capture these dynamically generated session values and pass it subsequently to any part of the script, wherever required. This method to identify and set the dynamic generated value is known as correlation. Using Regular Expression Extractor in Jmeter Tests Regular expressions are used to search and manipulate text, based on patterns. JMeter interprets forms of regular expressions or patterns being used throughout a JMeter test plan. With the use of regular expressions, we can certainly save a lot of time and achieve greater flexibility as we create or enhance a Test Plan. You can place regular expressions in any component in a Test Plan. The next step will demonstrate the use of Regular expressions in the Regular Expression Extractor—a Post-Processor Element. This element will extract text from the current page using a Regular Expression to identify the text pattern that a desired element conforms with. Add Regular expression Extractor © Jmeter4u Page 33
    • Regular Expression Extractor Reference Name: The name of the variable in which the extracted test will be stored (refname). Regular Expression: The pattern against which the text to be extracted will be matched. The text groups that will extract are enclosed by the characters '(' and ')'. We use '.+?' to indicate a single instance of the text enclosed by the <td..>..</td> tags. Template: Each group of text extracted will be placed as a member of the variable VOL, following the order of each group of pattern enclosed by '(' and ')'. Each group is stored as refname_g#, where refname is the string you entered as the reference name, and # is the group number. $1$ to refers to group 1, $2$ to refers to group 2, etc. $0$ refers to whatever the entire expression matches. In this example, the ID we extract will be maintained in VOL_g1, while the Name value will be stored in VOL_g2. Match No: Since we plan to extract only the second occurrence of this pattern, matching the second volunteer, we use value 2. Value 0 would make a random matching, while a negative value needs to be used with the ForEach Controller. Default: If the item is not found, this will be the default value. This is an optional field. You may leave it blank. After extracting the ID of the record that we want to edit, we are ready to select, edit, and update this record. © Jmeter4u Page 34
    • Chapter 7: Parameterize with test data What is Parameterization It is the way of replacing a hard coded value in the script with a parameter which represents a list of values. It is a script that contains the actual values used during recording and during script enhancement phase test engineer has to replace the recorded values with parameters is known as parameterizing. Why Parameterize We do Parameterization because:    It allows you to test your script with different values. Replace the constant values in Script with parameters. Simulate real user behavior while running the test. Identifying the test data on AUT For successful performance test, Performance test environment should be exact replica of production environment. So test data should be identified and then it should be used while execution. Building the accurate test data very similar to production environment is the fundamental step for successful performance test. To check what could be test data in your application, just watch each http request. Under http request there could be parameter and there values. So, this is particular parameter for which test data should collect. Some of examples are listed below:   While login “Username” & “Password” are parameter for which test data needed. While registration “First Name”, “City” etc is parameter for which test data needed. Using the CSV Data Config in Jmeter Tests Using Parameterization we can execute one test plan for more than one user at the same time. This is a method of generalizing an action for many users. To Parameterize Jmeter please follow the steps give below: 1) Open MS file and type the words Csv file for parameterization © Jmeter4u Page 35
    • 2) Save page on desktop as login.csv 3) Follow the process and record the script for login for a single word in Jmeter. Why I am suggesting single word because later we are going to parameterize other words. Script 4) Now Click on the thread name login1 and change “USERNAME” and “PASSWORD” parameters as ${username}and ${password}. ‘username’ and ‘password’ we are going to use as a Variable to store different parameters for the login. Before Replacement After Replacement © Jmeter4u Page 36
    • 5) Now right click on the thread search and add CSV Data Set Config: Right Click on search thread–> Add–> Config Element–> CSV Data Set Config Adding config element Once CSV Data Set Config page is added we need to configureFilename- This is the name of the file where you are going to save the different search words. (Don’t worry I will make you easy to understand in next few steps.) Variable Names- This is the name of the variable where we will store the search data during running the script. Stop thread on EOF- Once search will be completed the thread will get stopped automatically. So now I am going to configure these fieldsFilename- login.csv Variable Names- username, password Stop thread on EOF- False Csv set data config © Jmeter4u Page 37
    • 6) Click on Thread Group and change Number of Threads as 2 and Ramp-Up Period as 1. I am suggesting to make it 2 because we are going to login 2 key words. Or you can say we are going to user 2 users to search each keyword. Thread group for parameterization Here we are done with all the configurations. You can add some listeners to view the result by right clicking on thread group. Now just press Ctrl+s to save the jmeter script and run the script by pressing Ctrl+r and see the magic. © Jmeter4u Page 38
    • Chapter 8: Adding Assertions to the test script What is Assertion? Assertions allow you to include some validation test on the response of your request made using a Sampler. They are inserted as a child component of a Sampler. Assertions are particularly necessary in functional testing of your applications, while, in performance testing, you may want to use assertion to ensure the responses you receive. Why Assertion? Assertions are used to perform additional checks on samplers. Types of Assertion in Jmeter Assertions allow you to include some validation test on the response of your request made using a Sampler. They are inserted as a child component of a Sampler. Assertions are particularly necessary in functional testing of your applications, while, in performance testing, you may want to use assertion to ensure the responses you receive. Response Assertion: Lets you add pattern strings to be compared against various fields of the response. The pattern strings are Perl5-style Regular Expressions. Duration Assertion: This tests that each response was received within a given amount of time. Any response that takes longer than the given number is marked as a failed response. Size Assertion: This tests that each response contains the right number of bytes in it. You can specify that the size be equal to, greater than, less than, or not equal to a given number of bytes. XML Assertion: This tests that the response data consists of a formally correct XML document. It does not validate the XML based on a DTD or schema or do any further validation. © Jmeter4u Page 39
    • Bean Shell Assertion: Allows the user to perform assertion checking using a Bean Shell script. MD5Hex Assertion: Allows the user to check the MD5 hash of the response data. HTML Assertion: Allows the user to check the HTML syntax of the response data using JTidy. XPath Assertion: The XPath Assertion tests a document for well formedness and has the option of validating against a DTD, or putting the document through JTidy and testing for an XPath. XML Schema Assertion: The XML Schema Assertion allows the user to validate a response against an XML Schema. Running the tests and analyzing the Assertion results Assertions allow you to assert facts about responses received from the server being tested. Using an assertion, you can essentially "test" that your application is returning the results you expect it to. You can add an assertion to any Sampler. For example, you can add an assertion to a HTTP Request that checks for the text, "</HTML>". JMeter will then check that the text is present in the HTTP response. If JMeter cannot find the text, then it will mark this as a failed request. Add assertion © Jmeter4u Page 40
    • To view the assertion results, add an Assertion Listener to the Thread Group. Failed Assertions will also show up in the Tree View and Table Listeners, and will count towards the error %age for example in the Aggregate and Summary reports. Add assertion results Assertion results © Jmeter4u Page 41
    • Chapter 9: Advanced Features Testing a Database Server A few things you will need before proceeding to build a Database Test Plan are: 1. A working database driver. Following the database that you are using on your database server, copy the .jar file contained in the database driver and pastes it in the lib folder of your JMeter installation path. 2. A valid database-schema. 3. Valid non-empty database table(s). 4. A valid user-level access to the database. It is important for the database to have a user other than the root user for testing purpose, in order to prevent any potential data misuse. As usual we will start off by adding a thread group to the Test Plan. You may need to configure inorder to have 1000 threads, with minimal start-up time, e.g. 3 seconds, with multiple repeats just to demonstrate how far we can test a database in this manner. Then, add a JDBCConnection Configuration as the thread's first child. You may choose to use the default values or configure as you wish in tandem with the database in use. For this Test Plan, configure as following: JDBC Connection Configuration © Jmeter4u Page 42
    • Add a JDBC Request sampler to the thread, and create an SQL statement that serves your testing purpose. I used a simple SQL query for this example. JDBC request You may want to add assertions to the sampler to verify that it returns the expected results. Save and Run the Test Plan as needed. Testing an FTP Server What you will need before proceeding to build a FTP Test Plan includes: 1. A running FTP server on the target machine. 2. A valid path to the shared files in your FTP server. 3. Valid non-empty files in the FTP installation path. 4. A valid user-level access to the files. As usual we will start off by adding a Thread Group to the Test Plan. You may need to configure in order to have multiple threads, with minimal start-up time, with multiple repeats—just to demonstrate how far we can test a file server in this manner. Then, add an FTP Request Defaults element as the thread's first child. You may choose to use the default values or configure as you wish in tandem with the file server in use. © Jmeter4u Page 43
    • Add an FTP Request sampler to the thread, and configure as seen in the following snapshot: FTP request Note that this sampler requests a file located in the FTP Share folder of the file server, downloads it and saves it using a different file name in the download path. The downloaded file names are created following the thread number generated by each thread that makes the file request. This effect is achieved by appending the __threadNum function—a JMETER built-in function—to the thread's own copy of the downloaded file. You may want to add assertions to the sampler to verify that it returns the expected results. Save and Run the Test Plan as needed. © Jmeter4u Page 44
    • Chapter 10: Best Practices Limit the Number of Threads Your hardware's capabilities will limit the number of threads you can effectively run with JMeter. It will also depend on how fast your server. The more JMeter works, the less accurate its timing information may become. The more work JMeter does, the more each thread has to wait to get access to the CPU, the more inflated the timing information gets. If you need large-scale load testing, consider running multiple non-GUI JMeter instances on multiple machines. For testing how JMeter performs on a given platform, the Java Test sampler can be used. Using Cookie Manager The HTTP Cookie Manager element has three functions: 1.The cookie manager stores and sends cookies just like a web browser If you have an HTTP Request and the response contains a cookie, the Cookie Manager automatically stores that cookie and will use it for all future requests to that particular web site. Each JMeter thread has its own "cookie storage area". So, if you are testing a web site that uses a cookie for storing information for particular sessions then each JMeter thread will have its own session. 2.Received Cookies can be stored as JMeter thread variables To save cookies as variables, define the property "CookieManager.save.cookies=true”. The names of the cookies contain the prefix "COOKIE_" before they are stored (this avoids accidental corruption of local variables). To revert to the original behavior, define the property "CookieManager.name.prefix= " (with one or more spaces). If enabled, the value of a cookie with the name TEST can be referred to as ${COOKIE_TEST}. 3.Manually add a cookie to the Cookie Manager Note that if you do this, the cookie will be shared by all JMeter threads. Such cookies are created with an expiration date far in the future. © Jmeter4u Page 45
    • Using the Authorization Manager The Authorization Manager lets you specify one or more user logins for web pages that are restricted using server authentication. You see this type of authentication when you use your browser to access a restricted page, and your browser displays a login dialog box. JMeter transmits the login information when it encounters this type of page. Authorization manager Name: Username: Password: Domain: Realm: Descriptive name for this element that is shown in the tree. Request URLs. The password for the user. The domain to use for NTLM. The realm to use for NTLM. Controls:     Add Button: Add an entry to the authorization table. Delete Button: Delete the currently selected table entry. Load Button: Load a previously saved authorization table and add the entries to the existing authorization table entries. Save As Button: Save the current authorization table to a file. Reducing resource requirements     Some suggestions on reducing resource usage Use non-GUI mode: jmeter -n -t test.jmx -l test.jtl Use as few Listeners as possible; if using the -l flag as above they can all be deleted or disabled. Don't use "View Results Tree" or "View Results in Table" listeners during the load test; use them only during scripting phase to debug your scripts. © Jmeter4u Page 46
    •  Rather than using lots of similar samplers, use the same sampler in a loop, and use variables (CSV Data Set) to vary the sample. Or perhaps use the Access Log Sampler.  Don't use functional mode  Use CSV output rather than XML  Only save the data that you need  Use as few Assertions as possible If your test needs large amounts of data particularly if it needs to be randomizedcreate the test data in a file that can be read with CSV Dataset. This avoids wasting resources at run-time. Bean Shell Server The Bean Shell interpreter has a very useful feature it can act as a server, which is accessible by telnet or http. If you do wish to use the server, define the following in jmeter.properties: beanshell.server.port=9000 beanshell.server.file=../extras/startup.bsh In the above example, the server will be started, and will listen on ports 9000 and 9001. Port 9000 will be used for http access. Port 9001 will be used for telnet access. The startup.bsh file will be processed by the server, and can be used to define various functions and set up variables. The startup file defines methods for setting and printing JMeter and system properties. This is what you should see in the JMeter console: Startup script running Startup script completed Httpd started on port: 9000 Sessiond started on port: 9001 Distributed Testing In the event that your JMeter client machine is unable, performance-wise, to simulate enough users to stress your server, an option exists to control multiple, remote JMeter engines from a single JMeter GUI client. By running JMeter remotely, you can replicate a test across many low-end computers and thus simulate a larger load on the server. One instance of the JMeter GUI client can control any number of remote JMeter instances, and collect all the data from them. This offers the following features:    Saving of test samples to the local machine Management of multiple JMeterEngines from a single machine No need to copy the test plan to each server - the client sends it to all the servers © Jmeter4u Page 47
    • However, remote mode does use more resources than running the same number of non-GUI tests independently. If many server instances are used, the client JMeter can become overloaded, as can the client network connection. Step 1: Configure the nodes Make sure that all the nodes (client and servers) are running exactly the same version of JMeter. If the test uses any data files, note that these are not sent across by the client so make sure that these are available in the appropriate directory on each server. If necessary you can define different values for properties by editing the user.properties or system.properties files on each server. These properties will be picked up when the server is started and may be used in the test plan to affect its behavior (e.g. connecting to a different remote server). Alternatively use different content in any data files used by the test (e.g. if each server must use unique ids, divide these between the data files). Step 2: Start the servers To run JMeter in remote node, start the JMeter server component on all machines you wish to run on by running the JMETER_HOME/bin/jmeter-server (UNIX) or JMETER_HOME/bin/jmeter-server.bat (windows) script. Note that there can only be one JMeter server on each node unless different RMI ports are used. Step 3: Add the server IP to your client's Properties File Edit the properties file on the controlling JMeter machine. In /bin/jmeter.properties, find the property named, "remote hosts", and add the value of your running JMeter server's IP address. Multiple such servers can be added, comma-delimited. Note that you can use the -R command line option instead to specify the remote host(s) to use. This has the same effect as using -r and -Jremote_hosts={serverlist} If you define the JMeter property server.exitaftertest=true, then the server will exit after it runs a single test. Step 4: Start the JMeter Client from a GUI client Now you are ready to start the controlling JMeter client. For MS-Windows, start the client with the script "bin/jmeter.bat". For UNIX, use the script "bin/jmeter". You will notice that the Run menu contains two new sub-menus: "Remote Start" and "Remote Stop" (see figure 1). These menus contain the client that you set in the properties file. Use the remote start and stop instead of the normal JMeter start and stop menu items. © Jmeter4u Page 48
    • Distributed Testing Sever Monitoring Tools (PerfMon) Performance Monitor is a simple yet powerful visualization tool for viewing performance data, both in real time and from log files. With it, you can examine performance data in a graph, histogram, or report. Membership in the local Performance Log Users group, or equivalent, is the minimum required to complete this procedure. To start Performance Monitor 1. Click Start, click in the Start Search box, type PerfMon, and press ENTER. 2. In the navigation tree, expand Monitoring Tools, and then click Performance Monitor. You can also use Performance Monitor to view real-time performance data on a remote computer. Membership in the target computer's Performance Log Users group, or equivalent, is the minimum required to complete this procedure. To connect to a remote computer with Performance Monitor 1. Start Performance Monitor. 2. In the navigation tree, right-click Reliability and Performance, and then click Connect to another computer. 3. In the Select Computer dialog box, type the name of the computer you want to monitor, or click Browse to select it from a list. 4. Click OK. Additional considerations To view performance counters from a remote computer, the Performance Logs and Alerts firewall exception must be enabled on the remote computer. In addition, members of the Performance Log Users group must also be members of the Event Log Readers group on the remote computer. © Jmeter4u Page 49
    • Database Monitoring Tool (Jet Profiler) Jet Profiler for MySQL is a query profiling tool for the MySQL database server. Features Query, table and user performance Jet Profiler focuses on queries, tables and users. This gives you the information you need most in order to quickly fix performance problems in your code, such as most frequent queries, most used tables or busiest users. Graphical visualization Data is collected, analyzed and displayed in real-time in diagrams, pie charts and tables. You can easily drill down and navigate through the data. Low overhead Most of the profiling work is done in the Jet Profiler application, not in the database server. Therefore, the performance hit is normally negligible, around 1%. Easy to use It supports all MySQL versions. No database server changes are necessary. No agents or separate services are needed. Jet Profiler is a desktop application which runs on your computer. You start it, connect to a server, hit the record button, and see results within minutes. And it runs on Windows, Mac and Linux. How it works Jet Profiler is a desktop application that runs on your computer. When you start to record performance information, the application will connect to a specified MySQL server. It will then collect different performance metrics from the server every second (or 100ms - 10s, configurable). This information is then stored and analyzed in an internal database in the application. The collected information is presented in a GUI where you can drill down on different aspects. You can view the trends (such as how many queries are executing) and zoom in on peaks in the load, and you can view top lists for different time frames (such as the most seen queries). The information is available close to real time, giving you instant feedback on performance variations. This makes it very easy and efficient to optimize your database. For instance, you can add indexes on the fly and watch the difference within seconds. © Jmeter4u Page 50
    • MySQL commands  SHOW PROCESSLIST  SHOW OPEN TABLES  SHOW GLOBAL STATUS For more details go through this below link http://www.jetprofiler.com/doc/ © Jmeter4u Page 51