Hi,
I had to deal in a similar situation, Since the process that I wanted to
talk was on the same machine, I ended up using UDP sockets ( the other
process already spoke UDP), I was blocking on the select for a couple of
milliseconds, and this did not affect performance much ( 30 millisecs on
the select blocking Vs 2 seconds for the HTML to be actually rendered on
the browser).
In my case the response was smaller than the default UDP packet size (1 K).
If your response from the server is fragmented, this may not be optimal,
you may have to increase the deafult UDP packet size or deal with packet
re-assembly.
hope this helps.
naren
At 10:47 AM 5/24/00 +0100, Reilly, Thomas wrote:
>Hi,
> I'm new to all this and forgive me if my questions are basic
>My question is how scaleable is Apache in terms of performance when i use
>IPC from a mod_perl script? I basically want to have the Apache child
>process handling the request to communicate with another process (using
>mod_perl) and wait to get a response before continuing handling the request.
>I know this isn't recommended but i have to talk to legacy code and retrieve
>some data to send back to the client that made the request.
> What is the best form of IPC to use and what are the implications on
>Apaches performance? i.e is it ok to have the child handling the response
>sit there waiting for its child to return something? Is this dangerous when
>multiple requests are involved?
>
>Thomas Reilly
>Software Consultant,
>
>Distributed Software Consultancy Ltd.,
>Ballybrit Business Park,Galway,Ireland.
>Tel: +353 (91) 760541 Fax: +353 (91) 760542
>e-mail: [EMAIL PROTECTED]
>web: http://www.dscie.com
>
>
>
