What are the Timers in JMeter?

In this following article we are going to know about what is Jmeter Timers. The main purpose of the article will be, how can we use the timers, Why and where we use it.

By the name we can understand what is the timers. When we need to insert time between test steps or process(or sample) , we use this.
Timers are only processed in conjunction with a sampler. It is preprocessed to sampler.

- Timers are processed before each sampler(for single or multiple timers)
- A timer which is not in the same scope as a sampler will not be processed at all.
-If we need time after a sampler, we need to add to the next sampler

How to use
-Add the timer as a child element of any sampler
-Add the time parameter/script/conditions in the timer
-When we need to thread delay, use timers under thread.
-Some timers can be remotely invoked or scripted.

Types  : 
1. BeanShell Timer : It is for generating a standard delay. It supports  ThreadListener and TestListener methods. Important parameters are
a. Reset bsh.Interpreter before each call : When selected, the interpreter will be recreated for each sample. It can be helpful for long running scheduled  scripts
b. Parameters are passed to the BeanShell script
c. Script file contains the BeanShell script.File name is stored in the script variable FileName.
d. BeanShell script ,(returns values in milliseconds to wait)
 See this link as for more. I haven't use that.

2. BSF Timer : Making delay with using a BSF scrip.
See this link for more. I haven't used that.

3. Constant Throughput Timer : It aims to generate constant load to server. For that it changes the load parameters. It introduces variable pauses, calculated to keep the total throughput (samples/min) [As near value as possible]. We need to set the sample/min parameter along with thread to be affected. It is maintained by changing value by
a. A counter variable ,
b. A JavaScript/ BeanShell function to change value,
c.A remote BeanShell server to change a JMeter property 

-It try to keep the throughput, so there may some fluctuation .
-As it is implemented thread wise, add this under the test plan (not thread group)
-Use this for a big load generation over a limited resourced server.

4. Constant Timer : It will keep hold(pause) the step for some time. Values are provided in Milliseconds.
-Best practice to use with ajax or JS call.
-Good to simulate real life scenarios.

5. Gaussian Random Timer : When we need to pause threads for random amount of time, we use this. It has 2 parameter, a. Deviation, means this value will be difference between two random pause. b. Constant Delay Offset, means this value is constant delay after each random pause. All are in Milliseconds
-Best practice to see the behavior after any release( primary load checkup test case)
-Good for random run-time regression(health checkup) scenario. 

6.  JSR223 Timer : It generate a delay using a JSR223 script. See detail of BSF timer.

7. Poisson Random Timer : It pauses each thread for a random amount of time, with most of the time intervals occurring near a particular value.
-The total delay = Poisson distributed value +the offset value.
-Used for purposes same as gaussian random timer

8. Synchronizing Timer : It blocks thread for synchronizing the load. (it block threads until X number of threads have been blocked, and they are all released at once). "Number of Simultaneous Users to Group by" parameter means number of threads to release at once
-Used for generating large user instance at a same time
-Used for constant Max supported user hit
-Used for making a stress test environment for max support testing.

9. Uniform Random Timer : It is used for uniformly random delay(well, see, random can be uniform..:)... ). Random Delay Maximum provides max milliseconds of pause(random). Constant Delay Offset is the added milliseconds with random delay.
-Good for random run-time regression(health checkup) scenario.

10. jp@gc - Throughput Shaping Timer : (please install Google plugins to get that) By adding single or multiple row, it will show the graph of delay generation. Parameters under a row are, Start Rate Per Second, End Rate Per Second, Duration(of full delay time)



Thanks...:).. Please add comments on more uses of Timers.,

What are the Reports/Listeners in JMeter? Why we use them?

In this article we are going to see what are the reports (Listeners) in JMeter and why we use that. Please see my previous posts for primary idea about jmeter.

Jmeter Listener used to listen and process for suitable views/reports. That needed more memory and processor. Different listener of jmeter performs different purposes.
-Listeners are used to view/save/read from running/saved test results.
-Listeners are processed at the end of the scope in which they are found.
-The results are stored as XML files(".jtl" ext). But storing as CSV is the most efficient option[it is less detailed than XML]
-Listeners do not process sample data in non-GUI mode, but the raw result data will be saved if an output file(configured). We can load that data with any suitable Listener.(From File menu)

