2013-05-10

Introduction to JMeter Google PlugIn- Listeners

In this article we are going to see what are additional features/items added after installing jmeter plugin (Google Plugin) and what we can do with it. I will discuses about Listeners only. To know about basic of jmeter see my this page. And, the process to install plug in , see this post.

What is a listener? A listener mainly analysis the monitored data and show in different way about different information. You may see my previous post to know more about listeners. So, after adding the Google plug in, we get 19 type of listeners. Well, it is better to use these listeners as they are very memory efficient. All listeners can be added
-Right click a Test Plan or thread > Listeners > [Name of the listener]

And, for most of the cases, add  "Save active thread counts" from listener's configuration(if it is present)

1. jp@gc - Active Threads Over Time
-This shows the threads running or ran over time. It is a simple listener showing how many active threads are there in each thread group during test run.
-A single listener can show different threads(if it is in directly under test plan),  Please make sure that you change the label of the thread to distinguished between them.
-Make sure to Tick the "Save Active Thread Count" in listener's configuration to
-In case of remote testing (multiple servers) make the thread group label with name of the remote pc to identify. Ex- ${__machineName()}_myThreadName. This function will call the remote pc name and attach with thread group.
-It is very useful while running the test, we can see the overall and individual thread progress. In my opinion, if there is small user generation or you need a demo run to show to your clients, you must add this to see the overall progress.
See a sample screen shot.

2. jp@gc - AutoStop Listener
-This is a spatial listener who will check certain conditions to stop the test. Like as conditional test terminator.
-Functionally, if condition verify, It will trigger shutdown test (up to 5 attempts) . If shutdown test  can not stop, it will trigger stop test(up to 5 attempts). If stop test can not stop, it will trigger stop now.
-Provide value Zero to any criteria if we want to disable.

3. jp@gc - Bytes Throughput Over Time
-This shows Bytes send or receive over time. All units are in second.
See a sample screen shot.

4. jp@gc - Composite Graph
-This is a spatial listener. It shows any graph from other listeners. In graph section, we can select/deselect from available sources.
-It works if we add that before test run.
-It is very useful see different graphs together in composite/combined way. So that we can compare different states.
-It is very useful while analyzing the data with graph representation
See a sample screen shot.

5. jp@gc - Console Status Logger
-This shows summary log in command prompt while Jmeter is running in Non GUI mode.
-This write summary log in log file while Jmeter is running in GUI mode.
See a sample screen shot.

6. jp@gc - DbMon Samples Collector
-This listener shows performance counters provided by database(some data base provides) when the test running(using SQL).
-It also can put values in to database which are accessible.
-We must follow a DB test plan process to make this listener workable. (like as adding JDC connection configuration)
-When we add a single line in the listener, it contains 4 properties.
JDBC pool variable name : It is the variable name which can be used in the test plan.
Chart Label : This is the label which will be shown in the chart representing the value.
Delta : [I do not know yet]
SQL Query : The query which will be used. This must return single numeric value(single column, single row and numeric data)
-Generally, sql query get the value in every second. If we need to change the interval, we may put
jmeterPlugin.dbmon.interval = [millisecond time ] this property in user.properties.
Note : I have not used that yet, so, when I will use this, I can put more comments.

7. jp@gc - Flexible File Writer
This is same as Sample Data writer, but in more flexible format and I has a GUI.
-It has a header and footer
-We need to specify the file path.
-We can specify data for each sample record
-We can use available fields to include as data. Add are in the GUI.
-It helps to make a good formatted results. Usually helpful for custom reporting.
See a sample screen shot.

8. jp@gc - Hits per Second
-This is like as other listeners showing Hits/s.
-This shows hits to the server.(send requests by client)

