Sie sind auf Seite 1von 19

UI Performance Analysis An Approach Using JMeter and JProfiler

23/02/2009

BFS - 4/ Banking and Finance / Application Development and Maintenance Kannan D kannan.d@tcs.com

TCS Public

UI Performance Analysis An Approach Using JMeter and JProfiler

INDEX
1. PERFORMANCE...........................................................................................................3 2. JMETER .......................................................................................................................4 2.1. JMeter Points to Remember....................................................................5 2.1.1. Folder Structure..5 2.1.2. GUI Mode .....................................................................................6 2.2. Elements of JMeter........................................................................................7 2.2.1. Thread Groups....7 2.2.2. Controllers.....8 2.2.3. Samplers.......................................................................................8 2.2.4. Logical Controllers.....8 2.2.5. Listeners.....8 2.2.6. Configuration Elements...9 2.2.7. Timers..9 2.2.8. Http Proxy Server..10 2.3. jmx and jtl..................................................................................................,......11 3. PERFORMANCE ANALYSIS....................................................................................12 3.1. Test Plan.............................................................................................................13 4. JProfiler.......................................................................................14 4.1. Why JProfiler? ....14 4.2. Views of JProfiler........14 4.3. Server Integration - Steps.....................16 Reference ...19

Internal Use

UI Performance Analysis An Approach Using JMeter and JProfiler

1. Performance
We are aware that meeting the functional requirements alone will not suffice in attaining the lead position in the competitive market as a Product. There exists a main term that contributes to the Quality of the Product which acts as a measure of Efficiency without compromising the business requirement with minimal and effective utilization of the resources. It is nothing but the Performance of the System. It is essential to understand that the user has a particular view of performance that allows us to cut some corners. People expect to see something happening which in turn they will consider as a response from the System. A good rule of thumb is that if an application is not responding for more than three seconds, it is seen as slow. Some Human Computer Interface authorities put the user patience limit at just two seconds; an IBM study from the early '70s suggested people's attention began to wander after waiting for more than just one second. For performance improvements, it is also useful to know that users are not generally aware of response time improvements of less than 20%. This means that when tuning for user perception, we should not deliver any changes to the users until we have made improvements that add more than a 20% speedup. For this reason, we may want to target variation in response times as a primary goal. Unfortunately, this is one of the more complex targets in performance tuning: it can be difficult to determine exactly why response times are varying. All bottlenecks should not be treated equally. Some are going to be trivial fixes, while others will take architectural changes, hardware purchases, and large data and code migration to fix. We need to avoid spending a long time working on a fix that gives us a 1 percent performance boost, while we could have gotten a 10 percent boost in half the time by modifying another component. When we say we want to find bottlenecks, what we really mean is that we want to find the areas of the application in which the most time is spent. If we're spending 80 percent of the time reading files from disk, then that's our bottleneck. If we're spending 70 percent of our time waiting for database calls to respond, then our bottleneck lies somewhere inside the database system.

The General Performance Tuning Strategy will be: Identify the main bottlenecks Choose the quickest and easiest one to fix, and address it Repeat from Step 1.

Internal Use

UI Performance Analysis An Approach Using JMeter and JProfiler

In simple terms, we can say Arriving at Z = X + Y is the Functional Requirement And Attaining Z = X + Y within x seconds is where performance comes into the picture and it is one of the parameters which defines the Brand and the Quality of the System.

There are various performance measure and analysis tools which are available in the market. The purpose of those tools is to identify the bottlenecks of the Performance providing the root cause of the problem. This in turn enables the Programmers to break the bottlenecks and arrive at the desired performance level and meet their business specifications. The selection of the tool depends on the deliverables under test and needs of the business. In certain cases, we need to use the performance tool in collaboration with the other tools to increase the mileage of the performance. We are going to see one such case where we will be using the JMeter along with the JProfiler. Before diving, to make things comfortable we will have a brief introduction of JMeter and JProfiler.

2. JMeter
Apache JMeter is a pure Java desktop application, the purpose of which is to load test client/server software (such as a web application). It can be used to simulate a heavy load on a server, network or object to analyze overall performance under different load types. It may be used to test the strength and the performance of various resources such as static files, Java Servlets, CGI scripts, Java objects, databases, FTP servers, and more. JMeter allows us to create assertions using regular expressions thus providing an option to validate the application.

Internal Use

UI Performance Analysis An Approach Using JMeter and JProfiler