Using Tips :
-Clear (Ctrl+Shift+E)/Clear All (Ctrl+E) before loading any result file.
-Configure CSV format before string results from jmeter.properties.
-Use function name inside CSV not variable name for remote running(in client server more, variable does not saved) .
-Use Simple Data Writer, and use the CSV format.
[Note :
Most of the listeners currently keep a copy of every sample in their scope, so they are resource hungry.. These don't need to current data for processing separately, so they don't copy.
-Simple Data Writer
-BeanShell/BSF Listener
-Mailer Visualizer
-Monitor Results
-Summary Report

And these Listeners don't keep copies of every single sample, so less memory needed.
You can see my configuring jmeter posts for having more idea on how to configure jmeter, listeners and all reports.

In the following section, we will discuses more about why we use the particular listener, not about what is that because Jmeter doc provides vast information about that.

Aggregate Graph:
-The aggregate graph is similar to the aggregate report except showing results by bar graphs and save the graph as a PNG file.
-It is better to define the graph settings(spatially following client requirements)
-No settings are saved with jmeter project file.
-Very Useful to see results after a distributed test execution(aggregated results).
-Never Use this while running test as it will cause memory overflow


Aggregate Report:
-Same facility as Simple Data Writer.
-Results are shown in tabular format(request count/min/max/average/error rate/approximate throughput (request/second) and KB/s throughput)
- When "Include group name in label?" is selected, the name of the thread group is added as a prefix to results.
-Very Useful to see results after a distributed test execution(aggregated results).
- Never Use this while running test as it will cause memory overflow

Assertion Results:
- Same facility as Simple Data Writer
- Reports any kind of Assertions fail results with failed sample label.
-Very useful for viewing saved results for validation.
-Never Use this while running test as it will cause memory overflow.

BeanShell Listener:
-BeanShell Listener allows the use of BeanShell for processing samples for saving
-When we need to apply condition(modification) in the execution time, this can be very useful.
Note: I have not used them yet. To know more about BeanShell, see this.

BSF Listener:
-It runs BSF script code to be applied to sample results.
-It is used for processing results in a suitable way(following client requirements)
Note: I have not used this yet.

Comparison Assertion Visualizer:
-It shows the results of any Comparison Assertion element
-Same facility as Simple Data Writer
-It is a little bit resource hungry for the Comparison Assertion element, so try to avoid it
-It is very nice when we need to compare & debug requests under assertion.

Distribution Graph (alpha):
-It will show a bar for every unique response time
-The graph will draw two threshold lines: 50% and 90%.This means, 50% of the response time finished between 0 and the line. Same is true of 90% line.
-Normally, A good application's lines are near in hight. (wild fluctuations occurs for bad application).
-Graphs with no apparent clumping or pattern, may indicate a memory leak, therefore we have to use a profiling tool.
-Same facility as Simple Data Writer 
-It is good to view results after test run.
-Never Use this while running test as it will cause memory overflow.

Generate Summary Results:
-It can be placed anywhere
-Main purpose is , Logging or standard output
-Output can be generated after a period of time
-Best uses of this is in multiple test case synchronize running.
-It is mainly intended for batch (non-GUI) runs

Graph Results :
-It shows actual number of requests/minute that the server handle.
-We save result as a file (like simple data writer)
-It also used to view saved data/results.
-We can apply conditions(error/success).
-We can configure the Items to be saved(Press configuration)
-Very Useful to see results after run.
-Never Use this while running test as it will cause memory overflow.


JSR223 Listener:
-It allows JSR223 script code to be applied to sample results.
-It is used for processing results in a suitable way(following client requirements)
Note: I have not used this yet.

Mailer Visualizer:
-It is used for sending mail notification for failed/passed conditions.
-Same facility as Simple Data Writer. 
-All settings are mail related settings.
-It is a very good in case of scheduled test plan execution.
-Project stake holders can be notified for test status on error/passing conditions.
-It is best practices to use this

Monitor Results:
-Basically it is a Visualizer for displaying server status
-The "Health" tab shows the status of one or more servers
-The "Performance" shows the performance for one server for the last 1000 samples
-It requires Tomcat 5 or above
-Same facility as Simple Data Writer.
-It takes a lot of resources, so, when ever we need that, we have to specify the interval for monitor samples.(using constant timer).
-In my opinion, It is better to run the test separately(usually occasionally, when we are in a need to update server for better application support)  for monitor results as it will monitor the servers rather than application's performance .

Response Time Graph:
-it is a line chart showing the evolution of response time during the test, for each labeled request(every request)
-Same facility as Simple Data Writer.
-It is better to define the graph settings(spatially following client requirements)
-No settings are saved with jmeter project file.
-If necessary , then use this while execution test. This also takes a lot of memory. Better to use this after execution.

Save Responses to a file:
- It can be placed anywhere in the test plan for saving file.
-In sample in its scope, it creates a file of the response Data
- Same facility as Simple Data Writer.
-It is vastly used when we create functional test cases.
-It is very handy when  the response data is too large(for currently displaying in tree). It just save them in file.
-It saves file in document type.
-The current sample is saved first, followed by any sub-samples (child samples).
-If a variable name is provided,the names of the files are saved in the order that the sub-samples appear

Simple Data Writer :
-When we save results in our data as CSV/JTI file.
-We can apply conditions(error/success).
-We can configure the Items to be saved(Press configuration)
-It is best practice to use this for storing results which can be viewed after running tests.

Spline Visualizer: 
- All options are same as Same as Graph Results but shows a view of all sample divided in 10 segments(10% each)
-It uses spline logic to show a single continuous line.
- It is useful for at a glance graph visibility over graph results.
-Like as Graph Results, Never Use this while running test as it will cause memory overflow.

Summary Report:
-It creates a table row for each differently named request in test.
-It is a summary of view results in table
-It shows average results for separate sampler(EX- http request )
-It is a kind of "Aggregate Report"
-It is good to view results of  non distributed test.
- Same facility as Simple Data Writer.

View Results in Table:
-Same facility as View Result Tree but all are shows in tabular format.
-By default, it shows the main (parent) samples, on user checking,  it displays the sub-samples (child samples)
-Never Use this while running test as it will cause memory overflow.

View Results Tree:
-View Results Tree shows a tree of all sample & responses in details(HTML/Document/Text/JSON/Regexp Tester/XML format)
- Same facility as Simple Data Writer.
-If there is no content-type provided, then the content will not be displayed in the any of the Response Data panels
-By Default, the response data is larger than 200K, then it won't be displayed.Change the limit from JMeter property view.results.tree.max_size. See this post for how to edit.
-It is the most useful listener for debugging test case. There are various way to use this for optimizing the test plan, view requests, view responses.
-Never Use this while running test as it will cause memory overflow.

So, best practice, Save the results and see after test execution.

Thanks...:)... If you have more of their uses, please have comments. 

