You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by li...@dankeeley.co.uk on 2007/05/24 12:01:19 UTC
Problem with regex extractor
Hi,
We use a regex extractor to extract a ref from an XML/RPC message, and
then use it in the next request to respond back. (An acknowledgement as
we call it )
The test runs for several hours over night. The test has many other
thread groups which send different messages. This is the only group that
uses a regex extractor.
During the run, 9961 ack's are sent. out of these, 18 fail because the
regex failed to extract the correct message ref. However our DB stores
the xml sent back and forth, and if i paste the xml into this link below:
http://jakarta.apache.org/oro/demo.html
then i can see that the message ref is correctly extracted.
So my question is, why am i getting these occasional failures? Or more to
the point, how can I investigate further?
( Also; I have 2 regex's following each other, would it be more efficient
if they could be combined into 1, and we could map the occurrance number
to the variable name? )
Thanks,
Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Problem with regex extractor
Posted by li...@dankeeley.co.uk.
Yes, this is a dual cpu solaris intel box. Using JMeter 2.2 and sun Java 6.
> I tried a simple test with 20 threads and 2 Java Request samplers,
> each with an RE Post-Processor child. No errors found even with 10,000
> loops. However this does not mean that there cannot be a threading
> issue.
>
> Just thought - are you running on a multiple-CPU box? That would offer
> more opportunities for thread synchronisation errors to show up.
>
> I have a dual-CPU system I can retry the test on later.
>
> S.
> On 24/05/07, lists@dankeeley.co.uk <li...@dankeeley.co.uk> wrote:
>> Ok, i'll try that different regex tonight. Also; no errors or warnings
>> in
>> the jmeter log i'm afraid!
>>
>> Rgds,
>> Dan
>>
>> > On 24/05/07, lists@dankeeley.co.uk <li...@dankeeley.co.uk> wrote:
>> >> >
>> >> > Perhaps there is a thread-safety problem.
>> >> > Does the RE use fixed strings, or are any variables used?
>> >> >
>> >>
>> >> The regex is simply:
>> >>
>> >> <value>(.+?)<
>> >> looking for the 16th match. The default value is "unset"
>> >
>> >>From the performance aspect it might be worth trying
>> >
>> > <value>([^<]+)
>> >
>> > as this does not require lookahead.
>> >
>> >> > How many threads in the thread group?
>> >>
>> >> This particular thread group has 10 threads. over all there are
>> about
>> >> 550
>> >> in use. The group itself has a read from csv, a counter, 2 samplers,
>> >> the
>> >> 2 regex's and finally a constant throughput timer.
>> >
>> > OK.
>> >
>> >>
>> >> >> the point, how can I investigate further?
>> >> >
>> >> > You could use the "Save Responses" Post-Processor as a child of
>> the
>> >> > samplers to create a copy of all the responses.
>> >>
>> >> I can already see the responses in our database. AFAIKT there's no
>> way
>> >> they could be any different to what comes out at the jmeter end, but
>> >> i'll
>> >> have a try.
>> >
>> > Should not be different, but they are presumably at different ends of
>> > a network connection, so it's remotely (!) possible.
>> >
>> >> > Is there any pattern to the failures?
>> >> > Do they match the wrong text, or do they fail to match at all?
>> >>
>> >> It seems to fail completely - I get the "unset" (default value) which
>> >> doesnt appear in the xml response at all, rather than the wrong
>> value.
>> >
>> > Any error/warning messages in the jmeter log file?
>> >
>> > S.
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>>
>
> ---------------------------------------------------------------------
> 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: Problem with regex extractor
Posted by sebb <se...@gmail.com>.
I tried a simple test with 20 threads and 2 Java Request samplers,
each with an RE Post-Processor child. No errors found even with 10,000
loops. However this does not mean that there cannot be a threading
issue.
Just thought - are you running on a multiple-CPU box? That would offer
more opportunities for thread synchronisation errors to show up.
I have a dual-CPU system I can retry the test on later.
S.
On 24/05/07, lists@dankeeley.co.uk <li...@dankeeley.co.uk> wrote:
> Ok, i'll try that different regex tonight. Also; no errors or warnings in
> the jmeter log i'm afraid!
>
> Rgds,
> Dan
>
> > On 24/05/07, lists@dankeeley.co.uk <li...@dankeeley.co.uk> wrote:
> >> >
> >> > Perhaps there is a thread-safety problem.
> >> > Does the RE use fixed strings, or are any variables used?
> >> >
> >>
> >> The regex is simply:
> >>
> >> <value>(.+?)<
> >> looking for the 16th match. The default value is "unset"
> >
> >>From the performance aspect it might be worth trying
> >
> > <value>([^<]+)
> >
> > as this does not require lookahead.
> >
> >> > How many threads in the thread group?
> >>
> >> This particular thread group has 10 threads. over all there are about
> >> 550
> >> in use. The group itself has a read from csv, a counter, 2 samplers,
> >> the
> >> 2 regex's and finally a constant throughput timer.
> >
> > OK.
> >
> >>
> >> >> the point, how can I investigate further?
> >> >
> >> > You could use the "Save Responses" Post-Processor as a child of the
> >> > samplers to create a copy of all the responses.
> >>
> >> I can already see the responses in our database. AFAIKT there's no way
> >> they could be any different to what comes out at the jmeter end, but
> >> i'll
> >> have a try.
> >
> > Should not be different, but they are presumably at different ends of
> > a network connection, so it's remotely (!) possible.
> >
> >> > Is there any pattern to the failures?
> >> > Do they match the wrong text, or do they fail to match at all?
> >>
> >> It seems to fail completely - I get the "unset" (default value) which
> >> doesnt appear in the xml response at all, rather than the wrong value.
> >
> > Any error/warning messages in the jmeter log file?
> >
> > S.
> >
> > ---------------------------------------------------------------------
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Problem with regex extractor
Posted by li...@dankeeley.co.uk.
Ok, i'll try that different regex tonight. Also; no errors or warnings in
the jmeter log i'm afraid!
Rgds,
Dan
> On 24/05/07, lists@dankeeley.co.uk <li...@dankeeley.co.uk> wrote:
>> >
>> > Perhaps there is a thread-safety problem.
>> > Does the RE use fixed strings, or are any variables used?
>> >
>>
>> The regex is simply:
>>
>> <value>(.+?)<
>> looking for the 16th match. The default value is "unset"
>
>>>From the performance aspect it might be worth trying
>
> <value>([^<]+)
>
> as this does not require lookahead.
>
>> > How many threads in the thread group?
>>
>> This particular thread group has 10 threads. over all there are about
>> 550
>> in use. The group itself has a read from csv, a counter, 2 samplers,
>> the
>> 2 regex's and finally a constant throughput timer.
>
> OK.
>
>>
>> >> the point, how can I investigate further?
>> >
>> > You could use the "Save Responses" Post-Processor as a child of the
>> > samplers to create a copy of all the responses.
>>
>> I can already see the responses in our database. AFAIKT there's no way
>> they could be any different to what comes out at the jmeter end, but
>> i'll
>> have a try.
>
> Should not be different, but they are presumably at different ends of
> a network connection, so it's remotely (!) possible.
>
>> > Is there any pattern to the failures?
>> > Do they match the wrong text, or do they fail to match at all?
>>
>> It seems to fail completely - I get the "unset" (default value) which
>> doesnt appear in the xml response at all, rather than the wrong value.
>
> Any error/warning messages in the jmeter log file?
>
> S.
>
> ---------------------------------------------------------------------
> 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: Problem with regex extractor
Posted by sebb <se...@gmail.com>.
On 24/05/07, lists@dankeeley.co.uk <li...@dankeeley.co.uk> wrote:
> >
> > Perhaps there is a thread-safety problem.
> > Does the RE use fixed strings, or are any variables used?
> >
>
> The regex is simply:
>
> <value>(.+?)<
> looking for the 16th match. The default value is "unset"
>From the performance aspect it might be worth trying
<value>([^<]+)
as this does not require lookahead.
> > How many threads in the thread group?
>
> This particular thread group has 10 threads. over all there are about 550
> in use. The group itself has a read from csv, a counter, 2 samplers, the
> 2 regex's and finally a constant throughput timer.
OK.
>
> >> the point, how can I investigate further?
> >
> > You could use the "Save Responses" Post-Processor as a child of the
> > samplers to create a copy of all the responses.
>
> I can already see the responses in our database. AFAIKT there's no way
> they could be any different to what comes out at the jmeter end, but i'll
> have a try.
Should not be different, but they are presumably at different ends of
a network connection, so it's remotely (!) possible.
> > Is there any pattern to the failures?
> > Do they match the wrong text, or do they fail to match at all?
>
> It seems to fail completely - I get the "unset" (default value) which
> doesnt appear in the xml response at all, rather than the wrong value.
Any error/warning messages in the jmeter log file?
S.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Problem with regex extractor
Posted by li...@dankeeley.co.uk.
>
> Perhaps there is a thread-safety problem.
> Does the RE use fixed strings, or are any variables used?
>
The regex is simply:
<value>(.+?)<
looking for the 16th match. The default value is "unset"
> How many threads in the thread group?
This particular thread group has 10 threads. over all there are about 550
in use. The group itself has a read from csv, a counter, 2 samplers, the
2 regex's and finally a constant throughput timer.
>> the point, how can I investigate further?
>
> You could use the "Save Responses" Post-Processor as a child of the
> samplers to create a copy of all the responses.
I can already see the responses in our database. AFAIKT there's no way
they could be any different to what comes out at the jmeter end, but i'll
have a try.
> Is there any pattern to the failures?
> Do they match the wrong text, or do they fail to match at all?
It seems to fail completely - I get the "unset" (default value) which
doesnt appear in the xml response at all, rather than the wrong value.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Problem with regex extractor
Posted by sebb <se...@gmail.com>.
On 24/05/07, lists@dankeeley.co.uk <li...@dankeeley.co.uk> wrote:
> Hi,
>
> We use a regex extractor to extract a ref from an XML/RPC message, and
> then use it in the next request to respond back. (An acknowledgement as
> we call it )
>
> The test runs for several hours over night. The test has many other
> thread groups which send different messages. This is the only group that
> uses a regex extractor.
>
> During the run, 9961 ack's are sent. out of these, 18 fail because the
> regex failed to extract the correct message ref. However our DB stores
> the xml sent back and forth, and if i paste the xml into this link below:
>
> http://jakarta.apache.org/oro/demo.html
>
> then i can see that the message ref is correctly extracted.
>
> So my question is, why am i getting these occasional failures? Or more to
Perhaps there is a thread-safety problem.
Does the RE use fixed strings, or are any variables used?
How many threads in the thread group?
> the point, how can I investigate further?
You could use the "Save Responses" Post-Processor as a child of the
samplers to create a copy of all the responses.
Is there any pattern to the failures?
Do they match the wrong text, or do they fail to match at all?
> ( Also; I have 2 regex's following each other, would it be more efficient
> if they could be combined into 1, and we could map the occurrance number
> to the variable name? )
Very difficult to say in general - you would have to test it, as
different REs can have very different perfomance characteristics.
But it is likely that a simple combination such as
num1=(\d+)\s+num2=(\d+)
would be more efficient than
num1=(\d+)
followed by
num2=(\d+)
> Thanks,
> Dan
>
>
> ---------------------------------------------------------------------
> 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