9. jp@gc - Loadosophia.org Uploader
This needs spatial plugin library to be installed. Download link is here. Keep the files in \apache-jmeter-2.9\lib directory.
This is a spatial listener to upload results to Loadosophia.org after test complete. It may keep test plan also. When we add, this , we will need to fill out the following.
Upload Project : Name of the project to upload. It is private token, need from Loadosophia.org. Who knows the token, he can upload the project.
Directory to store data for upload : path to store
Test title : Title of the running test
Upload token: The token that we will send
Caution : It can upload your data/files to Loadosophia
To know more, see this . And to get the token, go here. They are providing service to analysis data . To use their service you have to upload results.
See a sample screen shot.

10. jp@gc - Page Data Extractor
-It shows the data that we extract from a page response(status, health, message)
-We can add multiple regular expression to extract data. When we add a row there are 4 parameters,
Chart Label : This is the label which will be shown in the chart representing the value.
Regular Expression value extractor : The regular repression  that we will use
Delta : [I do not know yet]
RegExp Label : It is a check box that enables adding label with results.
-In graph, every line show each finding from expression.
-It is actually data over time graph, the more data we get the high value will be in Y axis.

11.jp@gc - PerfMon Metrics Collector
-This is spatially used With Pref Mon server plug ins. I will make a separate post spatially for this.

12. jp@gc - Response Codes per Second
-This is number of response code( HTTP , response code like http 200) over time.
- Each line in graph represents individual HTTP code

13. jp@gc - Response Latencies Over Time
-This is a spatial type of listener that shows latency. Latency means the time between the end of the request and the beginning of the server response. In a short way , the communication time is latency time. Neither application or server is responsible for that, only environments are responsible for that.
-It is response latency (millisecond) vs progress time(s) graph

14. jp@gc - Response Times Distribution
-This shows number of response over response time(millisecond over X axis)
-It shows every Thread/sample individually in Bar diagram
-It can show show all threads/samples together(average)

15. jp@gc - Response Times Over Time
-This shows response time on how much test progresses(time)(X axis)
-Time shown in millisecond (Y axis)
-hr:min:sec format time shown on for test progress.
-It shows every sampler individually
-It can show show all sampler together(average)

16. jp@gc - Response Times Percentiles
-This shows response time on how many percentage(%) completed(X axis)
-Time shown in millisecond.
-It shows every sampler individually
-It can show show all sampler together(average)
-Percentage calculated 0.1 to 99.9 % range.

17. jp@gc - Response Times vs Threads
-This shows response time on user (thread) increment.
-Time shown in millisecond.
-It shows every sampler individually
-It show shows all sampler together(average)

18. jp@gc - Transaction Throughput vs Threads
-This is same as Response Times vs Threads, but shows Estimated Transaction/s.
-It shows the statistical maximum possible number of transactions based on number of users (threads)accessing the application
-Formula is Thread count * /Server Response time in second. (or Thread*1000/time in millisecond)

19. jp@gc - Transactions per Second
-This is like as other listeners showing Transaction/s.
-This shows transactions from each samplers in one second time period.
-It shows every sampler individually
-It can show show all sampler together(average)
-In aggregated view, it shows fail transactions also.
-The graphs shown in manner of full execution time(full time plotted in X axis)

2013-05-09

Introduction to JMeter Google PlugIn- Pre Processors

In this article we are going to see what are additional features/items added after installing jmeter plugin (Google Plugin) and what we can do with it. I will discuses about Pre Processors only. To know about basic of jmeter see my this page. And, the process to install plug in , see this post.

What is pre processor? Typically, a pre processor will process data or provide information before the sampler request send. That means, all parameter data can be handled by Pre processors. After adding Google plugin, we get two type of pre processors.

1. jp@gc - Inter-Thread Communication PreProcessor
-Right click a Test Plan or thread > Pre Processors> jp@gc - Inter-Thread Communication PreProcessor
 
