JMeter: HTTP Persistance connection using JMeter

1
votes

I need to hold sessions for a certain period of time using JMeter.

The test plan and script detail is given below:

Say, for example, 100 users have logged into my web application using their individual credential.The session timeout of my web application is 30 minutes. That means if those 100 users remain idle for 30 minutes after login, the application will hold the connection open for next 30 min to receive any further requests from those logged in clients. The connection will not be closed. So if the client needs to conduct another HTTP transaction, it can use the idle keepalive connection rather than create a new TCP connection. Now when those 100 connections are active or idle, I need to determine the response time of a newly logged in client. But I can’t generate this scenario using JMeter.

Here is my script detail: ->Simple Login request -> Ultimate Thread Group: Start Thread Count-100 ->Startup time-120 ->Hold load for-120 ->Shutdown Time-60 -> Constant Throughput Timer- Target Throughput (1200/min). ->Tests run in non-GUI mode ->I have allowed "keepAlive" in "HTTP Request" sampler.

All the threads are up within 120 seconds and after that, this load will be held for another 120 sec. So for this total 240 seconds login requests will be sent (in fact during shutdown time also). In my test around 6500 login requests were generated for 100 threads and all of them logged in using different credentials. I have used CSV data configuration element to pass the data for login. I have monitored the server log while executing the test and observed all login requests were accepted and successful. So in real time scenario, if 6500 users log in to my web app, using different machines or PCs and simply do nothing after login, my server will keep the connection open for next 30 min for further HTTP transactions. How could I generate this scenario in JMeter. Or in my script, are all those sessions kept alive?

Any suggestions or guidance would be very helpful.

2
performancejmeterload-testingjmeter-plugins
I think you are confusing TCP-level keepalive (en.wikipedia.org/wiki/Keepalive) with HTTP persistent connections, also sometimes called "keep-alive" (en.wikipedia.org/wiki/HTTP_persistent_connection). But they are unrelated. Also it's quite unusual for an application session to depend on TCP-level keepalive, but not unusual to depend on HTTP persistent sessions. – Kiril S.
So ,in my test script will all those 6500 requests hold their sessions? I have observed the result with "View Results tree" and all the login requests were generated different session ids with different login credentials. I have to make sure that all those sessions were kept alive while in the mean time I have to determine the response time of a newly set(another "X " users from different machine trying to login) of logged in request. How can I be sure that my first set of(6500 requests of 100 users or threads) requests are kept alive? Is there any tool to observe this from server side? – Adnan
How to check HTTP level keep-alive completely depends application-level behavior, rather than some system parameter, or universal tool. I.e.: number of open TCP connections will not map to number of sessions currently alive on the server. To verify if sessions are alive, you need to know what alive means on your server. For example maybe you could issue some operation after 15 min with the same 6500 user tokens and make sure that login was not required? Or check number of threads in web application (if threads do map to connections, which is not always the case). There are many possibilities. – Kiril S.

2 Answers

1
votes

From a performance perspective your thirty minute timeout is too long. You will be locking up session resources far longer than you need to in order to preference a small group of users. The overhead of satisfying your 30 minute edge case is greater than the overhead of creating a new session for that same edge case.

I recommend you use your choice of log analysis tools (I prefer Splunk> for its ease of use) and analyze the time between page requests for your users. This is easier than you might think. Eliminate all of the static resource requests from your logs, leaving the top level page requests. You will have the timestamp for each request as well as the page it came from ( the referer tag ). Collect a sample set of the difference in response times for any given page less the page with the page noted on the refer tag with the same session or IP address ( depending upon your architecture ). Now you have a sample set of all page to page wait times.

Next, take your choice of tool and graph the distribution of these items with a breakout by minute. What you will very typically find is that the page to page grouping is highly clustered in the one to three minute range for public facing sites. Outside of that range the samples drop off very rapidly. What happens with a long session, such as the thirty minutes you noted, is that you lock up resources that cannot be freed under higher load conditions leading to poorer performance. If you have a shopping cart this will actually slow the entire cart system leading to lower conversion rates. The session is held as an offset from the last request, not the first one.

2
votes
  • There is no need for private services, jmeter is enough. If i am not mistaken what you are trying to do is a peak test, you wanna know how do response times increase as new user sessions are created.
    • the test start by sending a 100 requests, each request will create a new session.
    • if the next requests do not use the same cookie, it will create a new session for each one of them.
    • the peak test will increase load until either the injector run out of threads, or the application start crashing.
  • from the test you will get, a plot that relates response times to load
    • this will tell you what reponse times expect for a given load, you could use this to do capacity planning.
    • a peak test look like this:
    • Load, Throughput and reponse times
  • what is and not an active user depends on your system (after you run the test you'll find out which one is the best to choose).
    • if the session management implementation is sensible to a large number of cookies, i will use all the session as active even the idle ones. Injector threads.
    • if the application container handles the session at the same time, no matter how many idle users there are, i will choose as active users just those usersfor which the system is processing a request in a given moment.
  • if you are doing performance testing to help developers to find bottlenecks, you also need to monitor resources compsumption.
    • JMeter already has agents and monitors in its plugins.