we are working on performance testing using JMeter, Can any one please provide information how to keep the Session alive using jmeter for 3 minuts or more.
To keep session alive , you need to check option "Use KeepAlive" in your http sampler.
You can just add a HTTP Cookie Manager at the Thread Group level, so as to ensure that all HTTP requests will share the same cookies.
Right click your Thread Group, and then add Config Element -> HTTP Cookie Manager.
More details about HTTP Cookie Manager: http://jmeter.apache.org/usermanual/test_plan.html
Related
Our Application is live event based application which creates 2-3 web-socket connection and it is a web-based application which makes both HTTP calls and Web-socket calls.
I have created a script for Https calls as unfortunately Jmeter does not support web-socket recording so I trying to insert web-socket calls manually with the help of web-socket Sampler but not sure which will be the best sampler for same as my request has access token in it.
I tried with Web-socket request-response sampler I am getting 200 OK but their is no data response from server when I compare it with browser developer tool i could see some messages flowing..
Can anyone let me know if I am doing something wrong or missing anything? OR what can be done to solve it.
I believe JMeter WebSocket Samplers by Peter Doornbosch is what you're looking for.
As per Features section:
integrates with JMeter's Header Manager to set additional HTTP headers on WebScoket upgrade request
so you will be able to add HTTP Header Manager, configure it to send Authorization header with the value of Bearer followed by your token and the Sampler will pick it up.
With regards to which one to choose - it depends on the nature of your application and how does the communication with the backend looks like, check out your browser developer tools to see whether requests/and responses are coming via a single connection or a new one is being established for each frame and so on.
More information: JMeter WebSocket Samplers - A Practical Guide
i send 10 requests to the server which was recorded by blazemeter chrome plugin.
some of them are signalr requests that have connection token values created runtime.
signalr requests are
signalr/negotiate?..
signalr/connect?
signalr/start?
signalr/abort?
if i dont use regular expression extractor for correlation, the signalr request has wrong responses and test will fail.
if i use correlation, some interesting results are present.
if i use it only in signalr/start it will pass, the other signalr's will fail.
if i add the connectionParameter to the signalr/connect... request. it will do nothing and test will not continue and not finished. So, i wonder if Jmeter dont send the request or any response is received. in view result tree listener, the request is not seen in this case.
What will Jmeter do if a response is not send by server?
or any other information that i dont know related to signalr/connect.. issue?
What will Jmeter do if a response is not send by server
When it comes to HTTP Request samplers JMeter will wait for response for the time defined in the "Timeouts" section of the aforementioned HTTP Request sampler
Blank values mean "no timeout" so JMeter will wait either forever or until the socket timeout defined in the underlying JVM or OS is exceeded.
With regards to SignalR most probably you need to use WebSocket Samplers plugin, I don't think there is a way to record these requests using whatever JMeter recording solution currently available in the market so consider inspecting the traffic from your browser to the backend using either browser developer tools or a 3rd-party sniffer tool like Wireshark.
What is the use of keep alive option in Jmeter and ow its working ?
I did a performance test using Jmeter 3.0
In my recorded script Keep alive option is checked.
So i use keep alive option checked in my real test script
If i use keep alive option i got error with in 75 concurrent VU's
Error message : XXX.XXXX.XXXX:XXX server refused to respond
if i un check keep alive option i can able to go up to 500 VU's without error.
In this case do we need to use Keep alive option or not ?
Keep-alive is an HTTP feature to keep a persistent connection between round trips, so that it does not initiate a new one on every single request. This feature has many benefits, but one of the trade-offs is that it holds resources on the server side and that can be an issue under heavy load.
In your case, I guess that you've simply consumed all resources on the server with 75 opened connections and that it can't serve further requests. This error does not necessarily mean your server can't serve more than 75 connections, because it all depends on your HTTP server config.
Example of an Apache config:
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 100
Keep alive on wikipedia
Ugh! Just ran into this. According to JMeter's documentation:
http://svn.apache.org/repos/asf/jmeter/tags/v5_1_RC2/docs/usermanual/component_reference.html
JMeter sets the Connection: keep-alive header. This does not work
properly with the default HTTP implementation, as connection re-use is
not under user-control. It does work with the Apache HttpComponents
HttpClient implementations.
In other words, JMeter will send the header, but with the default implementation it will not re-use connections.
To use KeepAlive effectively, you need to select 'HttpClient4' from Implementation dropdown on Advanced tab.
HTTP keep-alive i.e. HTTP persistent connection, is an instruction that allows a single TCP connection to remain open for multiple HTTP requests/responses.
I am doing load testing in jmeter. I have recorded the script using jmeter recording of my application. When i am running the script then response time is greater than the response time comes in browser.
I have used the concurrent pool in Http Request Header but its not working for me because i have different http requests.
So Is there any way that we can send the parellel http requests of Sampler for same user.
Please help! Thanks in advance.
Try "clean" browser session - delete all cookies, cache, etc. - response times will stop being different - all you need is just to add HTTP Cache Manager to your Test Plan
If it doesn't help - it may be AJAX. JMeter doesn't have built-in mechanisms for simulating AJAX requests so it needs to be worked around.
See How to Load Test AJAX/XHR Enabled Sites With JMeter guide for different options highlighted and explained.
I have a strange problem in 2.6 jmeter. I have a really simple test plan with couple of http samplers with cache and cookie managers on the thread level. Whenever "Use concurrent pool" is enabled for http samplers, I see the following warnings in the log:
jmeter.protocol.http.sampler.HTTPSamplerBase: Existing CacheManager HTTP Cache Manager superseded by HTTP Cache Manager
jmeter.protocol.http.sampler.HTTPSamplerBase: Existing CookieManager HTTP Cookie Manager superseded by HTTP Cookie Manager
This repeats a huge number of times for each thread and may hang jmeter. But if the "Use concurrent pool" setting is disabled then everything is fine. There are no additional cookie or cache managers on the sampler level. I can not do without Cookie manager's functionality in my test plan.
My test plan looks like this:
Test plan
---Thread Group
------Cookie Manager
------Cache Manager
------Response assertion
------HTTP sampler
--------Header Manager
------HTTP sampler
--------Header Manager
------Aggregate report
You have multiple Cookie and Cache managers in scope and this is causing this warning to appear. To remove the warning you should remove the additional, extraneous managers.
Eg.
Test Plan
---Thread Group
---HTTP Cookie Manager
-------Sampler
HTTP Cookie Manager
The above setup will cause this warning as both managers will be in scope for the sampler.
This:
Test Plan
---Thread Group
---HTTP Cookie Manager
-------Sampler
Will not cause the warning but will still produce the same results.
I found that when had a "HTTP Request defaults" config element setup with "use concurrent pool" enabled I always got these warnings. Disabling that setting cleared up warnings, doesn't explain the why? however.