jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shmuel Krakower <>
Subject Re: Theoretical question
Date Sun, 23 Dec 2012 13:53:08 GMT
Adrian - yes you are correct, I'll put some kind of logic to determine the
amount of logins needed for my scenario.
Sergio - I agree, each scenario should implement load test to best reflect
the real life state, it's ok that there is no clear answer, just wanted to
hear how others are coping with it.

On the technical side (and just for the record), what I've done to "logout"
is just clearing the cookies (JSESSIONID, etc) stored in the cookie manager
of the thread.
I didn't find a straightforward way to achieve this, so the only way to get
my hands on the CookieManager was with a BSF Pre-Processor on the HTTP
Sampler of the login action with the following code(beanshell):
while(sampler.getCookieManager().getCookieCount() > 0)
// this clear all cookies but for some odd reason the new cookies aren't set

Test Plan
+Login fragment
++Login (HTTP Sampler)
+++Clear Cookie (BSF PreProcessor) - with the above code

Hope it will help others.

Shmuel Krakower. - re-use your jmeter scripts for application performance
monitoring from worldwide locations for free.

On Thu, Dec 20, 2012 at 5:02 PM, Sergio Boso <>wrote:

>  Hi,
> this is a really interesting question, although I would classify it as a
> "analysis " question.
> IMHO, the choice clearly comes out from the analysis of the behaviour of
> users on the specific application.
> For example, I recently tested a document management application that was
> used all day round by users, doing extensive data entry:
> clearly, in this particular case, the login usage was minimal (just once a
> day) and was negligible during the simulation.
> My test approach is to design one (or several) uses cases that mimic the
> actual user behaviour (you have ti spend a little time with end user to do
> that),
> and use them at a faster pace.
> In most cases, there is a login operation at beginning of the user cycle,
> and sometimes there is a logout at the end:
> I tend to reproduce the session time out by simply re-sending the login as
> a new user (most of the time simple authentication is not used).
> Otherwise, you have to wait for the normal session timeout which implies
> more longer loop (probably around 15 minutes) which in turn requires a lot
> of user ids.
> IN summary, there is no "simple" neither "standard" request to your answer.
> regards
> Sergio
> PS
> Season's greetings to all the list!!!
> Il 20/12/2012 15:02, Shmuel Krakower ha scritto:
> Hi,
> Thanks for the collaboration.
> Didn't got your first comment regarding loops.
> Anyway I think it will be some kind of a merge between option 2 and my
> needs.
> This is what I'll do:
> 1. To promise specific throughput per each transaction, I have separate
> thread groups per each transaction/set of very few transactions which must
> go together (like login->view a message, or login->view a message->post
> reply).
> 2. Then I set a Constant Throughput Timer to get the needed traffic on a
> transaction level (based on production stats).
> 3. So like this - a user that logged in for posting replies will do that
> during the entire load test.
> 4. With your suggestion - to cause users to log out in some percent,
> another user will login after a while and post replies. So that's another
> benefit for me (having replies from many users instead of the same few
> which logged in at ramp up).
> 5. I don't need DB to save session, all sessions are cookie sessions, so
> what I'll do is just clearing the session cookie with a BSF sampler
> (instead of putting more load with sending requests to the application
> logout action, which will cause non realistic load in some manner).
> Thanks again,
> Shmuel - re-use your jmeter scripts for application performance
> monitoring from worldwide locations for free.
> On Wed, Dec 19, 2012 at 5:19 PM, Adrian Speteanu <> <>wrote:
>  Hi,
> 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.
> Cheers,
> 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 - re-use your jmeter scripts for application performance
> monitoring from worldwide locations for free.
> --
> Ing. Sergio Boso

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