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 <[email protected]> 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. > www.Beatsoo.org - re-use your jmeter scripts for application performance > monitoring from worldwide locations for free. >
