Re: frontend proxy really useful?
"CN" == Chris Nokleberg [EMAIL PROTECTED] writes: CN But the guide seems to be saying that the speed of the client isn't CN an issue--the process (proxy _or_ mod_perl) is released as soon as it CN finishes putting the outputted page into the OS socket buffer. I assume CN "released" means it can go and serve another request. Am I reading it CN wrong? But that's exactly *why* the speed of the client is important. If your client is slow, say a 28.8 modem in Sri Lanka, then your httpd is stuck spoon-feeding the client until all data is transferred. Would you rather that spoon-feeding be done by a 30Mb mod_perl server or a 512kb proxy server? Now, multiply the spoon-feeders by 100 and re-evaluate your decision.
Re: frontend proxy really useful?
Hi there, On Sat, 20 May 2000, Chris Nokleberg wrote: I was rereading http://perl.apache.org/guide/scenario.html#Buffering_Feature does it make the light frontend buffering proxy technique useless as long as your pages fit in the socket buffer size (256K on Solaris)? (assuming the proxy is just a dumb passthrough to one backend server) You might think that it serves little purpose for a light Apache server simply to pass all requests from a socket through to a heavy mod_perl server, only then to receive the reply and pass it back to the socket. But you don't usually know what is the other side of the socket, and so you don't know how fast the buffer will be emptied. It might take a couple of minutes if the client is on a slow line. Your processes could all be waiting for the socket buffers to be emptied by slow clients, so there may be no free child to serve an incoming request. In that case Apache will just keep spawning new ones (if it's allowed) for any new incoming requests. You could build up a big heap of waiting processes. You will have far less resources consumed by the waiting processes if they are plain Apache children than you will if they are Apache+mod_perl children. So you will be able to spawn more processes, and so serve more incoming requests. It depends of course on the profiles of your users, the resources requested, etc.etc... You can make measurements, or calculations, or guesses, or you can just wing it. But you don't want to let Apache spawn so many children that you get into swapping, nor do you want to force your clients to wait unnecessarily. 73, Ged.
Re: frontend proxy really useful?
On Sun, 21 May 2000, G.W. Haywood wrote: You might think that it serves little purpose for a light Apache server simply to pass all requests from a socket through to a heavy mod_perl server, only then to receive the reply and pass it back to the socket. But you don't usually know what is the other side of the socket, and so you don't know how fast the buffer will be emptied. It might take a couple of minutes if the client is on a slow line. Your processes could all be waiting for the socket buffers to be emptied by slow clients, so there may be no free child to serve an incoming request. In that case Apache will just keep spawning new ones (if it's allowed) for any new incoming requests. You could build up a big heap of waiting processes. You will have far less resources consumed by the waiting processes if they are plain Apache children than you will if they are Apache+mod_perl children. So you will be able to spawn more processes, and so serve more incoming requests. But the guide seems to be saying that the speed of the client isn't an issue--the process (proxy _or_ mod_perl) is released as soon as it finishes putting the outputted page into the OS socket buffer. I assume "released" means it can go and serve another request. Am I reading it wrong? "Therefore if you don't use mod_proxy and mod_perl send its data directly to the client, and you have a big socket buffer, the mod_perl process will be released as soon as the last chunk of data will enter the buffer. Just like with mod_proxy, OS will worry to complete the data transfer." Chris
Re: frontend proxy really useful?
Hi again, On Sun, 21 May 2000, Chris Nokleberg wrote: On Sun, 21 May 2000, G.W. Haywood wrote: It might take a couple of minutes if the client is on a slow line. But the guide seems to be saying that the speed of the client isn't an issue--the process (proxy _or_ mod_perl) is released as soon as it finishes putting the outputted page into the OS socket buffer. I assume "released" means it can go and serve another request. Am I reading it wrong? No. But what happens if the socket is still full of data from the previous request when the child attached to that socket gets another request for another socket-buffer-full? That's when you run into the problem. 73, Ged.
frontend proxy really useful?
I was rereading http://perl.apache.org/guide/scenario.html#Buffering_Feature and was surprised to find: "Therefore if you don't use mod_proxy and mod_perl send its data directly to the client, and you have a big socket buffer, the mod_perl process will be released as soon as the last chunk of data will enter the buffer. Just like with mod_proxy, OS will worry to complete the data transfer." Is there any new information on whether this is the case? If it is, does it make the light frontend buffering proxy technique useless as long as your pages fit in the socket buffer size (256K on Solaris)? (assuming the proxy is just a dumb passthrough to one backend server) Thanks, Chris
