tclwebtest-general

[tclwebtest] Non blocking http requests

[Grzegorz A. H. <gr...@ef...>]

Hi.

Once I have tclwebtest running inside my server I get the urge
to run several tests concurrently, but looks like geturl is the
bottleneck, and while one test case is blocked querying some slow
external server, another test case which runs against the local
server doesn't progress.  Can this be solved with the callback
feature of geturl?

-- 
 Grzegorz Adam Hankiewicz, gr...@ef.... Tel: +34-94-472 35 89.
 eFaber SL, Maria Diaz de Haro, 68, 2         http://www.efaber.net/
 48920 Portugalete, Bizkaia (SPAIN)

Re: [tclwebtest] Non blocking http requests

[Tilmann S. <ti...@ti...>]

* Grzegorz Adam Hankiewicz <gr...@ef...> [20030304 16:06]:
> Once I have tclwebtest running inside my server I get the urge
> to run several tests concurrently, but looks like geturl is the
> bottleneck, and while one test case is blocked querying some slow
> external server, another test case which runs against the local
> server doesn't progress.  Can this be solved with the callback
> feature of geturl?

When running outside the webserver you can use the -processes switch
to make tclwebtest fork into several processes that run in
parallel. Within the webserver you might have to invent your own way
of making use of its multithreading capabilities. 

I don't know how callback would help in this case as that would mean
that you want the same instantiation of tclwebtest (e.g. a set of
initialised global variables etc.) to do several requests in parallel,
right? So when the callback fires tclwebtest should know which
currently running set of global variables to associate that with -
this is totally impossible with the current architecture.


til

-- 
http://tsinger.com

Re: [tclwebtest] Non blocking http requests

[Grzegorz A. H. <gr...@ef...>]

On Wed, Mar 05, 2003 at 05:30:54AM +0000, Tilmann Singer wrote:
> I don't know how callback would help in this case as that would
> mean that you want the same instantiation of tclwebtest (e.g. a
> set of initialised global variables etc.) to do several requests in
> parallel, right? So when the callback fires tclwebtest should know
> which currently running set of global variables to associate that
> with - this is totally impossible with the current architecture.

At the moment I'm not doing anything special to create two instances
of tclwebtest, the server seems intelligent enough to create two
separate threads each with it's set of variables, which might happen
because at the moment I reload the complete tclwebtest script for
each run or because aolserver by default creates a separate memory
space for each thread (a logical behaviour after all: if two users
request the same dynamic page, the requests shouldn't share the
same memory space). It looks like the problem is opening an http
connection, it seems to freeze the whole server. My boss said that's
because the geturl command might open the socket in blocking mode,
and this could block the whole process.

I verified this launching two test units concurrently, one against
the local server and another one against a slow external one. Then
I tried to connect with a browser to the local server (which runs
tclwebtest inside aolserver), and the request was frozen: after
several seconds the html code appeared, some more later one image,
and so on for the rest of the images. From my limited point of view
this means that the unit tests are waiting for the external query
to finish, and meanwhile other threads of the server are unable to
progress. The slow one by one appearing of images suggests that after
each geturl command the other threads get a little CPU time only
to get blocked again by the next scheduled blocking geturl command.

My supposition was that running geturl with the callback option
would open the socket in non-blocking mode, and thus the rest of
the threads wouldn't be blocked, I would separate do_request in
two parts and simulate the sequencial behaviour. Therefore each
tclwebtest instance would still be able to run along others and
open any number of separate sockets.

It's not a requested feature yet, I was just asking. If I have to
solve this problem in the future I will try this callback approach
first and get back to you with the results.

-- 
 Grzegorz Adam Hankiewicz, gr...@ef.... Tel: +34-94-472 35 89.
 eFaber SL, Maria Diaz de Haro, 68, 2         http://www.efaber.net/
 48920 Portugalete, Bizkaia (SPAIN)

Re: [tclwebtest] Non blocking http requests

[Tilmann S. <ti...@ti...>]

Hmm, this sounds like very much being the symptom of geturl not being
_threadsafe_ - I never understood what that actually means, but this
problem gives me some idea on it. You could make it sure by not
testing against a slow and a fast server, but against your a socket
that you opened on your own and thus know that it will never been
answered until you hit Ctrl-D:

$ socket -s 9000

...

do_request "http://localhost:9000"



til

Re: [tclwebtest] Non blocking http requests

[Grzegorz A. H. <gr...@ef...>]

On Wed, Mar 05, 2003 at 07:05:06PM +0000, Tilmann Singer wrote:
> Hmm, this sounds like very much being the symptom of geturl not
> being _threadsafe_ - I never understood what that actually means,
> but this problem gives me some idea on it. You could make it sure
> by not testing against a slow and a fast server, but against your
> a socket that you opened on your own and thus know that it will
> never been answered until you hit Ctrl-D:

Yes, the first do_request is blocked, but other http requests
are satisfied. When the second do_request is blocked, no other
http requests progress: aolserver is frozen. At the very same
time Ctrl-D is pressed, all the pending requests are processed.
Now the question is if using the callback version of geturl would
prevent the blocking.

-- 
 Grzegorz Adam Hankiewicz, gr...@ef.... Tel: +34-94-472 35 89.
 eFaber SL, Maria Diaz de Haro, 68, 2         http://www.efaber.net/
 48920 Portugalete, Bizkaia (SPAIN)

Re: [tclwebtest] Non blocking http requests

[Grzegorz A. H. <gr...@ef...>]

On Wed, Mar 05, 2003 at 04:10:55PM +0100, Grzegorz Adam Hankiewicz wrote:
> It's not a requested feature yet, I was just asking. If I have to
> solve this problem in the future I will try this callback approach
> first and get back to you with the results.

Attached is my attempt to make this working, but everything
fails: the callback command is simply ignored and vwait fails
always. However, if I run the attached shell script it all works
ok. What's happening?

-- 
 Grzegorz Adam Hankiewicz, gr...@ef.... Tel: +34-94-472 35 89.
 eFaber SL, Maria Diaz de Haro, 68, 2         http://www.efaber.net/
 48920 Portugalete, Bizkaia (SPAIN)