curl-loader-devel

Re: check expression proposal.

[Robert I. <cor...@gm...>]

On 7/4/07, Michael Moser <mos...@gm...> wrote:
> Proposal for limited scripting facility in curl-loader

Great!

> ------------------------------------------------------
>
> scope: test result of fetching a url.
>        the facility must be able to
>       - test condition on body content and header content
OK
>       - conditional branching of flow

Great!

>       - return error messages

Probably, also to add some counters to statistic, like Err-Body,
Err-Hdrs?

>       - output messages into log.
OK.
Also some counters per client statistics?

Just not to forget, that we have logging of responses and headers
to files. This feature should still work (to test).

>
> New tags in configuration file.
>
> url=http://kuku/
> onget=<event_syntax>
>

Great! Makes it sense to separate it into events on response bodies
and separately events on response headers?

> onget is an action associated with action of processing a specific url;
> it is processed after the url has been retrieved/processed.
>
> (possible feature: event tag for execution prior to sending, so that we can
> manipulate header content, request url,  dynamically)

We can manipulate headers statically via tag HEADER.
Do you mean dynamic manipulations?

What we have in TODO list is also rather vague:
1. HTML analyses. libcurl example is using libtidy in:
   http://www.koders.com/c/fid7923BF828D0534D6B747ED138FCDD50DCFD13B3F.aspx
2. A regular expression pattern for a search in a response body
   Look in Apache JMeter.
3. Regular expression operations for the header/s certain header and whether
   value matches a regular expression pattern.
4. Vladislav proposed to add extraction of a field from response
   to be used in the next requests.

Let's try to come with a some narrow + broad subsets of features, that
we wish to implement, thus we can get a better filling of what we need
to develop.

Probably, you can look in WebLoad and JMeter, and in meanwhile
Vladislav, who is the former Mercury brain, can advise us in more details
regarding the features of LoadRunner not to spend time on their docs.

> - grammar is written with right recursion (since most probably there will be
> recursive descent parser)
>
> <event_syntax> ::= <statement-list>
>
> <statement-list> ::= <statement> | <statement> ; <statement-list>
>
> <statement> ::=  <goto_statement> | <label_definition> | <ifcondition> |
> <return> | <msg>
>
> <label_definition> ::= IDENTIFIER :
> - label definition
>
> <goto_statement> ::= goto <IDENTIFIER>
> - branch definition
>
> <msg> ::= echo <quoted string>
> - output to log file
>
> <return> ::= return NUMBER
> - stop execution of this client, return the number as status for this run.
>
> <ifcondition> ::= if <condition>  <statement-list> [<else-clause>] fi
>
> <else-clause> ::=  elsif <condition> <statement-list> <else-clause> | else
> <statement-list>
>
>
> - condition can test for content of body or header
> -
> <condition> ::= <and-condition> | <or-condition>
>
> <and-condition> ::= <or-condition> && <and-condition> | <or-condition>
>
> <or-condition> ::= <or-condition> || <test_condition> | <test_condition>
>
>  <test-condition> ::=  ( <condition> )  |
>                               <string-item> =~ /REGEX-STRING/ |      #
> search regex
>                               <string-item> eq QUOTED-STRING  |
>                                <string-item> ne QUOTED-STRING  |
>                               <int-item> eq INT_CONSTANT |
>                               <int-item>  ne INT_CONSTANT |
>                                <int-item>  gt INT_CONSTANT | (alo lt lte)

regexp?

> - item that has int value
> <int-item> ::= RESPONSE-STATUS
>
> - item that has string value
> <string-item>::= HEADER( IDENTIFIER ) |
>            RESPONSE-BODY |

I am OK with that.
Could you, please, look on the JMeter regexp and other HTTP response
analyzes?

Thanks, looks like we can define it more precisely and to develop a
great facility!

Michael, there is an option, that Vlad will wish to join the efforts to share
the design & implementation load.

I need to run more testing and to improve/update documentation, therefore
next version (stable 0.40) may be released in a week.

-- 
Sincerely,
Robert Iakobashvili,
coroberti %x40 gmail %x2e com
...........................................................
http://curl-loader.sourceforge.net
A web testing and traffic generation tool.

Re: check expression proposal.

[Aleksandar L. <al-...@no...>]

On Mit 04.07.2007 11:12, Robert Iakobashvili wrote:
>On 7/4/07, Michael Moser <mos...@gm...> wrote:
>> Proposal for limited scripting facility in curl-loader
>
>Great!