-This is same as it's brother jp@gc - Inter-Thread Communication PostProcessor. Actually, both of them are used together. It is used for getting the value from the queue and use the value to processors any sampler before sending a request. It supports all functions and settings like as jp@gc - Inter-Thread Communication PostProcessor. To get detail idea about it's supporting see my previous post.
-We can set timeouts here to make it more time driven when working with data.
-One of the best way to keep the data and use them before sending request.

2. jp@gc - Raw Data Source PreProcessor
-Right click a Test Plan or thread > Pre Processors> jp@gc - Raw Data Source PreProcessor
-This is another way of reading file rather than CSV data set config.
-This is one of the best way to read for Binary data.
-This is very helpful when we work with TCP or RAW data.
-This HTTP Raw requests/ UDP request in easy way that helps to work with large data set.
-As it is using Raw file, the raw file format should be like this . We can also see this from response data of a http request from View Result Tree Listener.
-In the raw file, there is chunk marker(number) which defines the pursing of raw data.
Note : I have not use this one, as long as I have used it, I will add more comments.

Thanks...:)

Introduction to JMeter Google PlugIn- Post Processors

In this article we are going to see what are additional features/items added after installing jmeter plugin (Google Plugin) and what we can do with it. I will discuses about Post Processors only. To know about basic of jmeter see my this page. And, the process to install plug in , see this post.

After adding google plug in we get 4 types of Post Processors. Basically a post processor will perform processing from response data to retrieve meaningful information. It also help in making further decision and communication with results.

1. jp@gc - Inter-Thread Communication PostProcessor.
-Right click a Test Plan or thread > Post Processors> jp@gc - Inter-Thread Communication PostProcessor.

-By name we understand it's purpose. It actually provides a global string queues(FIFO) for communication. We put string in to it and er get that from different thread group.
-It allows separate thread group to be synchronized on getting same value.
-It allows separate thread group to pass variable.
-Normally, we use this with its brother jp@gc - Inter-Thread Communication PreProcessor.Where , pre processor get the values from previous thread's post processor. Both are following FIFO.
-It clears queue before and after test
-It is better to uses changeable name as queue names. If there we have not use post processor, previous data may not be cleared. So, it may provide wrong values.
-As it is FIFO system, there 4 logical functions are implemented, fifoPut, fifoGet, fifoPop, fifoSize.
 All of them have two parameter, name of fifo and the string value.
Ex- The image showing an example, if we want to apply putting that string in queue, it will be
${_fifoPut(SYNC_FIFO, Shantonu Test)}
-We can set time out of the queue by adding the following string in jmeter.properties or user.properties. 
kg.apc.jmeter.functions.FifoTimeout=[our time in second]

2. jp@gc - JSON Format Post Processor
This need spatial plugin library to be installed. Download link is here. Keep the files in \apache-jmeter-2.9\lib directory.  To add.
-Right click a Test Plan or thread > Post Processors>  jp@gc - JSON Format Post Processor
-It is very useful when we need to debug test cases with view result tree listener. What it do is that, it makes the response data of view result tree more readable(if there are lot's of JSONs).
-The main purpose is to make response data more easier to read.

3. jp@gc - JSON Path Extractor
This need spatial plugin library to be installed. Download link is here. Keep the files in \apache-jmeter-2.9\lib directory.  To add,
-Right click a Test Plan or thread > Post Processors> jp@gc - JSON Path Extractor
 

-This will Extract JSON path. There are two items, Name = The name of the extracted path. JSON path = the extraction syntax to get the JSON path. To know about the syntax, see this. I will try a different post for some idea about JSON path.
-It is very useful when we need to extract data from a JSON object and use in the test plan.

4. jp@gc - XML Format Post Processor
-Right click a Test Plan or thread > Post Processors> jp@gc - XML Format Post Processor
-Like as JSON format post processor, it does the same for XML response data. When we add this to our request, the response data in XML view(of response data) become more readable. When I need to debug any test step, I use this to see View Result Tree listener's response data in XML view in more readable way.
-The main purpose is to make response data more easier to read. 

Thanks..:)