Tips and Tricks Part-1

This post has been moved 

What is HTTP Request Defaults? Why we use it

In this following article we are going to see what is HTTP Request Defaults in JMeter and why we use it.

HTTP Request Defaults is the default configuration set for each http request in a fragment/thread/plan which are under it. This is one king of Configuration element that controls the HTTP Request .

When we add a  HTTP Request Defaults(Thread group->(right click)add->Config Element-> HTTP Request Defaults) we will find these

Server:Domain name /IP of server [Exclude http:// prefix]
Port: Port of server.
Connect Timeout(ms): Time to wait for a connection to open
Response Timeout(ms):Time to wait for a response.
Implementation:Java/HttpClient3.1/HttpClient4.[If blank, the default will be activated that is in jmeter.properties.]
Protocol :HTTP/HTTPS
Path: The path to resource.
[Note:Path is the default for the full path, not a prefix to be applied to paths specified on the HTTP Request screens.
Send Parameters With the Request -The query string will be generated from Name and Value.The query string will be generated depending on the choice of "Method"(In the http request sampler)
[If we send a file by multipart form, it will be created using the multipart form specification].
Press Add to add row for parameter.  We can enable encoding if we need(spatially for https)
Server (proxy): Hostname/IP [Exclude http:// prefix.]   
Port: Proxy Port
UserName/Password for Proxy
Retrieve All Embedded Resources from HTML Files: Enabling this, Jmeter will parse the HTML file and send HTTP/HTTPS requests for all images/Java applets/JavaScript /CSS etc
Use concurrent pool: Use concurrent connections to get embedded resources.
Size(byte):Pool size for concurrent connection
Embedded URLs must match: Filter option(Perl regular expression)

Why we use HTTP Request Defaults?
1. When we need to categorize http request under single configuration
2. When we need to use a configuration for multiple fragment( test request segments)
3. When we need to dedicate a particular sampler set following a specific http/https request settings.

-It is best practice to use HTTP Request Defaults in test planning so that we can track the configurations and requests easily.

...Thanks....:)

What is JDBC Connection Configuration? Why we use this.

In this following article we are going to see what is JDBC Connection Configuration in JMeter and why we use it.

By naming, we can understand it is one king of Connection Configuration element that controls the JDBC connection. It will control the the communication to any Data Base used by JDBC. And, it will be present in side a config element.

When we add a  JDBC Connection Configuration(Thread group->(right click)add->Config Element)-> JDBC Connection Configuration) we will find These

Variable Name*: Connection settings will be stored in this variable. Use unique names for Multiple connections Configuration as JDBC Samplers will select any one to use. If two configuration elements using the same name, only one will be saved.
Max Number of Connections* : Number of threads allowed in the pool the connection.
[0=the connection is not shared between thread,
any number = The max count of thread share this connection.(to ensure threads don't wait on each other)[Note: on sharing, thread number = this number]
Pool timeout(m)*: Time to retrieve a Connection Pool (Throws an error when the timeout period is exceeded in the process)
Idle Cleanup Interval (ms)*: Time to Clean a connection pool when it is Idle.( need more experiment on exact functionality)
Auto Commit* Enable/Disable auto commit for connections.
Transaction Isolation* : Transaction Behavior for a connection pool.
Keep-alive*: Logically, connection behavior for validation query( need more experiment on exact functionality). Default true.
Max Connection Age (ms)*: Logically, connection life time for the validation query.( need more experiment on exact functionality). Default 5000.
Validation Query*: A simple query to know the database response.
Database URL*: JDBC DB Connection string
JDBC Driver class*: Fully qualified(including package) name of driver class(Include .jar to \lib)

*= Mandatory

Why we use this ? As it is the configuration for database connection. It will be used for any request that needs a database.Different database's JDBC driver should be located in \lib or should be added to class path(of test plan).
We can see more with the example from my jmeter database related posts.

..Thanks..:)