jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hubbell <richard_hubb...@yahoo.com>
Subject Re: http request and .*
Date Tue, 30 Oct 2007 03:32:00 GMT
--- sebb <sebbaz@gmail.com> wrote:
> On 30/10/2007, Richard Hubbell
> > > The Link Parser only produces useful output when
> it
> > > finds a link. If
> > > there is no link in the previous page, it will
> not
> > > update the current
> > > sampler.
> >
> > So if the regex is "one or more of something" than
> I
> > should never see it trying to do a GET
> http://.+/.+
> > right? Or is something else at play here?
> >
> 
> I don't understand what you are saying here.
> 
> The Link Parser looks for links in the previous
> page, and tries to
> match them against the current sampler.

You don't understand me and I don't understand Jmeter.
We're not getting anywhere. 

I still don't understand how the sampler could 
do a GET http://.+/.+  

That's literally what the server sees Jmeter doing.
Can you explain the flow of that in pseudo-code?
(using the link parser and a sampler)

> 
> > >
> > > > In regexdom it's a bad idea to use .*, it
> should
> > > be
> > > > used sparingly.
> > >
> > > It's only a problem where there is trailing
> context,
> > > as that causes
> > > back-tracking.
> > >
> > > .* with nothing after it is OK, but .*?; would
> be
> > > better as [^;]*;
> > >
> > > Same for .+.
> > >
> > > >
> > > > >
> > > > > Another issue is using 1000 threads with 1
> loop
> > > just
> > > > > does not make sense.
> > > >
> > > > Does not make sense in general or just to you?
> It
> > > > makes sense to me. I would have used 10,000
> but
> > > the
> > > > jvm is a bit hungry with memory.  There may be
> > > some
> > > > tuning still needed.  Stack size, etc.
> > > >
> > > > Imagine that each loop does more than one
> thing.
> > > >
> > >
> > > But given the ramp-up time, the threads don't
> run in
> > > parallel. Even
> > > with a very short ramp-up time it's likely that
> the
> > > earlier threads
> > > will have finished before the later ones start.
> > >
> > > Better to run a few threads (or one thread)
> multiple
> > > times.
> >
> > Better for what?  Better's loaded with context.
> 
> Fewer resources.

Shouldn't be a limiting factor in testing, if it is,
it will be hard to push a system hard enough to see
how it behaves at high transaction rate.

> 
> > Not every test is a onesy-twosy affair.  Sometimes
> > people want 10,000 threads in parallel hammering a
> > website or service. It happens that way.  Better
> to
> > find out sooner if it's going to fall over.
> 
> Indeed, but 10,000 threads with 1 loop will have at
> most a few threads
> running in parallel at any one time.

That depends on the test though.

> 
> It is also not an efficient use of JMeter, as the
> thread startup costs
> are likely to be a significant proportion of the
> total.

See above.  Make sure to have plenty of RAM.

> 
> > >
> > > A single thread can represent multiple users.
> >
> > Yes and many threads can represent a single user.
> 
> I disagree; multiple parallel threads inherently
> represent multiple users.

It's not a matter of disagreeing, it's more about what
you want to test.  What if a page has 50 db
connections via ajax or something. One user loads one
page and that cause 50 transactions plus css, plus
imgs, plus js, plus, etc., etc.


> 
> E.g. a human user with a single keyboard can only
> provide input to a
> single browser at a time.

Not if they're running Jmeter. (^:
See above.

> 
> Though of course if one thread finishes before the
> next one begins
> they could represent one user, but then why bother
> with multiple
> threads?

Well maybe you want to do that to test something you
haven't imagined or encountered.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Mime
View raw message