httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: updated status for 1.2b7
Date Sun, 16 Feb 1997 07:37:43 GMT
On Sun, 16 Feb 1997, Rob Hartill wrote:

> On Sat, 15 Feb 1997, Marc Slemko wrote:
> 
> > Agenda for 1.2b7-dev
> > ====================
> > 
> >   * mod_include is slow.  Marc posted an output buffering patch
> >     that shouldn't help but does.
> 
> I've been running this on SSI active servers without any problems.
> A quick test I did when I first tried it suggested a 25% better
> performance on a large file (100k) HTML file with 1 "include virtual"
> in it.
> 
> It's a feature :-)

So are the whole whack of other performance improvement things added over
the past few weeks.  This really originated along with all the others, it
just didn't get added at that point.  It isn't really a new patch as such;
I wouldn't write it now and say include it.

If anyone does do more than be tempted to -1 it, I will probably say just
put it in contrib, but I do think it would be worthwhile for 1.2.

> I've nothing against the patch, but I'm tempted to -1 it as incentive
> for someone to draw a line in the sand and say "bug fixes only after
> this date". Marc, you're wearing the release manager hat these days,
> can you please set some deadlines. We could be here forever otherwise.
> 
> What I'd suggest is we make b7 this week, release it and if it looks
> okay after 2 weeks, rename it to 1.2. If anything breaks, roll b8
> a week later and repeat.

There is still the lingering_close issue.  There are two parts:

	- it kills servers.  This is the same one that has been
	  hanging around for the past few months and has not been
	  fixed.  FIN_WAIT_2.
	- it slows down performance.  This can possibly be worked
	  around with Dean's suggestion and should have been
	  improved by Roy's patch lowering the timeout.  I will
	  look at implementing Dean's solution tomorrow.  If
	  I think I can do it without too many changes, I will.

I am not convinced that we will find the solution to connections
building up in FIN_WAIT_2 before 1.2.  Tenative proposal:

	- either ship 1.2 with NO_LINGCLOSE for platforms that
	  don't have a timeout or put a very big note saying
	  "IF YOU ARE RUNNING {XXX,XXX,...} YOU SHOULD DO THIS".
	  I perfer not adding it but making people do it themself
	  because then they are aware of it.  Current platforms
	  I can think of that need NO_LINGCLOSE are UnixWare 
	  (I think there is some patch for it, but don't know
	  for sure...), SunOS (not likely a patch will come out),
	  and IRIX (for now, until they release their patch).

	- If we do figure out what is going on in lingering_close
	  after 1.2, release 1.2.1 as a fix.  I am willing to bet
	  we will need something after 1.2 for bugfix anyway.

Tenative date of Wed. for 1.2b7?  

The only possibly large thing I expect between now and then is possibly
implementing Dean's lingering_close suggestion if practical.  Oh, I guess
there is that HUP thing too.  <sigh>

We should decide now if we will mandate absolutely 0 source changes
between the last beta and 1.2 or if "small changes to fix things
that are unlikely to break things" are allowed.

> 
> 
> >   * if "options IncludesNOEXEC" set in directory, no CGI will work
> >     Message-Id: <199702102302.PAA11416@taz.hyperreal.com>
> 
> Isn't that what's supposed to happen ? I though that's how it used
> to be documented.

Yes, that is how it is documented and I guess we can't change that
now.  But consider that the only thing most admins care about
when using IncludesNOEXEC is that people can't execute arbitrary
programs.  That is what I care about, but I don't care less if someone
executes something which is already directly executable as a CGI
from inside a SSI.



Mime
View raw message