0
votes

I am creating a JMeter test plan and need some validation to verify I'm going about it the right way.

I have the following GA data for our busiest hour.

Hour: 10    
Average session duration: 00:02:56
Avg. Page Load Time (sec): 1.57 
Sessions: 2441
Page Views: 8361

Number of threads (users):

I've calculated this using the following formula:

2441 (Hourly Sessions) x 176 (Average Session Duration (in seconds)) / 3600

Which gives me 119.

1) Is this the correct approach?

Getting average page load time

I'm attempting to bench mark against the average page load time as reported by GA. So I have created currently the following test plan:

Thread Group:

  - HTTP Request (Main Request)
  - Aggregate graph

1) This will request (main request) 119 times should I add more pages so that requests total 8361 as per the pages views from GA?

2) I'm unclear about how I should get the test plan to run over an hour as the GA data is over an hour, currently the 119 requests get executed within a few minutes or is it even necessary to run over an hour to get a rough idea of capacity?

3) Is it correct to use the average response time from the aggregate graph and compare that against the Avg. Page Load Time from GA?

1
VUsers = visit rate / (60/visit length) 2441/(60/1.57) = 63. Use 63 thread group and add appropriate timers to the test plan and execute it for 1 hour. Collect the metrics and compare. You cannot conclude the performance tests in 1 run. Multiple iterations are required. - NaveenKumar Namachivayam

1 Answers

0
votes

1.1) Seems like that - but only if you stick to mimic-ing the actual "average user" way to interact with your service: do some chain of requests (let's call it session) during 176 sec.

Then, yes: if inside one thread, you'd stretch your chain of requests along 176 sec, 1 thread could serve ~20.5 sessions per hour.

Which turns into ~119 threads to meet desired ~2440 requests per hour.

The other approach would be to stick to Page views (8361). That's if maintaining the "session" and particular request sequence doesn't matter, while load does.

Then it comes to ~2.3 rps flat. As soon as response time is expected to be around 1.5 sec, you would need at least 3 threads to keep the pace, more would be better to have some room to stretch. But you won't need a lot of them, because they'd be hanging blocked with I/O most of the time.

Checking the actual throughput value JMeter yields during initial runs, you could adjust the number of threads to optimal.