Re: Performance analysis questions

• Mail folder: WWW Talk Apr 94-present
• Next message: Yechezkal-Shimon Gutfreund: "Re: file i/o api for URL"
• Previous message: Chris Lilley, Computer Graphics Unit: "Re: Image types and related issues [was: Re: filetype extensions]"
• Maybe in reply to: Rick Troth: "Re: Performance analysis questions "
• Reply: George Phillips: "Re: Performance analysis questions "

Errors-To: listmaster@www0.cern.ch
Date: Sun, 15 May 1994 04:48:11 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <199405131402.KAA11545@n8kei.tiac.net>
Errors-To: listmaster@www0.cern.ch
Reply-To: payne@n8kei.tiac.net
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Andrew Payne <payne@n8kei.tiac.net>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Performance analysis questions 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas

George writes:

>>Code like this doesn't help (getline() in util.c):
>>
>>           if((ret = read(f,&s[i],1)) <= 0) {
>
>This is done because it wants to hand off the file descriptor to
>CGI scripts that handle POSTs.  I'd suggest the right way to fix
>things is to read a bufferful and cat the extra to the scripts that
>need it.  

If the common case is GETs (which I suspect it is for most servers), doing 
buffered reads and just copying the bytes down to the POST script is 
probably the right thing do to.  Plus, POST data _tends_ to be short 
anyway.

Actually, you can get the best of both methods.  Read the first 4 bytes of 
the connection.  If the method is POST, read the rest of the connection 
unbuffered and hand the socket off to the script.  Otherwise, do large 
block reads and buffer all you'd like.  If you seek the ultimate in 
performance, the extra code might be worth it.

Make the common case fast,

-andy