You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Richard Hubbell <ri...@yahoo.com> on 2007/10/20 01:31:24 UTC
http request and .*
The http request always ends up on http://.*/.*
Is there a way to prevent that from happening?
I followed the example which describes to use those
regex in the server and path fields in the http
request. I am using the html link parser.
__________________________________________________
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
Re: http request and .*
Posted by Richard Hubbell <ri...@yahoo.com>.
--- sebb <se...@gmail.com> wrote:
> > Can you explain the flow of that in pseudo-code?
> > (using the link parser and a sampler)
>
> See above.
Ok, you can't, fair enough.
I wonder if others using Jmeter have problems when
they attempt any complex test plans.
I think the examples are a good start but they're too
similar to each other and
don't show enough of what the tool can do.
The GUI abstracts what's happening underneath too far
and so it's hard to
follow what's happening.
What do other newcomers think about using Jmeter?
Easy? Hard? Could use a little more
of this? Or that?
__________________________________________________
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
Re: http request and .*
Posted by sebb <se...@gmail.com>.
On 30/10/2007, Richard Hubbell <ri...@yahoo.com> wrote:
> --- sebb <se...@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.
"This modifier parses HTML response from the server and extracts links
and forms. A URL test sample that passes through this modifier will be
examined to see if it "matches" any of the links or forms extracted
from the immediately previous response. It would then replace the
values in the URL test sample with appropriate values from the
matching link or form. Perl-type regular expressions are used to find
matches.
Matches are performed using protocol, host, path and parameter names.
The target sampler cannot contain parameters that are not in the
response links."
If the sampler does not match any links (or there are no links) then
the sampler will not be modified.
> I still don't understand how the sampler could
> do a GET http://.+/.+
If the sampler has not been modified, then it will do whatever you
have told it to do.
> That's literally what the server sees Jmeter doing.
Of course.
> Can you explain the flow of that in pseudo-code?
> (using the link parser and a sampler)
See above.
> >
> > > >
> > > > > 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.
Indeed, which is why it is important to use the test tool efficiently.
> >
> > > 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.
Of course.
But more threads still require more resources.
> >
> > 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.
And CPU.
> >
> > > >
> > > > 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.
But that is not a real-world user.
>
> >
> > 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.
Of course you are free to use JMeter as you see fit.
> __________________________________________________
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: http request and .*
Posted by Richard Hubbell <ri...@yahoo.com>.
--- sebb <se...@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
Re: http request and .*
Posted by sebb <se...@gmail.com>.
On 30/10/2007, Richard Hubbell <ri...@yahoo.com> wrote:
>
> --- sebb <se...@gmail.com> wrote:
> > > I guess bugzilla would be best in this case, I'll
> > do
> > > that. In a sense it's unfortunate that the jmx
> > files
> > > can't be discussed right here since this is a user
> > > group and users seem to have many questions about
> > the
> > > jmx since the jmx is everything.
> >
> > By all means discuss JMeter test plans, but posting
> > anything more than
> > a very short extract is counter-productive IMO.
> >
> > The only easy way to "read" the files is to load
> > them into JMeter, and
> > that is not at all easy to do from a mailgroup
> > posting.
> >
> > Even extracts from jmeter log files are difficult to
> > read when posted
> > in an e-mail because of the line-wrapping that
> > occurs.
> >
> > > Jmeter is the jmx from a user perspective.
> > >
> > > >
>
> > >
> > > It is possible, but what's the alternative for
> > > recursing over links on pages? I tried using the
> > > feature in the HTTP Request sampler to get only
> > > "Embedded URLs must match" regex but that was too
> > > limiting. Can you describe in greater detail how
> > > complex a regex can go into that field?
> >
> > As complex as you like, but of course that may
> > increase the resources
> > needed to process it.
> >
> > > Would something like this work?
> > > href="([^"]+)"|img="([^\s]+)"|imgurl="([^\s]+)"
> >
> > What are you trying to achieve?
>
> Trying to match as many embedded url types as
> possible.
In that case, why try to restrict the URLs that match?
> Will that work?
>
> >
> > > I think you get the idea, there are more than one
> > type
> > > of embedded url I'm interested in traversing
> > further.
> > >
> > > I also tried http://.+/.+ but that didn't work,
> > but I
> > > would have thought that would have solved the
> > issue.
> > > Maybe it's a missing feature/bug.
> >
> > 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.
> >
> > > 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.
> 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.
It is also not an efficient use of JMeter, as the thread startup costs
are likely to be a significant proportion of the total.
> >
> > 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.
E.g. a human user with a single keyboard can only provide input to a
single browser at a time.
Though of course if one thread finishes before the next one begins
they could represent one user, but then why bother with multiple
threads?
> >
> > Multiple threads are normally used to represent
> > multiple concurrent users.
>
> That too, yeah the test is many users in parallel,
> traversing a website. It happens that way.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: http request and .*
Posted by Richard Hubbell <ri...@yahoo.com>.
--- sebb <se...@gmail.com> wrote:
> > I guess bugzilla would be best in this case, I'll
> do
> > that. In a sense it's unfortunate that the jmx
> files
> > can't be discussed right here since this is a user
> > group and users seem to have many questions about
> the
> > jmx since the jmx is everything.
>
> By all means discuss JMeter test plans, but posting
> anything more than
> a very short extract is counter-productive IMO.
>
> The only easy way to "read" the files is to load
> them into JMeter, and
> that is not at all easy to do from a mailgroup
> posting.
>
> Even extracts from jmeter log files are difficult to
> read when posted
> in an e-mail because of the line-wrapping that
> occurs.
>
> > Jmeter is the jmx from a user perspective.
> >
> > >
> >
> > It is possible, but what's the alternative for
> > recursing over links on pages? I tried using the
> > feature in the HTTP Request sampler to get only
> > "Embedded URLs must match" regex but that was too
> > limiting. Can you describe in greater detail how
> > complex a regex can go into that field?
>
> As complex as you like, but of course that may
> increase the resources
> needed to process it.
>
> > Would something like this work?
> > href="([^"]+)"|img="([^\s]+)"|imgurl="([^\s]+)"
>
> What are you trying to achieve?
Trying to match as many embedded url types as
possible.
Will that work?
>
> > I think you get the idea, there are more than one
> type
> > of embedded url I'm interested in traversing
> further.
> >
> > I also tried http://.+/.+ but that didn't work,
> but I
> > would have thought that would have solved the
> issue.
> > Maybe it's a missing feature/bug.
>
> 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?
>
> > 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.
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.
>
> A single thread can represent multiple users.
Yes and many threads can represent a single user.
>
> Multiple threads are normally used to represent
> multiple concurrent users.
That too, yeah the test is many users in parallel,
traversing a website. It happens that way.
__________________________________________________
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
Re: http request and .*
Posted by sebb <se...@gmail.com>.
On 30/10/2007, Richard Hubbell <ri...@yahoo.com> wrote:
>
> --- sebb <se...@gmail.com> wrote:
>
> > On 27/10/2007, Richard Hubbell
> > <ri...@yahoo.com> wrote:
> > > This is the jmx. So you don't have to go back over
> > the
> > > thread on this I was having problems where jmeter
> > > would send requests to the server like
> > http://.*/.*
> > >
> > > I'd really like to figure out how to have it not
> > do
> > > that since it creates a lot of noise in the server
> > > logs and in the jmeter logs, etc.
> > >
> > > If this is hard to read I can re-send as an
> > > attachment.
> >
> > It *is* hard to read - and makes the mail hard for
> > others to read.
> > Anyway it is not usable as it stands.
> >
> > However, please don't send attachments to the list
> > either.
> >
> > Either store the JMX file on a public server, or
> > create a Bugzilla
> > issue and attach the file to that.
>
> I guess bugzilla would be best in this case, I'll do
> that. In a sense it's unfortunate that the jmx files
> can't be discussed right here since this is a user
> group and users seem to have many questions about the
> jmx since the jmx is everything.
By all means discuss JMeter test plans, but posting anything more than
a very short extract is counter-productive IMO.
The only easy way to "read" the files is to load them into JMeter, and
that is not at all easy to do from a mailgroup posting.
Even extracts from jmeter log files are difficult to read when posted
in an e-mail because of the line-wrapping that occurs.
> Jmeter is the jmx from a user perspective.
>
> >
> > Please make sure that any such test cases are as
> > small as possible (no
> > extraneous stuff) and all necessary supporting files
> > are present.
> > Also please attach a copy of the jmeter log file
> > from running the test case.
> >
> > In the case of your JMX, I did manage to get the
> > file to load
> > (eventually), but it is unusable as there are
> > several mising files.
> >
> > It's not clear that the While Controller is
> > guaranteed to exit, and
> > the Link Parser is being applied to the previous
> > sample in the loop so
> > it's not surprising that it sometimes does not find
> > a match - are all
> > the previous pages guaranteed to contain a link or a
> > form?
>
> It is possible, but what's the alternative for
> recursing over links on pages? I tried using the
> feature in the HTTP Request sampler to get only
> "Embedded URLs must match" regex but that was too
> limiting. Can you describe in greater detail how
> complex a regex can go into that field?
As complex as you like, but of course that may increase the resources
needed to process it.
> Would something like this work?
> href="([^"]+)"|img="([^\s]+)"|imgurl="([^\s]+)"
What are you trying to achieve?
> I think you get the idea, there are more than one type
> of embedded url I'm interested in traversing further.
>
> I also tried http://.+/.+ but that didn't work, but I
> would have thought that would have solved the issue.
> Maybe it's a missing feature/bug.
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.
> 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.
A single thread can represent multiple users.
Multiple threads are normally used to represent multiple concurrent users.
>
> __________________________________________________
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: http request and .*
Posted by Richard Hubbell <ri...@yahoo.com>.
--- sebb <se...@gmail.com> wrote:
> On 27/10/2007, Richard Hubbell
> <ri...@yahoo.com> wrote:
> > This is the jmx. So you don't have to go back over
> the
> > thread on this I was having problems where jmeter
> > would send requests to the server like
> http://.*/.*
> >
> > I'd really like to figure out how to have it not
> do
> > that since it creates a lot of noise in the server
> > logs and in the jmeter logs, etc.
> >
> > If this is hard to read I can re-send as an
> > attachment.
>
> It *is* hard to read - and makes the mail hard for
> others to read.
> Anyway it is not usable as it stands.
>
> However, please don't send attachments to the list
> either.
>
> Either store the JMX file on a public server, or
> create a Bugzilla
> issue and attach the file to that.
I guess bugzilla would be best in this case, I'll do
that. In a sense it's unfortunate that the jmx files
can't be discussed right here since this is a user
group and users seem to have many questions about the
jmx since the jmx is everything.
Jmeter is the jmx from a user perspective.
>
> Please make sure that any such test cases are as
> small as possible (no
> extraneous stuff) and all necessary supporting files
> are present.
> Also please attach a copy of the jmeter log file
> from running the test case.
>
> In the case of your JMX, I did manage to get the
> file to load
> (eventually), but it is unusable as there are
> several mising files.
>
> It's not clear that the While Controller is
> guaranteed to exit, and
> the Link Parser is being applied to the previous
> sample in the loop so
> it's not surprising that it sometimes does not find
> a match - are all
> the previous pages guaranteed to contain a link or a
> form?
It is possible, but what's the alternative for
recursing over links on pages? I tried using the
feature in the HTTP Request sampler to get only
"Embedded URLs must match" regex but that was too
limiting. Can you describe in greater detail how
complex a regex can go into that field?
Would something like this work?
href="([^"]+)"|img="([^\s]+)"|imgurl="([^\s]+)"
I think you get the idea, there are more than one type
of embedded url I'm interested in traversing further.
I also tried http://.+/.+ but that didn't work, but I
would have thought that would have solved the issue.
Maybe it's a missing feature/bug.
In regexdom it's a bad idea to use .*, it should be
used sparingly.
>
> 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.
__________________________________________________
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
Re: http request and .*
Posted by sebb <se...@gmail.com>.
On 27/10/2007, Richard Hubbell <ri...@yahoo.com> wrote:
> This is the jmx. So you don't have to go back over the
> thread on this I was having problems where jmeter
> would send requests to the server like http://.*/.*
>
> I'd really like to figure out how to have it not do
> that since it creates a lot of noise in the server
> logs and in the jmeter logs, etc.
>
> If this is hard to read I can re-send as an
> attachment.
It *is* hard to read - and makes the mail hard for others to read.
Anyway it is not usable as it stands.
However, please don't send attachments to the list either.
Either store the JMX file on a public server, or create a Bugzilla
issue and attach the file to that.
Please make sure that any such test cases are as small as possible (no
extraneous stuff) and all necessary supporting files are present.
Also please attach a copy of the jmeter log file from running the test case.
In the case of your JMX, I did manage to get the file to load
(eventually), but it is unusable as there are several mising files.
It's not clear that the While Controller is guaranteed to exit, and
the Link Parser is being applied to the previous sample in the loop so
it's not surprising that it sometimes does not find a match - are all
the previous pages guaranteed to contain a link or a form?
Another issue is using 1000 threads with 1 loop just does not make sense.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: http request and .*
Posted by sebb <se...@gmail.com>.
On 23/10/2007, Richard Hubbell <ri...@yahoo.com> wrote:
>
> --- sebb <se...@gmail.com> wrote:
>
> > Sampler: http://www.google.com/
> >
> > Sampler: host=.* path=.* parameter: hl=.*
> > + Link Preprocessor
> >
> > What did you try?
>
> Mine differs a little. I used a CSV file element for
> the thread group, so a variable passed to the 1st
> sampler (google in your case) and I didn't use the
> "parameter: hl=.*" as you have it.
Mine also works without the hl parameter.
Try and get it working without variables at first.
> >
> > On 22/10/2007, Richard Hubbell
> > <ri...@yahoo.com> wrote:
> > >
> > > --- sebb <se...@gmail.com> wrote:
> > >
> > > > Works for me.
> > > >
> > > > But you need to ensure that any parameters in
> > the
> > > > sampler are matched,
> > > > or it won't update the sampler.
> > > >
>
>
>
> __________________________________________________
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: http request and .*
Posted by Richard Hubbell <ri...@yahoo.com>.
--- sebb <se...@gmail.com> wrote:
> Sampler: http://www.google.com/
>
> Sampler: host=.* path=.* parameter: hl=.*
> + Link Preprocessor
>
> What did you try?
Mine differs a little. I used a CSV file element for
the thread group, so a variable passed to the 1st
sampler (google in your case) and I didn't use the
"parameter: hl=.*" as you have it.
>
> On 22/10/2007, Richard Hubbell
> <ri...@yahoo.com> wrote:
> >
> > --- sebb <se...@gmail.com> wrote:
> >
> > > Works for me.
> > >
> > > But you need to ensure that any parameters in
> the
> > > sampler are matched,
> > > or it won't update the sampler.
> > >
__________________________________________________
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
Re: http request and .*
Posted by sebb <se...@gmail.com>.
Sampler: http://www.google.com/
Sampler: host=.* path=.* parameter: hl=.*
+ Link Preprocessor
What did you try?
On 22/10/2007, Richard Hubbell <ri...@yahoo.com> wrote:
>
> --- sebb <se...@gmail.com> wrote:
>
> > Works for me.
> >
> > But you need to ensure that any parameters in the
> > sampler are matched,
> > or it won't update the sampler.
> >
>
> It's difficult to know what "works for me" means when
> you don't give any details. Can you give a concrete
> example of what works for you?
>
> __________________________________________________
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
HTTp Proxy Server recording aplications with Ajax
Posted by Adrián Alberto Rojas González <ar...@AVANTICATEC.NET>.
Hi, all
I have a question, Jmeter can recording aplications that it development with Ajax (this aplication use the Google Web Tool Kit)? Because I used the "HTTp Proxy Server" to recorder the test in the aplication and the request not recording, please help me
Thanks
Adrian
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: http request and .*
Posted by Richard Hubbell <ri...@yahoo.com>.
--- sebb <se...@gmail.com> wrote:
> Works for me.
>
> But you need to ensure that any parameters in the
> sampler are matched,
> or it won't update the sampler.
>
It's difficult to know what "works for me" means when
you don't give any details. Can you give a concrete
example of what works for you?
__________________________________________________
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
Re: http request and .*
Posted by sebb <se...@gmail.com>.
Works for me.
But you need to ensure that any parameters in the sampler are matched,
or it won't update the sampler.
On 21/10/2007, Richard Hubbell <ri...@yahoo.com> wrote:
>
> --- sebb <se...@gmail.com> wrote:
>
> > It's difficult to give any advice without a bit more
> > infomation.
> >
> > Which example are you following?
> >
> > What have you put in the sampler fields?
>
> For recursing the links in each HTTP Request I'm using
> the HTML Link Parser. Which states using the regex .*
> for the path and the server fields. The problem is
> that Jmeter is trying to use those literally at some
> point and that causes an error. How do I prevent
> that? Is it a bug?
>
> >
> > On 20/10/2007, Richard Hubbell
> > <ri...@yahoo.com> wrote:
> > > The http request always ends up on http://.*/.*
> > > Is there a way to prevent that from happening?
> > > I followed the example which describes to use
> > those
> > > regex in the server and path fields in the http
> > > request. I am using the html link parser.
>
>
> __________________________________________________
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: http request and .*
Posted by Richard Hubbell <ri...@yahoo.com>.
--- sebb <se...@gmail.com> wrote:
> It's difficult to give any advice without a bit more
> infomation.
>
> Which example are you following?
>
> What have you put in the sampler fields?
For recursing the links in each HTTP Request I'm using
the HTML Link Parser. Which states using the regex .*
for the path and the server fields. The problem is
that Jmeter is trying to use those literally at some
point and that causes an error. How do I prevent
that? Is it a bug?
>
> On 20/10/2007, Richard Hubbell
> <ri...@yahoo.com> wrote:
> > The http request always ends up on http://.*/.*
> > Is there a way to prevent that from happening?
> > I followed the example which describes to use
> those
> > regex in the server and path fields in the http
> > request. I am using the html link parser.
__________________________________________________
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
Re: http request and .*
Posted by sebb <se...@gmail.com>.
It's difficult to give any advice without a bit more infomation.
Which example are you following?
What have you put in the sampler fields?
On 20/10/2007, Richard Hubbell <ri...@yahoo.com> wrote:
> The http request always ends up on http://.*/.*
> Is there a way to prevent that from happening?
> I followed the example which describes to use those
> regex in the server and path fields in the http
> request. I am using the html link parser.
>
> __________________________________________________
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org