curl-loader-devel — curl-loader usage and development issues

Re: WebLoad HTTP performance numbers

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

On 7/10/07, Vlad W. <wvl...@gm...> wrote:
>>http://www.sqaforums.com/showflat.php?Cat=0&Number=381616&an=0&page=0#Post381616
> > >>
> > >> People found, that performance of Webload is below 2000 virtual clients
> > >> and other numbers being also not so impressive (we have reached 60 000
> > >> and are limited mainly by the memory of the available HW).
> > >>
> > >> We are talking, that 30-35 K for each virtual client is too much,
> whereas
> > >> WebLoad is taking an order more.
> >
> >
> > > what about loadrunner (former mercury, now hp) ?
> >
> > Please, address always to the list:
> > cur...@li....
> >
> > For example, I do not know, but Vlad seems to be in position to
> > comment about Mercury LoadRunner numbers.

> It was long time ago and I don't remember the numbers...

Y are kidding ...
>
> Roughly, LoadRunner performace depends of the choosed protocol and virtual
> client complexity.
> Since LR is positioned as business process oriented tool, it is usually used
> running "GUI level" protocol which builds DOM and runs javascripts. Resulted
> performance is relativelylow (hundreds concurrent virtual users for single
> machine) but virtual user script is quite simple and easy to maintanace.
>
> HTTP level protocol provides thousands concurrent virtual users on single
> load generator machine, but business process implementation become be very
> complicated task, providing good job for LR experts.
>
> So, LR is definitely not the best stress testing tool. However, for business
> process oriented load testing it is the best that I know. At the same time,
> if performance is the issue, LR can use multiple load generator machines.
> Usually, users are limited rather by the license than by performance issues.

Thank you, Vlad.

To conclude, LoadRunner is also not in business of performance and stress
load testing, but rather in business process testing.

On the high-end we will be competing with IXIA IxLoad and Spirent Avalanche,
and by adding more context analysis features will fill the gap between
the Big-HW tools and business process testing (WebLoad, LoadRunner, OpenSTA),


Apache JMeter is quite another story.
JMeter is a really great open-source community project. We may
co-operate with them
by e.g. using the same Regex definitions, using the same proxy for fetching
user behavior for our batch files, etc and where is possible, assist to them.

> Thanks,
> Vlad.


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

Re: WebLoad HTTP performance numbers

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

On 7/10/07, Robert Iakobashvili <cor...@gm...> wrote:

> Michael,
>
> On 7/9/07, Robert Iakobashvili <cor...@gm...> wrote:
> >>
> http://www.sqaforums.com/showflat.php?Cat=0&Number=381616&an=0&page=0#Post381616
> >>
> >> People found, that performance of Webload is below 2000 virtual clients
> >> and other numbers being also not so impressive (we have reached 60 000
> >> and are limited mainly by the memory of the available HW).
> >>
> >> We are talking, that 30-35 K for each virtual client is too much,
> whereas
> >> WebLoad is taking an order more.
>
>
> > what about loadrunner (former mercury, now hp) ?
>
> Please, address always to the list:
> cur...@li....
>
> For example, I do not know, but Vlad seems to be in position to
> comment about Mercury LoadRunner numbers.
>
> 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
>


It was long time ago and I don't remember the numbers...

Roughly, LoadRunner performace depends of the choosed protocol and virtual
client complexity.
Since LR is positioned as business process oriented tool, it is usually used
running "GUI level" protocol which builds DOM and runs javascripts. Resulted
performance is relativelylow (hundreds concurrent virtual users for single
machine) but virtual user script is quite simple and easy to maintanace.

HTTP level protocol provides thousands concurrent virtual users on single
load generator machine, but business process implementation become be very
complicated task, providing good job for LR experts.

So, LR is definitely not the best stress testing tool. However, for business
process oriented load testing it is the best that I know. At the same time,
if performance is the issue, LR can use multiple load generator machines.
Usually, users are limited rather by the license than by performance issues.

Thanks,
Vlad.

Re: WebLoad HTTP performance numbers

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

Michael,

