Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

[10:58:00 CST(-0600)] <drewwills> dd how much pause have you scripted between simulated user actions in your jmeter scripts?

[10:59:34 CST(-0600)] <dd> i have a 5 sec pause when it submits credentials and when it logs out

[10:59:46 CST(-0600)] <dd> turned it down to 3 and no difference

[11:00:06 CST(-0600)] <drewwills> is that all the script does? log in and log out?

[11:00:36 CST(-0600)] <dd> logs in through CAS, gets ticket, goes to uPortal, goes to User preference page, logs out

[11:00:37 CST(-0600)] <drewwills> that's fine of so... just trying to get a picture

[11:01:25 CST(-0600)] <dd> drewwills: could i send you my test to look at? maybe i have something setup incorrectly, this is the first time i've used jmeter

[11:01:29 CST(-0600)] <drewwills> I'd suggest turning it up... try 6-10 sec pauses between any user action

[11:01:56 CST(-0600)] <drewwills> i can look quickly... no guarentee i'd cactch something though

[11:02:08 CST(-0600)] <drewwills> can you sent it to the user list?

[11:04:43 CST(-0600)] <dd> i don't have an account

[11:04:52 CST(-0600)] <dd> i was just going to give you a dropbox url

[11:05:26 CST(-0600)] <drewwills> sure

[11:05:30 CST(-0600)] <dd> https://dl.dropbox.com/u/1922282/test.jmx

[11:06:09 CST(-0600)] <drewwills> EricDalquist i was giving uPortal Platform training at USU last week... whipped up a fix for this on the plane: https://issues.jasig.org/browse/UP-3623

[11:06:19 CST(-0600)] <EricDalquist> great

[11:06:32 CST(-0600)] <drewwills> i was inspired, having just dealt with LDAP settings on like 8 different laptops

[11:07:44 CST(-0600)] <dd> drewwills: i have to run for a meeting but i will be back in ~30mins. thank you for your help

[11:08:20 CST(-0600)] <drewwills> k, i'll look in a few

[12:12:50 CST(-0600)] <dd> back

[12:25:57 CST(-0600)] <drewwills> dd – I think you realistically need a RAMPUP period of some number (i suggest 6) * number of threads

[12:26:32 CST(-0600)] <drewwills> you could try 3*threads as well... but ramping up all your threads in 3 sec is probably too quick

[12:29:22 CST(-0600)] <dd> drewwills: i'll try that, and i should have a constant timer on all user actions?

[12:31:21 CST(-0600)] <drewwills> i'll put it this way – a real user normally wais a number of seconds after getting a response before submitting the next request

[12:31:39 CST(-0600)] <drewwills> just choose a conservative but realistic model for that

[12:32:16 CST(-0600)] <drewwills> if you put zero pauses in, jmeter just hammers the portal as quick as it can, and I know it doesn't take too many threads of that to slow it down

[12:32:45 CST(-0600)] <dd> makes sense

[12:33:16 CST(-0600)] <dd> jmeter does give me connection refused errors sometimes, what tomcat settings does that correlate with?

[12:34:31 CST(-0600)] <drewwills> if all the tomcat request-serving threads fill up... i can't remember, i think there may be a fixed-sized queue after that

[12:34:52 CST(-0600)] <drewwills> but if the threads and the queue get exhausted, it will just start refusing them

[12:35:35 CST(-0600)] <dd> are those the maxThreads and acceptCount settings?

[12:36:05 CST(-0600)] <drewwills> i can't remember, but it sounds right

[12:36:22 CST(-0600)] <drewwills> there's decent docs online for tomcat... i always have to look

[12:37:54 CST(-0600)] <dd> yeah, i think that's what i read. one more question, we're trying to test for a good amount of users (500-750) using the portal at a time, will a large rampup time affect this? give that the whole test sequence doesn't take that long?

[12:38:16 CST(-0600)] <dd> would i need to artificially slow it down somewhere while the thread is still in the portal?

[12:39:11 CST(-0600)] <dd> or is that what looping is for?

[12:39:36 CST(-0600)] <EricDalquist> http://jmeter.apache.org/usermanual/component_reference.html#Constant_Throughput_Timer

[12:39:46 CST(-0600)] <EricDalquist> so what I usually do when testing is:

[12:40:00 CST(-0600)] <EricDalquist> determine desired throughput (requests / second usually)

[12:40:16 CST(-0600)] <EricDalquist> determine desired concurrent user base (number of threads)

[12:40:25 CST(-0600)] <EricDalquist> write the script for what each "user" does

[12:40:55 CST(-0600)] <EricDalquist> setup the thread count of X and ramp up time of X * 5

[12:41:17 CST(-0600)] <EricDalquist> have the test set to run with each thread looping "forever"

[12:41:26 CST(-0600)] <EricDalquist> that constant throughput timer is the key

[12:41:57 CST(-0600)] <EricDalquist> you set that do something like 60 samples/minute with the Calculate Throughput Based on "all active threads (shared)"

[12:42:22 CST(-0600)] <EricDalquist> then your portal will see no more than 1 request / second across all of the threads you have running

[12:42:38 CST(-0600)] <EricDalquist> it of course could be slower than that if the target system can't keep up

[12:42:46 CST(-0600)] <EricDalquist> but the CTT is your throttle

[12:43:06 CST(-0600)] <EricDalquist> and that "all active threads (shared)" setting is crucial

[12:43:14 CST(-0600)] <EricDalquist> otherwise it is per-thread throughput

[12:43:26 CST(-0600)] <EricDalquist> which is really impossible to get a decent repeatable test setup with

[12:43:33 CST(-0600)] <dd> ah, ok. i had that timer in there before but didn't have "all active threads"

[12:44:09 CST(-0600)] <dd> so you have it loop forever until you get errors or have enough data?

[12:44:34 CST(-0600)] <EricDalquist> yup

[12:44:47 CST(-0600)] <EricDalquist> generally we run tests where I'm watcfhing it

[12:45:08 CST(-0600)] <EricDalquist> if I wanted an automated test I'd set the scheduler bit in the thread group control to run for a fixed time

[12:45:13 CST(-0600)] <EricDalquist> so threads still loop forever

[12:45:21 CST(-0600)] <EricDalquist> but the whole test may only run for X minutes

[12:45:30 CST(-0600)] <EricDalquist> and 3-5 seconds per thread on ramp up is really needed

[12:46:54 CST(-0600)] <dd> ok, thank you EricDalquist and drewwills, great places to start, much appreciated