Please ignore the second half of my previous post (also included at
the end of this post). The solution is below. Also, the use of
"ramp-up" seems to suggest that creating threads are quite expensive,
so still not sure if the solution below is the right approach to
control the number of new SSL sessions.
Solution is;
Test Plan
Thread Group (users 1800, ramp 180, count 100)
HTTP Request HTTPClient (SSL request - KeepAlive enabled)
Simple Data Writer
Thread Group (users 1800, ramp 90, count 100)
HTTP Request HTTPClient (SSL request - KeepAlive enabled)
Simple Data Writer
.......
.......
.......
Uniform Random Timer (Offset 10, dev 2)
Thanks, next time I'll post when I'm not sleep deprived!
Christiaan
> If the above is correct can I test the server for a scenario where for
> example; the server gets 10 new users (i.e. 10 threads or 10 SSL
> connections) each second and each user makes a 100 requests in that
> second and repeat the experiment for 3 mins to get a good average
> response time?
>
> Perhaps something like...
>
> Test Plan
> Thread Group (users 100, ramp 10, count 100)
> HTTP Request HTTPClient (SSL request - KeepAlive enabled)
> Uniform Random Timer (Offset 10, dev 2)
>
> ... but I need an average, over 3 mins, for each set of 10 users/sec
> (which need to be in separate files so that I can calculate the
> averages)
>
>
> Though perhaps I'm going against the grain as it seems that "ramp-up
> time" is there to ease the burden of creating many new threads rather
> than using it to create many new threads!?
>
>
> Many thanks
> Christiaan
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
