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 Krakower. www.Beatsoo.org - 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 <[email protected]>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 <[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. > > >