2.1. JMeter Points to Remember


Assuming we have JRE and JMeter installed in the machine with the Environment Variables set, We can go ahead playing with JMeter. JMeter works on all OS which comply with Java Implementation.

Note: JMeter requires the below mentioned things to perform its job: JVM 1.4 or higher. Folder structure of JMeter (Fig 1.0) after installing needs to be retained without any alteration.

2.1.1. Folder Structure: Fig 1.0

bin docs lib

- holds the executable commands and properties. - contains the api. - contains the utility jars and in turn has a folder ext to accommodate the user defined and third party jars thus providing an option to plug in the extra features. printable_docs - demos and user manual.

Internal Use

UI Performance Analysis An Approach Using JMeter and JProfiler

2.1.2. GUI Mode In general, JMeter can be executed in two modes - GUI and Non-GUI Mode (Command prompt mode). GUI (Fig 1.1) can be viewed by invoking the batch file jmeter.bat available in the location bin folder. There are few other batch files to run the test in Non-GUI mode and in the server mode. The jmeter.properties in the bin directory can be used to set the user.classpath thus defining the path of the add-on jars, xml parser and other configurations. Fig 1.1 GUI Mode

Internal Use

UI Performance Analysis An Approach Using JMeter and JProfiler

2.2. Elements of JMeter


Fig 1.2 Elements of JMeter

2.2.1. Thread Group This forms the primary element of JMeter through which values such as number of Threads, Ramp-Up period and loop count can be provided. The other elements such as Samplers, Controllers, etc will be tagged under this element. This can be correlated with the real world scenario in the following way: No of Threads - No of Users available to access a particular web application

Internal Use

UI Performance Analysis An Approach Using JMeter and JProfiler

Ramp-Up Period Time Delay between the individual users to access the application. Say if the Ramp-Up Period is zero, everyone will be accessing at the same time without any delay. Loop-Count It defines the no of times the defined requests will be accessed. Forever Defines that there is no limit for dropping a request. Scheduler Helps to schedule a particular test plan.

2.2.2. Controllers Controllers can be categorized into Samplers and Logical Controllers which drives the execution of the Test Plan. 2.2.3. Samplers This element enables the JMeter to create request and waits for the response. They are executed in the order in which they are arranged. The order can be altered by including the controllers which controls the flow of the process. Http Request, FTP Request, JDBC Request and Java Object Request are few of the JMeter samplers. 2.2.4. Logical Controllers This element can be used to define additional logic in the processing of the test sample. As the name implies, it controls the execution process thus enabling the requests to be triggered according to the controller used. There are various built-in controllers available. Few of them are: Simple Controller - basic controller.

Only Once Controller - executes the sampler attached to it only once. Interleave Controller - Alternates the sampler attached to it. Loop Controller - Iterates the requests based on the input loop count.

And others include If Controller, While Controller, For Each Controller, etc., and they are simple as their name.

2.2.5. Listeners This element is used to view the test results and record the same. It can also be used to load the recorded test sample. The output of the simulation of the test scenario can be viewed in different forms Graphical/ Tabular/Tree Form providing various measures such as Throughput/Average/Deviation of the Input Sample.

Internal Use

UI Performance Analysis An Approach Using JMeter and JProfiler

2.2.6. Configuration Elements

This enables JMeter to setup the defaults or provide data for the samplers to run Test Plan for later use.

Few of the Configuration Elements are: CSV Data Set Config This acts as the source providing the input to the test plan. It reads the file and defines the variables with the help of the delimiter at the start of the test iteration. For Eg: UserName, Search Criteria etc., can be provided through the file and the defined no of threads iterates by extracting the data from the input file and the settings can be configured using Recycle Option, Stop Thread on EOF available in the right panel and by modifying the JMeter property csvdataset.eofstring

Http Request Defaults - This can used to define the default values such as server or IP address, port no, etc., so that it is not required to mention the port no and server name in all the Http Request samplers as they inherit those values from the Http Request Defaults and we can overwrite those values if required by modifying it in the respective Http Request.

2.2.7. Timers This allows us to provide a time delay before or after the execution of the Sampler and works only with the sampler provided it is there in the same scope as the Sampler. Gaussian Random Timer - This timer pause each thread request for a random amount of time, with most of the time intervals occurring near a particular value.

Internal Use

UI Performance Analysis An Approach Using JMeter and JProfiler

