jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Speteanu <>
Subject Re: Theoretical question
Date Wed, 19 Dec 2012 15:19:39 GMT

If you use thread loops, instead of using loop controllers inside the
thread, shouldn't that trigger more logins?
I approached this differently some time ago:
   1. separate workload into two use-cases: with login and without login.
This gives you two different scripts or two different thread groups (I had
decent analytics, so I knew how much traffic each use-case should
generate)... I prefer using different scripts for performance reasons.

   2. instead of doing login once in a while, do logout once in a while ;)
This is a very common use case in real life. People will login if required
to accomplish whatever they need to do and can only do it if they are
signed in, but will very rarely logout. I used the throughput controller to
specify a number that represented a percentage of the total logins
performed. This will give you more than 500 sessions in the web container...

  3. for those threads that don't logout wright the session in a database
from JMeter, along with the timestamp when it was created. threads that
don't login from second script will use with a X probability a sessionID
stored in the database on their first request.
This covers those use-cases where your users return to the web page but
already have session. Make sure to detele old session IDs (this should
match the expiration configuration of the web container)...
This is also theoretical. I feel that 1) and 2) are enough, so test setup
is not too complicated -> you just have to monitor the number of sessions
(concurrent active and total sessions still valid) so they aren't too many
or too few. The focus is to have approximately the same amount of sessions
per web container and that the total number of logins in rapport to total
number of request matches production environment (or matches a realistic
number if you lack those analytics from production environments).

Testing this as realistically as possible didn't give me more and improved
results, though, since tomcat was pretty well configured in my case and had
enough memory, while the database was a bigger bottleneck - so in real
life, you couldn't get into a situation where session management is
actually an issue. But that was true for that system. Nowadays, it
shouldn't be something you should worry about, unless you specifically
think that might be the problem.

Adrian S

On Wed, Dec 19, 2012 at 4:42 PM, Shmuel Krakower <> wrote:

> Hi,
> Not directly JMeter question, but I think that this community is the right
> place to ask.
> How do you implement your load test scenario (test plan) when simulating
> the Login requests?
> Until today, all of my load tests where built up with having the login
> action inside a Once Only Controller, which caused my load tests to
> simulate a login only once per user.
> The problems I see with my current approach are:
> 1. Logins are only executed during the initial "ramp up" phase of the load
> test and no login requests are handled by the app later.
> 2. Amount of sessions in the application is ramped up and then remains on
> the same level (i.e. 500 threads = 500 sessions) - which is ok, but
> actually it doesn't reflect real life.
> In real life - users are logging in, doing action or few and then may come
> back later with new session, so even when I have same throughput for most
> of the actions in the system as in the real life usage,
> I still get only 500 application sessions during load tests, while on
> production we have thousands of them.
> So again, my question is not about above problems, it is:
> How do you implement your load test scenario when simulating the Login
> requests?
> 1. Do you randomly re-login for some of the iterations?
> 2. Do you login for each iteration?
> 3. Other ideas?...
> Best,
> Shmuel Krakower.
> - re-use your jmeter scripts for application performance
> monitoring from worldwide locations for free.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message