htt-users

[Htt-users] Load test and benchmarking

[Dossy S. <do...@pa...>]

Hi,

I just discovered httest today, and like what I see so far.  Simple
concurrency primitives, simple syntax, compiled executable: all huge
plusses.

The FINALLY block is useful.  Could an INIT block be similarly defined
that gets executed at the start?

It appears that variables are not thread-shared.  There's PROC:LOCK and
PROC:UNLOCK, but no IPC mechanism to pass data between threads.  That's
unfortunate.

I'm looking to use httest for benchmarking and load testing.  At the
minimum, having an INIT block implemented would be helpful for executing
stuff before testing starts (set up test, etc.).

What's the development process like for httest?  Is there a patch
submission process?

Thanks for all the great work,

Dossy

-- 
Dossy Shiobara         |      "He realized the fastest way to change
do...@pa...     |   is to laugh at your own folly -- then you
http://panoptic.com/   |   can let go and quickly move on." (p. 70) 
  * WordPress * jQuery * MySQL * Security * Business Continuity *

Re: [Htt-users] Load test and benchmarking

[Christian L. <li...@gm...>]

Hi Dossy

Thanks very much. No currently there is no defined process for httest 
development. If you have a usefull patch feel free to send me that. The 
module concept in httest makes it relativly easy to add new 
functionality blocks :)

I currently up work the syntax and make it more flexible, would be 
httest 3.x. But I do not have plans when to launch it and how to 
read/migrate old scripts.

I think many stuff you want have is allready there:

* shared variables

GLOBAL yourVar yourVar2
GLOBAL yourVar3

CLIENT
_SET yourVar=foo
END

CLIENT
_SLEEP 1000
_DEBUG $yourVar
END

* Init blocks could be done this way

CLIENT
# do what ever you need to start with your tests
END

GO

#now start your tests
CLIENT
...
END

* Performance Tests:
I think httest is not the fastest on the market, needs a lot CPU power :(

But with the
     PERF:DISTRIBUTED <host>:<port>
     PERF:RAMPUP <clients> per <interval>

you could even distribute and ramup your clients (Rampup even works 
distributed). But it is a little quricky this distributed thing. Please 
have a look into the test folder within the tar ball. You will find 
there many examples how a command could be use, just grep the command ;)

I hope that helps.

Best regards
Christian


On 11/13/12 05:37, Dossy Shiobara wrote:
> Hi,
>
> I just discovered httest today, and like what I see so far.  Simple
> concurrency primitives, simple syntax, compiled executable: all huge
> plusses.
>
> The FINALLY block is useful.  Could an INIT block be similarly defined
> that gets executed at the start?
>
> It appears that variables are not thread-shared.  There's PROC:LOCK and
> PROC:UNLOCK, but no IPC mechanism to pass data between threads.  That's
> unfortunate.
>
> I'm looking to use httest for benchmarking and load testing.  At the
> minimum, having an INIT block implemented would be helpful for executing
> stuff before testing starts (set up test, etc.).
>
> What's the development process like for httest?  Is there a patch
> submission process?
>
> Thanks for all the great work,
>
> Dossy
>

Re: [Htt-users] Load test and benchmarking

[Dossy S. <do...@pa...>]

On 11/13/12 2:41 AM, Christian Liesch wrote:
> Thanks very much. No currently there is no defined process for httest 
> development. If you have a usefull patch feel free to send me that. The 
> module concept in httest makes it relativly easy to add new 
> functionality blocks :)

Excellent.  I'll take a look into it.  I'll also probably look at
integrating Tcl which should be fairly easy if Lua's already supported.


> I think many stuff you want have is allready there:
>
> * shared variables
> ...
> * Init blocks could be done this way

The variables are shared across threads?  Perfect.

In the user-guide.pdf for 2.2.11, I don't see mention of the "GLOBAL"
keyword.  Is that only in the dev 3.x code, or is that in 2.2.11 and not
documented in the user guide?

Using a CLIENT/GO combo to implement the init block is a clever idea. 
I'll give that a try.

I'm not sure if I'm interpreting the behavior correctly, but in a script
that contains both a CLIENT and DAEMON block, it seems like the FINALLY
block is being executed when the DAEMON block terminates, even though
the CLIENT block is still executing?  I was under the impression that
the FINALLY block should only evaluate when _all_ CLIENT/SERVER/DAEMON
blocks terminate?

I suppose I should start reading the test suite and the source and not
solely rely on the user-guide (which is fantastic, by the way).  Thanks
for the tips!

-- 
Dossy Shiobara         |      "He realized the fastest way to change
do...@pa...     |   is to laugh at your own folly -- then you
http://panoptic.com/   |   can let go and quickly move on." (p. 70) 
  * WordPress * jQuery * MySQL * Security * Business Continuity *

Re: [Htt-users] Load test and benchmarking

[Christian L. <li...@gm...>]

On 11/13/2012 04:33 PM, Dossy Shiobara wrote:
> On 11/13/12 2:41 AM, Christian Liesch wrote:
>> Thanks very much. No currently there is no defined process for httest
>> development. If you have a usefull patch feel free to send me that. The
>> module concept in httest makes it relativly easy to add new
>> functionality blocks :)
> Excellent.  I'll take a look into it.  I'll also probably look at
> integrating Tcl which should be fairly easy if Lua's already supported.

I'm lookin forward for a tcl_module.c ;) But it was not that easy to 
integrate lua into httest and it is, in my opinion, not very well done. 
But perhaps you get a clue if you look into lua_module.c and 
configure.in. I think loading Modules at runtime would be nice to enable 
even user specific modules.

But attention httest 3 do break with many "old" things...

>
>> I think many stuff you want have is allready there:
>>
>> * shared variables
>> ...
>> * Init blocks could be done this way
> The variables are shared across threads?  Perfect.

Yes.

>
> In the user-guide.pdf for 2.2.11, I don't see mention of the "GLOBAL"
> keyword.  Is that only in the dev 3.x code, or is that in 2.2.11 and not
> documented in the user guide?

Hmmm yes I forgot that, I'm a lazy document writer :(

> Using a CLIENT/GO combo to implement the init block is a clever idea.
> I'll give that a try.

GO is an old command designed for a shell mode I abuse for joining all 
CLIENT/SERVER not DAEMON.

> I'm not sure if I'm interpreting the behavior correctly, but in a script
> that contains both a CLIENT and DAEMON block, it seems like the FINALLY
> block is being executed when the DAEMON block terminates, even though
> the CLIENT block is still executing?  I was under the impression that
> the FINALLY block should only evaluate when _all_ CLIENT/SERVER/DAEMON
> blocks terminate?

Not good if that is realy true, I have to test this and fix this. The 
finally should be called after all CLIENT/SERVER are terminated, no 
mather if there is DAEMON still running.

A DAEMON is a independant thread, which could for example be used to 
limit a test duration. For example

DAEMON
_SLEEP 60000
_DEBUG test duration too long
_EXIT FAILED
END

But if there is no _EXIT the httest do run as long as there is a 
CLIENT/SERVER running...

> I suppose I should start reading the test suite and the source and not
> solely rely on the user-guide (which is fantastic, by the way).  Thanks
> for the tips!
>

Welcome