httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@worldgate.com>
Subject Re: non-buffered CGIs suck
Date Fri, 06 Mar 1998 05:21:39 GMT
On Thu, 5 Mar 1998, Dean Gaudet wrote:

> 
> 
> On Thu, 5 Mar 1998, Marc Slemko wrote:
> 
> > I'm not sure I follow.  If they don't get buffered, where is the problem?
> 
> Ah ok, I've patched in your patch and it makes more sense in the full
> context.  I thought the write was hiding somewhere behind your new select
> and so all writes would be 100ms delayed.  Sorry.  +1 on the patch. 

Note that the patch is not acceptable as is, because it doesn't allow for
unbuffered CGIs anymore.  I am not concerned about a 100ms delay, although
actually perhaps I should be.  Darn.  Yes, that sucks.  

eg.

#include <unistd.h>
#include <stdio.h>

int main () {
        int i = 0;
        printf("Content-type: text/plain\n\n");
        fflush(stdout);
        while (i++ < 100000) {
                char *s;
                sprintf(s, "%d\n", time(NULL));
                write(STDOUT_FILENO, s, strlen(s));
                usleep(50000);
        }
}

Will not output until it fills a buffer.

In any case, as I was saying what I am more concerned about is that there
really should be some total time limit on how long a script can go before
it gets flushed; that doesn't fix this case unless that limit is quite low
(actually, it could be).  If the OS modified tv to indicate time left it
is easy, but otherwise there is no nice way to do that. 

(yea, it doesn't make sense to print a clock without millisecond
resolution more than once a second, but...)

I'm not sure what to do about this.  

Given:

1. Gathering small writes is good.  We either leave Nagle on, or do it
ourself.

2. Pseudo-unbuffered CGIs are good.

I'm not sure of the solution.  Perhaps some way for a CGI script to
disable this sort of delay?  eg. send a particular header?  The vast
majority of CGIs will be fine with my suggested change.  It is reasonable
to ask those that aren't to do something about it to avoid it.  It could
be disabled for nph- scripts (lame hack) and with defining a header to be
sent by the CGI to indicate it wants all buffering removed as far as
possible (actually a pretty good way; would be nice if it were standard). 

> 
> Note, I'm not sure about freebsd, but I do know that on Linux, a context
> switch doesn't occur on each write to a pipe.  The pipe is allowed to fill
> up.  So there's buffering in the kernel too.  I'm assuming this is why you
> stuck in the usleep(1).  I think that's actually an inaccurate portrayal
> of even unbuffered CGIs. 

Yes.  It was just there to force a context switch.

It is an inaccurate representation of unbuffered CGIs sending static
content, but I would suggest it may be very accurate for a CGI sending
short bits of information that each require a disk read, etc.  A well
designed app won't do that because of buffering on reading that input
data. I'm not worried about well designed apps though, since they will
watch their output too.

> 
> > Things are fine from the packet size perspective if you reenable Nagle,
> > but it may cause performance problems in some cases.  The original reason
> > for disabling it was due to the fact that we sent the headers in a
> > separate segment.  
> > 
> > We should only run into trouble with Nagle if we have two short segments
> > in a row.  Before, that could be the end of one response body and the
> > headers of the next response.  Now we don't flush after the headers are
> > sent, so that (common) case doesn't happen.  It could happen with just the
> > right sequence of cache validation stuff; not when we have a whole bunch
> > of requests pipelined at once, but when a new one comes in after we sent
> > the last segment of the previous response but before we have the ACK back
> > for it.  I am planning on looking to see if it is possible to enable Nagle
> > without causing problems.  Nagle is a lot smarter than Apache can be about
> > this because of the layer it is at.  I am also looking to see how many
> > systems have the sucky segment size problem; I am told that most don't,
> > and I don't even see it with all FreeBSD systems.  Not sure why yet. 
> 
> Leaving nagle on would mean 1 less syscall per connection.  You can bet
> I'd support that ;)

Hehe.  


Mime
View raw message