Hi, This sounds about right. The purpose is to simulate the amount of requests and whatever method gets you there is the way to go. What is not clear to me, on 5) - how will this ensure that not all users re-login? You'll also have to check if you have a session id or not before making the login request, right? In that case it seems more efficient your way.
Adrian S On Thu, Dec 20, 2012 at 4:02 PM, Shmuel Krakower <shmul...@gmail.com> wrote: > 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 <asp.ad...@gmail.com > >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 <shmul...@gmail.com> > > 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. > > > > > >