2.2.8. Http Proxy Server JMeters Proxy Server allows us to capture our actions while we browse through the web application using a normal browser. JMeter will create test sample objects and store them directly into our test plan when we traverse through the pages.

To use the Http Proxy server, add the HTTP Proxy Server element to the workbench. Select the WorkBench element in the tree, and right-click on this element to get the Add menu (Add --> Non-Test Elements --> HTTP Proxy Server). It is also required to set up the browser to use the JMeter proxy port as the proxy for HTTP requests. Fig 1.3 Http Proxy Sever Settings Console

Once we are done with the Http Proxy settings, we can start capturing the sample objects by traversing through the pages and we will be able to see those objects getting added to the Test Plan.

Internal Use

10

UI Performance Analysis An Approach Using JMeter and JProfiler

2.3. jmx and jtl


Simulation can be done using the various available elements in the JMeter (Thread Group, Samplers, Controllers and Listeners). In simple terms, jmx and jtl can be called as input and output files respectively. Before running or simulating, we must have an input defining the navigation steps or a template (Say for Eg: In a normal web application, the navigations steps Login Page Welcome Page Page of Interest ..).This is nothing but the Test Plan represented by a .jmx file. It has the information about the url which it needs to take and the location of the input data or parameters required to complete the test plan. This can be achieved by Samplers (Http Request) either by adding each of the elements to the tree or by using the Http Proxy settings as described above (Requires host/port configuration) in the Workbench. The Test Plan can be simulated by starting it in the JMeter. The Load can be modified using the Thread Group (No of Threads (Users) / Loop Count) and also by the using the Controllers. The output of the simulation can be viewed using the Listeners and can be saved in a file with the extension .jtl. It has sufficient data to define the performance figure and can be available in various flavors such as report, table and tree listeners. These flavors are nothing but the various forms of representing the information to the user. We can use the JMeter GUI to import the input file (jmx) and run it which basically will generate the output file, jtl containing the various performance figures. This jtl file holds the xml representation and will look something similar to this:

<?xml version="1.0" encoding="UTF-8"?> <testResults version="1.2"> <httpSample t="31" lt="31" ts="1220440179299" s="true" lb="Welcome" rc="200" rm="OK" tn="Thread Group 1-2" dt="text" by="1073"/> <httpSample t="0" lt="0" ts="1220440179643" s="true" lb="Welcome" rc="200" rm="OK" tn="Thread Group 1-1" dt="text" by="1073"/> <httpSample t="203" lt="16" ts="1220440181127" s="true" lb="Login" rc="200" rm="OK" tn="Thread Group 1-1" dt="text" by="2937"/> . . </testResults> The above file holds the information like Sampler, Label of the Sampler, Thread Group Involved in it, time taken by the request and Status of the Request.

Internal Use

11

UI Performance Analysis An Approach Using JMeter and JProfiler

3. Performance Analysis
Assuming that we have a task to analyze the performance of a particular navigation in the browser and identify the hotspot if any which prevents us to meet the business specification. Here we are going to consider JProfiler, which is a GUI tool used for the performance analysis Say for Example The Test under focus involves the following requests: Login Welcome Advanced Search Select Category Advance Search - Result Logout The first step is to create a Test Plan using JMeter. By following the above mentioned Http Proxy Settings Configuration, we can arrive at the Test Plan. To this Test Plan, we may need to add few elements manually so as to obtain clear picture. Say for example, in the obtained mentioned test scenario we need to learn the performance under various load conditions and using different set of inputs. As the search manipulation may vary according to the input variable and search criteria, we need to test it with the various scenarios, which is an ideal one. That is the reason we are going for CSV Data Set Config which needs to be added manually where we need to define the variables and input file location. The load to this Test Plan can be configured by providing the sufficient no of threads and the delay between the requests can be introduced by the use of Timers. As our focus is on Advance Search Page, more loads should be provided to the request of interest which can be achieved by the introduction of the Loop Controller. If we mention the no of threads as 30 and the loop count for the Advance Search Request (Using Loop Controller) is 15, the Welcome and other requests will be invoked 30 times whereas the Advance Search Request will be invoked 450 times (30 x 15).By this way, we can get more accurate Performance figure.

Internal Use

12

UI Performance Analysis An Approach Using JMeter and JProfiler

3.1. Test Plan Fig 1.4 Test Plan

Now the Test Plan is ready for the simulation and can be triggered by the Start Option available in the menu bar of the JMeter. Once Started , we can find the output in the

