jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TincaTibo <TincaT...@gmail.com>
Subject Re: Question on Ramp Up period
Date Thu, 15 Apr 2010 05:21:38 GMT
Thanks for the complement Deepak, I'm always to much thinking of 'simulating
real usage' test case and not enough that people may want to analyse special
cases.

I was doing these analysis mostly by my own scripts, but it's true that
JMeter provides an easy and fast toolbox to do it!

Rgds,
Tibo

On Thu, Apr 15, 2010 at 00:32, Deepak Shetty <shettyd@gmail.com> wrote:

> Hi
> Other factors to consider is
> a. What are you trying to test
> For e.g. Suppose your application deadlocks sometimes and you need to
> simulate this. In this case you might not want a ramp up time , you
> actually
> do want your application to be hit at the same time . On the other hand if
> you are simulating actual user flows with think times then you dont want
> 500
> threads to be created at the exact same moment  since this probably isnt
> normal for your application. Or say you are caching data on the first
> request and the cache load is synchronized, then you might want to access
> the page in multiple threads at the same time to check the synchronized
> behavior so no ramp up. Or perhaps you want to see how many people can
> download a  large file at exactly the same time , you probably want to
> check
> with no rampup.
>
> b. If your test is a short test , then the results may be skewed negatively
> without ramp-up (because both your client and server have to be able to
> handle the initial burst of sockets/traffic). A ramp up also adds a certain
> degree of randomness that your threads will be reasonably distributed
> across
> requests.
>
> Most tests where you want to measure the performance would want ramp up.
> Most analysis sort of tests (like the deadlock/ cache tests) would not want
> a ramp up.
>
> regards
> deepak
>
> On Wed, Apr 14, 2010 at 10:09 AM, TincaTibo <TincaTibo@gmail.com> wrote:
>
> > Hi,
> >
> > A ramp up period is necessary when your application can't handle all user
> > connexions at the same time.
> > Connecting everybody at the same time usually does a useless stress on
> the
> > server, that will generates bad response times, server hang, or worse,
> > total
> > failure. Because the servers have to create all the application context /
> > thread / memory increase at once.
> >
> > To prevent that behaviour, ramp up is a good idea. Especially as in real
> > life, users does not connect all at once.
> >
> > As for the timings, whith 5 users, and a ramp up of 5s, with 300s
> duration:
> > - after 5s, all your threads will be started
> > - start rate at 1 / second approximately
> > - each thread will last 300s
> > - your test will end at 300 + 5 (time of last thread start) : that is to
> > say
> > : 305 s
> >
> > Play with it!
> >
> > Rgds,
> > Tibo
> >
> > On Wed, Apr 14, 2010 at 17:10, prasanna bhat <prasannabhat38@gmail.com
> > >wrote:
> >
> > > Hi,
> > >
> > > Description of Ramp Up period in the user manual :
> > > This property tells JMeter how long to delay between starting each
> user.
> > > For
> > > example, if you enter a Ramp-Up Period of 5 seconds, JMeter will finish
> > > starting all of your users by the end of the 5 seconds. So, if we have
> 5
> > > users and a 5 second Ramp-Up Period, then the delay between starting
> > users
> > > would be 1 second (5 users / 5 seconds = 1 user per second). If you set
> > the
> > > value to 0, JMeter will immediately start all users.
> > >
> > > Usecase description:
> > > I have 5 users in the thread, a Ramp Up period set to 5 sec and  the
> > > duration set to 300 sec in the Scheduler configuration. So for the
> first
> > 5
> > > seconds each thread is invoked with a delay of 1 sec, but is the same
> > > behavior(next thread is delayed for 1 sec) exhibited for the next 300
> > secs
> > > of test duration?
> > >
> > > And also i was not clear as to how Ramp Up period is advantageous? and
> > >  when
> > > to (and when not to) set this Ramp Up period?
> > >
> > > Thanks,
> > > Prasanna
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message