Yep, but what is wrong with one of the allready exists embeddable
Languages?!

lua
neko
perl
python
.
.
.

BR

Aleks

Re: check expression proposal.

[Robert I. <cor...@gm...>]

On 7/4/07, Aleksandar Lazic <al-...@no...> wrote:
> On Mit 04.07.2007 11:12, Robert Iakobashvili wrote:
> >On 7/4/07, Michael Moser <mos...@gm...> wrote:
> >> Proposal for limited scripting facility in curl-loader
> >
> >Great!
>
> Yep, but what is wrong with one of the allready exists embeddable
> Languages?!
>
> lua
> neko
> perl
> python

Thanks, Aleks, for your comments.

My understanding is that it is going to be a definitions language,
whereas the run-time is in C.
C is good.

Sincerely,
Robert Iakobashvili,
coroberti %x40 gmail %x2e com
...........................................................
http://curl-loader.sourceforge.net
A web testing and traffic generation tool.

Re: check expression proposal.

[Robert I. <cor...@gm...>]

>Yep, but what is wrong with one of the allready exists embeddable
>Languages?!

LUA would be the only appropriate solution, due to its very low memory
footprint during runtime (remember that we have lots of users running
at the same time.) Perl and python would be disqualified for this
reason (don't know about neko)

somehow Robert did not like the idea for the following reasons;

   - we tried to come up with a somewhat simpler (and more limited
solution), something less than scripting language; however the thing
still creeps back ;-)

   - with scripting language we have to redo the whole state machine
of curl-loader
     lets say we use lua; we would need one script that is in control
