Re: Performance analysis questions
Rick Troth <troth@rice.edu>
Errors-To: listmaster@www0.cern.ch
Date: Fri, 13 May 1994 15:18:23 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <Pine.3.89.9405130741.A12231-0100000@brazos.is.rice.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: troth@rice.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Rick Troth <troth@rice.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Performance analysis questions
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Type: TEXT/PLAIN; charset=US-ASCII
Mime-Version: 1.0
Mime-Version: 1.0
On Thu, 12 May 1994, George Phillips wrote:
> Andrew Payne said:
> > ... Code like this doesn't help (getline() in util.c):
> >
> > if((ret = read(f,&s[i],1)) <= 0) {
> >
> >Your mileage may vary.
[YMMV]
>
> Whilst looking through the httpd code, I noticed this too. ...
>
> 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. However, a quick hack could double the speed by doing
> read(f, &s[i], 2) because you know that at least CR LF will terminate
> the line.
For something totally unrelated, I wrote my own getline().
Trying to adhere to the "be liberal about what you accept and
conservative about what you generate" rule, it doesn't care
whether or not there's actually a CR, just the LF, and returns the
length of the string LESS the line terminator(s), or < 0 on error.
I think mine is at least as bad as Rob's above.
The intent was to replace it (someday) and not have a if/while
based on characters embedded in the server proper.
> If it's the header boundary that's a problem, you could
> quadruple the speed with read(f, &s[i], 4) since you have at least
> "GET " for HTTP/0.9 requests and HTTP/1.0 headers will terminate
> with CR LF CR LF (well, they better!).
>
> -- George
Argh! This is bad. Not picking on you, George,
but you've presumed on something that a *lot* of people seem to
presume on. It should be
CR LF [any amount of white space] CR LF
There are contemporary systems that CAN NOT generate a
completely empty line in places. This is a problem for certain
mail user agents which don't see the header termination because
the blank line isn't an "empty line" (cr/lf/cr/lf). Let the blank
line be just blank to the eyes, not necessarily "empty".
Try this:
o a line of text is NUL terminated
(assuming you're coding C on UNIX) [YMMV]
o when sending "on the wire" append CR & LF
o when receiving, accept either NL (LF)
or CR LF for end-of-line
o when processing, ignore trailing white space
Thoughts?
--
Rick Troth <troth@rice.edu>, Rice University, Information Systems