Internal Use

13

UI Performance Analysis An Approach Using JMeter and JProfiler

Summary Report or View Tree (Listeners) showing the status of the input samples along with the other figures such as average time taken, Deviation, Error Percentage etc., In the View Results Tree Listener, we can even find the page by selecting the Response for a particular label. Thus JMeter helps us to visualize the Performance figure for a particular Test Scenario of a Web Application.

4. JProfiler
4.1. Why JProfiler? JProfiler is an all in one Java Profiler which comes with GUI to identify the Performance hindrance or bottlenecks, memory leakage and other thread issues. With JMeter we can arrive at the Performance figures under various load conditions with which we can say whether a particular instance has meet the business specifications or not. In case, if it fails to satisfy the criteria, the next step is to identify the root cause which prevents it to meets the defined criteria and the identification of such a bottleneck can be achieved by the use of JProfiler. In other way, using JProfiler we can identify the cause of the performance and memory issues at code level. 4.2. Views of JProfiler Memory Views All Objects View shows all classes and their live instances on the heap. It also has the provision to change the aggregation levels to Classes, Packages and J2EE Components. Objects during specific use cases can be viewed using Recorded Objects. Allocation Call Tree shows the call stacks of the Recorded Objects. Allocation Hot spots shows the methods that consume more objects. Class Tracker shows how the instance count changes with respect to the time. Heap Walker - Helps in identifying the memory leaks. CPU Views Call Tree View shows the collective information on all recorded method. Hot Spots Easiest view to recognize the performance bottlenecks and their origin. Most of them normally approach Hot Spots view as it gives a clear picture of the performance issues with the inherent time.

Internal Use

14

UI Performance Analysis An Approach Using JMeter and JProfiler

Call Graph To get more information about calling and caller method, Call Graph is used. Call Traces Chronological information about the method calls can be obtained. Thread Views - This can be used to identify the performance issues in multithreaded applications. VM Telemetry Views - This section contains a number of views with aggregated information about the profiled JVM. Server

Assuming that the machine has JProfiler in it, the first thing we need to do is Integration with JProfiler. Fig 1.5 JProfiler Server Integration Wizard

Internal Use

15

UI Performance Analysis An Approach Using JMeter and JProfiler

4.3. Server Integration - Steps:

Choose Wizard Select the appropriate server Choose Local or Remote as we have options to profile in both the modes After selecting the Startup Mode, locate the Config file (server.xml) Locate the Startup script so that the server will be switched on when we invoke this session in the JProfiler Choose the JVM Choose the Profiling Port which will be defined by default. Deactivate Windows Service and Finish.

After completing this process, a new session will be created with the appropriate name (Server Name on localhost).

Starting this session will activate the server by invoking the start-up batch file and will start displaying the various views of the JProfiler. After server start-up through JProfiler, we need to start the simulation in the JMeter which will start issuing the requests under various loads and by extracting the input data from the CSV file. Within few seconds the Listeners will start representing the output data by receiving the response from the server.

Meanwhile the JProfiler will construct the various views by analyzing the behavior of the server. We can identify the hotspots at various aggregation levels (methods, packages) in the CPU View of the JProfiler.

Internal Use

16

UI Performance Analysis An Approach Using JMeter and JProfiler

Fig 1.6 CPU View Hot Spots Identification

We can even sort the hotspots to identify the methods or packages contributing higher performance bottlenecks and also provides the call hierarchy in the tree structure. The often occurring problem could be either due to the inappropriate utilization of the resources at code level or with the improper implementation of a query. The snap shot can also be saved for future reference.

By this way, we can identify the methods or classes issuing performance hindrance. Now we have the root cause and it needs to be explored further to look for an alternative so as to increase the Performance level.

Internal Use

17

UI Performance Analysis An Approach Using JMeter and JProfiler

After doing the required changes, we can profile the same along with the JMeter simulation to cross check whether the introduced changes have contributed to the raise in the Performance figure. If we continue doing this, it is for sure that there will be a significant increase in the Performance thus leading to the better quality of the Product.

Internal Use

18

UI Performance Analysis An Approach Using JMeter and JProfiler

Reference

More details about JMeter can be obtained by switching on to the

Various Performance Tuning tools can be found in

http://www.JavaPerformanceTuningTool/resources.shtml

More about JProfiler

Java Performance Tuning, 2nd Edition by Jack Shirazi - O'Reilly Media, Inc.

Internal Use

19