of the main loop (option #1)

     lets say the scripting language calls down to a C function that
gets the next URL, now we have
     deal with asynchronous IO situation - which leads us to need of
switching stacks, coprocedures

     Problems:
          - well it does redo the whole concept of configuration; etc.
etc. Its not the nicest thing in terms of having to deal with two sets
of configurations (one for scripts / one without script)
          - stack switching incurs memory overhead (see * 10k users is
quite a lot, but LUA)

     (option #2)  the alternative would be to have N scripts for each
URL and we invoke script number N upon download of url number N; now
they would all have their own script context, so no shared counters
for you. I think this solution is somewhat impractical.

   - possible optimization is not possible; with scripting language in
control we have to remember each incoming HTTP header, just in case
that the script will check presence/content of this HTTP header in the
future; with my proposal you see what headers are accessed, so no need
to remember them all; if no request body is requested then we don't
need to store request body at all !








On 7/4/07, Aleksandar Lazic <al-...@no...> wrote:
> On Mit 04.07.2007 11:12, Robert Iakobashvili wrote:
> >On 7/4/07, Michael Moser < mos...@gm...> wrote:
> >> Proposal for limited scripting facility in curl-loader
> >
> >Great!
>
> Yep, but what is wrong with one of the allready exists embeddable
> Languages?!
>
> lua
> neko
> perl
> python
> .
> .
> .
>
> BR
>
> Aleks
>



-- 
Sincerely,
Robert Iakobashvili,
coroberti %x40 gmail %x2e com
...........................................................
http://curl-loader.sourceforge.net
A web testing and traffic generation tool.

Re: check expression proposal.

[Robert I. <cor...@gm...>]

On 7/4/07, Aleksandar Lazic <al-...@no...> wrote:
> On Mit 04.07.2007 11:12, Robert Iakobashvili wrote:
> >On 7/4/07, Michael Moser <mos...@gm...> wrote:
> >> Proposal for limited scripting facility in curl-loader
> >
> >Great!
>
> Yep, but what is wrong with one of the allready exists embeddable
> Languages?!

There are great tools very flexible with various scripting support:
- JMeter;
- OpenSTA;
- WebLoad;

They are very flexible and have a great set of features,
that we would like to implement.
Does open-source community really need a one more
JMeter/OpenSTA/WebLoad?

What is indeed required may be Ixia IxLoad or Spirent Avalanche,
which are of less flexibility, but have 100 - 10000 higher loading capacity.

A friend of mine is using OpenSTA for rather simple load, and they are
using 20 PC computers (2 racks) to create a load of 50 000 connections.

We would like to provide a 10 -100 higher loading
capacity (than JMeter) with a good set of features and a high degree
of flexibility.

Therefore, C is the choice and SSL acceleration to HW is a future option.


Sincerely,
Robert Iakobashvili,
coroberti %x40 gmail %x2e com
...........................................................
http://curl-loader.sourceforge.net
A web testing and traffic generation tool.

Re: check expression proposal.

[Aleksandar L. <al-...@no...>]

On Mit 04.07.2007 22:48, Robert Iakobashvili wrote:
>On 7/4/07, Aleksandar Lazic <al-...@no...> wrote:
>>
>> Yep, but what is wrong with one of the allready exists embeddable
>> Languages?!
>
>There are great tools very flexible with various scripting support:
>- JMeter;
>- OpenSTA;
>- WebLoad;
>
>They are very flexible and have a great set of features, that we would
>like to implement.
>Does open-source community really need a one more
>JMeter/OpenSTA/WebLoad?

Nope you are right.

cheers

Aleks

Re: check expression proposal.

[Vlad W. <wvl...@gm...>]

Mercury LoadRunner uses C interpreter as the script engine. LR does not
provide desired performance (for single load generator machine) as well.
However, performance bottleneck is not in scripting but in protocol handling
(socket operations, HTTP analysis, infrastructure and OS impact, etc.).

The problem of scripting (like LR etc.) vs. configuration file using
(curl-loader batch) is rather architectural difficulty than performance, I
think. LR runs each virtual client in separate thread, while the scripting
engine instance exists for each client, whith its own context. Curl-loader
runs a lot of virtual clients in single thread. Script running become be
quite complicated in this case.

So, if high performance is the main target and curl-loader architecture is
the final choice, the client configuration is seemed to be right solution.

Thanks,
Vlad


On 7/4/07, Robert Iakobashvili <cor...@gm...> wrote:
>
> On 7/4/07, Aleksandar Lazic <al-...@no...> wrote:
> > On Mit 04.07.2007 11:12, Robert Iakobashvili wrote:
> > >On 7/4/07, Michael Moser <mos...@gm...> wrote:
> > >> Proposal for limited scripting facility in curl-loader
> > >
> > >Great!
> >
> > Yep, but what is wrong with one of the allready exists embeddable
> > Languages?!
>
> There are great tools very flexible with various scripting support:
> - JMeter;
> - OpenSTA;
> - WebLoad;
>
> They are very flexible and have a great set of features,
> that we would like to implement.
> Does open-source community really need a one more
> JMeter/OpenSTA/WebLoad?
>
> What is indeed required may be Ixia IxLoad or Spirent Avalanche,
> which are of less flexibility, but have 100 - 10000 higher loading
> capacity.
>
> A friend of mine is using OpenSTA for rather simple load, and they are
> using 20 PC computers (2 racks) to create a load of 50 000 connections.
>
> We would like to provide a 10 -100 higher loading
> capacity (than JMeter) with a good set of features and a high degree
> of flexibility.
>
> Therefore, C is the choice and SSL acceleration to HW is a future option.
>
>
> Sincerely,
> Robert Iakobashvili,
> coroberti %x40 gmail %x2e com
> ...........................................................
> http://curl-loader.sourceforge.net
> A web testing and traffic generation tool.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> curl-loader-devel mailing list
> cur...@li...
> https://lists.sourceforge.net/lists/listinfo/curl-loader-devel
>

Re: check expression proposal.

[Robert I. <cor...@gm...>]

On 7/5/07, Vlad W. <wvl...@gm...> wrote:
> Mercury LoadRunner uses C interpreter as the script engine. LR does not
> provide desired performance (for single load generator machine) as well.
> However, performance bottleneck is not in scripting but in protocol handling
> (socket operations, HTTP analysis, infrastructure and OS impact, etc.).

Interesting.

> The problem of scripting (like LR etc.) vs. configuration file using
> (curl-loader batch) is rather architectural difficulty than performance, I
> think. LR runs each virtual client in separate thread, while the scripting
> engine instance exists for each client, whith its own context. Curl-loader
> runs a lot of virtual clients in single thread. Script running become be
> quite complicated in this case.

Agree.
IMHO: We have a new option to distribute the load among several threads
for better SMP/multi-core utilization.

> So, if high performance is the main target and curl-loader architecture is
> the final choice, the client configuration is seemed to be right solution.

Thank you.

Sincerely,
Robert Iakobashvili,
coroberti %x40 gmail %x2e com
...........................................................
http://curl-loader.sourceforge.net
A web testing and traffic generation tool.