Re: [ANN] - curl-loader virtual scripting in SVN

[Michael M. <mos...@gm...>]

additional clarification regarding garbage collection: Lua uses mark and
sweep garbage collection, so when the heap fills up then everybody has to
wait until garbage is reclaimed; so nobody knows when and for how long these
wait cycles will happen.

2008/4/30 Michael Moser <mos...@gm...>:

> Hi,
>
> I have looked into LUA, now lets try to reconstruct the reasoning (any
> corrections/suggestions are welcome).
>
> Our problem here is that we need several thousand simulated clients in one
> process;
>
> This poses the following question
> 1) do we have one virtual machine for each simulated  client, i.e. a
> scripting language thread per client.
> 2) doe we have one virtual machine for all simulated clients.
>
> We will come back to that question later.
>
> Now lets look at the basic problem that we are facing with integrating any
> language environment with server that is processing requests asynchronously
> - xmethod calls (ie. calls to external methods written in C) usually these
> calls are blocking.
>
> [ the script would need at least one xmethod call that would perform the
> next http request that would 1) initiate the http request, 2) suspend
> execution of the vm for the current thread 3) be able to resume current
> thread when needed]
>
> now this problem can be solved by longjumps (or any other coprocedure
> mechanism) at the expense of  some memory to hold the current stack when we
> suspend current xmethod. Now
>
> basically this kills the option  of using one vm for all simulated
> clients.
>
> Ok, lets assume we are using longjump, this rules our sharing one vm for
> all simulated clients,
> How? lua is singlethreaded and with longjump we just suspended the current
> thread that is running the vm, [also any pending lock will block the whole
> VM if we branch out of it.]
>
> Ok, now we have one VM per simulated client. Great, with LUA they have a
> garbage collected heap, and holding such a heap per each simulated client is
> a very large overhead.
> (even if we could share one vm for all simulated clients then this garbage
> collection schema is a real killer for predictable and reasonable
> performance)
>
>
> Our requirements is therefore
> - vm supports xmethod calls that are truly asynchronous,  without  need
> for longjumps.
> - VM with very low footprint
> - memory management for objects created by the script that is reference
> counted;
> - also when a VM exits it has to take its memory with it.
>
>
> 2008/4/30 Aleksandar Lazic <al-...@no...>:
>
> Hi,
> >
> > On Fre 30.11.2007 10:41, Robert Iakobashvili wrote:
> >
> > > Gentlemen,
> > >
> > > Michael Moser has checked-in a new system for HTTP/FTP response body
> > > analyses, which have WebLoad and JMeter tools.
> > >
> > > Normally, body analyses in testing tools is done using JavaScript or
> > > any other script, which occupies a total thread, is blocking and is
> > > bad
> > > for performance.
> > >
> > > Since curl-loader is about performance (written in C, using C-written
> > > stacks of libcurl and openssl) Michael is developing a new scripting
> > > language, where the script will be:
> > >
> >
> > yust for my curiosity, have you looked into neko, lua or some other
> > 'smalll and embadabble' language and found some nogos?!
> >
> > Cheers
> >
> > Aleks
> >
>
>