On 7/9/07, Robert Iakobashvili <cor...@gm...> wrote:
>>http://www.sqaforums.com/showflat.php?Cat=0&Number=381616&an=0&page=0#Post381616
>>
>> People found, that performance of Webload is below 2000 virtual clients
>> and other numbers being also not so impressive (we have reached 60 000
>> and are limited mainly by the memory of the available HW).
>>
>> We are talking, that 30-35 K for each virtual client is too much, whereas
>> WebLoad is taking an order more.


> what about loadrunner (former mercury, now hp) ?

Please, address always to the list:
cur...@li....

For example, I do not know, but Vlad seems to be in position to
comment about Mercury LoadRunner numbers.

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

WebLoad HTTP performance numbers

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

FYI.

See the link about their performance numbers.

http://www.sqaforums.com/showflat.php?Cat=0&Number=381616&an=0&page=0#Post381616

People found, that performance of Webload is below 2000 virtual clients
and other numbers being also not so impressive (we have reached 60 000
and are limited mainly by the memory of the available HW).

To say the truth - my expectations from WebLoad were much higher.

We are talking, that 30-35 K for each virtual client is too much, whereas
WebLoad is taking an order more.

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

Re: DESTDIR support for curl-loader-0.40

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

On 7/5/07, BuraphaLinux Server <bur...@gm...> wrote:
> Attached is a patch to the Makefile to provide
> normal DESTDIR support so people can do:
> make install DESTDIR=/some/fake/root
> for packaging purposes.

Thanks, John. Applied.

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

DESTDIR support for curl-loader-0.40

[BuraphaLinux S. <bur...@gm...>]

Attached is a patch to the Makefile to provide
normal DESTDIR support so people can do:

make install DESTDIR=/some/fake/root

for packaging purposes.

[ANN] Stable version 0.40 released.

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

This version is a stabilization version, tested with up to 60K clients
from a single curl-loader process.

Besides the bugfixes the version delivers:
- HTTP Multipart Form-Data POST-ing as in RFC1867, initial support;
- client max throughput limit;
- random timers;
- url fetching probability;
- improved documentation, including man pages;

Very many thanks for the people, who helped us
and made this release possible!

-- 
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/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.

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.

[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.

[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: 60K curl-loader connections

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

On Mit 04.07.2007 21:04, Robert Iakobashvili wrote:

[snipp]

Thanks ;-)

BR

Aleks

Re: 60K curl-loader connections

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

On 7/4/07, Aleksandar Lazic <al-...@no...> wrote:

> How much memory is used by curlloader for this 60K?!

60K clients x 25K memory/client (our tuning of libcurl memory)
= 60 000 x 30 000 = 1, 6 GB user space + ~100 M
in kernel on a machine with 2 GB memory

It could be further optimized.

> Due the fact that I'am a little bit curious on which os was curlloader
> run and on which nginx?

Sure, both linux.

> What was the nginx config and what the os network config?!

Standard build on linux gives epoll handling as the default,
increased num of allowed clients to 64K
the directive for allowed descriptor (not not remember the exact
name something rlimit_nofile) increased up to 64K

ulimit -n 100000
+
some tuning from curl-loader page, see our FAQs on the web-site,
enjoy Israel flag.

> >Next target is 100K-200K, whereas we are still very far from Ixia
> >IxLoad with its up to 2 mln users.
> With how many Computers?

Client side - sure , a single one, but maybe more memory, lets see.
Ixia is a single box.
-- 
Sincerely,
Robert Iakobashvili,
coroberti %x40 gmail %x2e com
...........................................................
http://curl-loader.sourceforge.net
A web testing and traffic generation tool.

Re: 60K curl-loader connections

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

Hi,

On Mit 04.07.2007 16:10, Robert Iakobashvili wrote:
>
>60K curl-loader connections worked against nginx server (thanks to
>"Aleksandar Lazic" <al-...@no...> for recommending me this
>server) using ./conf-examples/60K.conf file.

Aeh, WOW congratulation ;-))) and you are welcome.
Why do you have switched to nginx, afai remember you have used lighty
right?

How much memory is used by curlloader for this 60K?!

Due the fact that I'am a little bit curious on which os was curlloader
run and on which nginx?

What was the nginx config and what the os network config?!

>Next target is 100K-200K, whereas we are still very far from Ixia
>IxLoad with its up to 2 mln users.

