[medusa] implications of asyncore.loop() timeout change

[Sam Rushing]

Ray Price writes:
> I've got a Linux Medusa server returning http pages via a Solaris 
> Apache script (written in python to act as a proxy). For some reason 
> the client does not see the complete page for 15-30 seconds.

I'm not sure I understand the setup. The Apache server is not really
involved, is it? It is generating pages with anchors pointing at the
other server (on a different port or machine?).

Are you calling 'request.done()' when finished generating the page?
Sounds like there's a delay in closing the connection?

> So, I went in and changed the asyncore.loop() timeout value from 30.0 
> to 0.5 and now pages are returned very quickly. 

The timeout value represents how long (max) the select() loop will
wait for anything to happen. If nothing happens, then the server will
sit idle (not consuming CPU) until the timeout expires.

> The question is: what implications should I beware of when changing 
> the timeout value in this way. FYI the asyncore module is shared 
> between several other servers running XML-RPC and mxODBC.

 by lowering the timeout, you create more busy-work for the server. It
has to run through all the objects every 1/2 second rather than
whenever there's activity. If your server is really busy (events come
in at an average of 1/2 second anyway), then there won't be much of an
impact.

> Before I made the timeout change, a client requesting a page directly 
> from the Medusa server would 'free the stuck' page back to the proxy.

Yes, because the activity on the server socket would 'wake up' the
select() call. Sounds like something's getting 'stuck'. If you can,
send me the code that generates the stuck page.

-Sam