With how many Computers?

BR

Aleks

60K curl-loader connections

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

Gentlemen,

60K curl-loader connections worked against
nginx server (thanks to "Aleksandar Lazic" <al-...@no...>
for recommending me this server)
using ./conf-examples/60K.conf file.

Next target is 100K-200K, whereas we are still very far from
Ixia IxLoad with its up to 2 mln users.

-- 
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?!
>
> 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.

[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, 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: documentation.

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

On 7/2/07, Michael Moser <mos...@gm...> wrote:
> i have put the documentation files in doc sub directory, you can still see
> them in root directory as symbolic links.
> i copy both man pages and documentation files (see makefile)

Thanks, Michael. Tested it, it works.

Thanks, "BuraphaLinux Server" <bur...@gm...>,
for the man pages.
I need to go thru the pages and correct/update them as well as use them
(correct English source) for web-pages, etc.
Nornally, man pages also include the names of the people, who create them.
Would you mind to appear?

> now i think we have to add a copyright notice into doc sub directory, so it
> will be copied with the other files - so please add something appropriate.

OK, I will add it later. Thanks.


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

Re: PATCH for "Timeouted" --> "Timed out"

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

On 7/1/07, BuraphaLinux Server <bur...@gm...> wrote:
> In English we do not say "timeouted", we say "timed out".
> So when a timeout expires, we say it has timed out.  This
> patch changes this for curl-loader-0.32

Thank you very much. Applied.

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

PATCH for "Timeouted" --> "Timed out"

[BuraphaLinux S. <bur...@gm...>]

In English we do not say "timeouted", we say "timed out".
So when a timeout expires, we say it has timed out.  This
patch changes this for curl-loader-0.32

README patch

[BuraphaLinux S. <bur...@gm...>]

This is a patch for curl-loader-0.32 to fix the name of one of the example
files specified in the README that does not match the real file name.

Re: man page for curl-loader

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

On 7/1/07, BuraphaLinux Server <bur...@gm...> wrote:

> Attached is my first draft at a curl-loader-config.5 man page.

Thank you very much once more! Really appreciating.

Michael, please, integrate it at some your free timeslot.
Thank you.

> There is one part with a big FIXME! section for the
> RESPONSE_STATUS_ERRORS tag since I never was able
> to make that work.  Clearly I don't understand it.

Let's say that some people like HTTP 403 response and consider it OK.
There is no more some previously kept file on their server.

If a virtual client fails on error, it does not continue a cycle by taking
further urls. Instead, the client attempts another cycle by returning to
the first url. When a client get 403 by default it is presented in all
statistics
as an error.

So the people can add +403 and get operational status Success as well
as such clients will continue to the next url.

Please, explain the problem you encounter so that we will try to fix it.
Thank you.


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

Re: man page for curl-loader

[BuraphaLinux S. <bur...@gm...>]

On 6/27/07, Robert Iakobashvili <cor...@gm...> wrote:
> On 6/26/07, BuraphaLinux Server <bur...@gm...> wrote:
> > make curl-loader.1
> > groff -man -Tascii curl-loader.1 | less -ic
> >
> > The most critical part of the man page is that content; the
> > formatting doesn't matter if the content is wrong, and if the
> > content is right people can use the program and they will
> > (normally) forgive any ugly formatting.
> >
> > Is that what you were asking me, or did I just answer the
> > wrong  question?
>
> Exactly, what was required. Michael Moser is currently looking
> into incorporating the man page you provided into our building/making
> infrastructure and its extension.
>
> It's a shame for me for being using UNIX system and C-programming since
> 1982, I have never learn the issues of creating man-pages.
>
> Great and thank you very much!

Attached is my first draft at a curl-loader-config.5 man page.
There is one part with a big FIXME! section for the
RESPONSE_STATUS_ERRORS tag since I never was able
to make that work.  Clearly I don't understand it.  However, all
you need to do is fill in the stuff between the FIXME lines
and remove the FIXME lines and the .br lines next to them
and the page would be ready.  Please check the rest of
it in case I made some factual errors.  My source was the
README file, but it has some typos in it.

Alternatively, tell me what to put in there in an email, and I
can update the man page and send it back again.