httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brandon Long <>
Subject Re: Issues for a beta release... (NCSA PLEASE READ)
Date Wed, 12 Apr 1995 03:54:10 GMT
Last time, Brian Behlendorf uttered the following other thing:
> On Tue, 11 Apr 1995, Robert S. Thau wrote:
> >    Our options, as I see them ---
> > 
> >    a) release a non-forking thing now, with promise of a forking
> >       server to come "soon after NCSA releases 1.4".
> > 
> >    b) wait until NCSA releases 1.4, and then release our code
> I would vote for a non-forking beta release, and then when we've got the 
> no-forking mechanism down pat (tested on a wide variety of platforms, 
> recoded to do a MP accept() model instead of serializing them, etc) 
> release that.

I'd love to borrow that, if you get it working.  It wasn't until after I'd
implemented the other that I thought about forking before the accept (I
just assumed it couldn't be done, show's what I know.)  I was thinking of 
trying something like have 5 servers with 5 children each, and wonder how that
would handle things, but I also hadn't considered the scheduling problem.
All I know is that the main problem I have with Netsite users is if the
number of servers is set too low, you get a very intolerable delay before you
get ANY response from the server at all.  (I'm also assuming this can be fixed
by setting the number of servers higher).

Our webmaster (of www.ncsa) did some performance monitoring of 1.4 and 
thought that the new approach didn't help that much, but I've noticed 
it helps quite a bit on certain platforms, and may be more due to not the
speed at which they handle transactions but the fact they can handle the 
transactions (a HP 715/50 at 15 transactions/second with 20 servers has
an uptime of .5 to 1.5, but is missing very few transactions, where as 
with fewer servers, or none at all, the uptime skyrockets to 11 or so, and
it misses most of the transactions)

Sorry, I guess I'm trying to prove that it helps, at least as well as I can
tell.  I'd also hate to see netsite on hoohoo, where we have this annoying
script that does an archie, and holds up a server until its done.  Of course,
I don't know enough about the netsite model, they might just let the scripts
go (sorta like nph scripts) instead of hanging a server on it (yes, we know
the script should be nph, but it helped find a deficiency in 1.4, so we left

> >    Personally, I wouldn't feel comfortable releasing the forking code
> >    yet --- for one thing, it would feel odd to be releasing 1.4 code
> >    to the general public before they do (although it would be labeled
> >    beta in both cases).  However, it's possible that reasonable people
> >    will disagree.

I hope to release the 1.4 (either general beta or for real) next week, but
I have this little thing called class (oh, and Easter too).  If I can find
the problem that Rob had with 58 reloads killing the server, it should be

> This is an intersting situation, and I hope someone from NCSA can respond 
> (hence my change to the subject line).  Since our licenses are still very 
> similar, I think they have as much right to use *our* code as we do 
> *their*s, so I can't see how they would see this situation as anything 
> but collaborative.  My opinion is that we shouldn't release anything with 
> the non-forking code until at least we hear back from them, but this is 
> based more on professional courtesy than any legal reason (NB: I'm not a 
> lawyer, etc etc...) (BTW, what does NB stand for?)

You're welcome to do what you will.  I have no problem if you beat us to the
punch, after all, we didn't do anything for how many months?  I think I've
mentioned before that give it a couple more months, and I expect Apache
to take over the position of httpd (except maybe for those who need free
support/hand holding which I'm sure you all don't wish to provide)
> > 2) Compatibility.  Current versions (i.e., the *most* recent betas) of
> >    1.4 have the following features which we *don't* support, or do
> >    differently.  Our current draft public docs page says we expect to
> >    be plug-compatible with 1.4, so we have to deal with the following
> >    somehow: 
> >   
> >    a) Some of the script variables we now both set on error redirects
> >       have different names (ERROR_foo vs. REDIRECT_foo --- we have the
> >       latter names because we set them as well when a script redirects
> >       to another local script).
> This local redirecting is still done through custom error messages 
> though, yes?  So "ERROR_" might not be a bad name.  I didn't realise when 
> I voted in favor of "REDIRECT_" that 1.4 had chosen the other way.... I 
> think semantically the first is more correct.

We can very easily (er, I think) add these variables to local redirects as 
well.  Right now, I just did it the easy way (I copy them in die, before
the error message is called) but I could do it in process request, and 
the just set a flag to actually send them to the script.
> >    b) RefererLog, UserAgentLog --- I don't think these are a terribly
> >       good idea, but if we really want to be plug compatible with 1.4,
> >       we're stuck with them.
> Not hard to implement though.  Compile-time option that's always set by 
> default?

We need CLF II, obviously.  These logs are only of minimal use, as is.  I find
it kind of interesting to view the referer log, but the UserAgentLog is next
to useless (unless you care which browser is "winning").  With the addition
of the referer information to the error_log on access denied, its about all
that's needed for most people.
> >    c) There's (experimental?) support for group annotation of some
> >       sort --- so far, it seems to consist only of having an
> >       annotation server named in the config files, and jamming its URL
> >       into the MIME headers on returned documents.  We may not even
> >       want to support this until it's documented and stabilized, but
> >       it's there.
> This, and b), could be labeled as "experimental" if we wished and not 
> supported.  While we *must* be compatible with 1.3 (if for any other 
> reason so people can still use as documentation for 
> apache) I don't necessarily agree that we must be compatible with 1.4.  
> 1.4 is much more a departure from its antecedent than 1.3 or even 1.2 
> was, so a lot of its "features" may get revamped in short order....

Basically, this was added now for the conference in Germany, but my feeling
is that its probably changed from the last version.  I believe there now
exists a annotation server of some sort, but I'm not really up-to-date on
the whole thing (one of the other developers is handling that)

As for the next version, I think it will be a security release, with
support (hopefully) for digest authentication, maybe kerberos (they're still
working out the whole mess of export), maybe some other stuff (there isn't
an SSL server library, but that's another can of worms entirely)

> > 3) I really would like the APB code in our first public release.
> >    (NB this may involve nontrivial coding --- most of my code looks
> >    pretty much like, well, Apache, but httpd.c is taken more or less
> >    from 1.4, and looks rather different.  I think there is a 1.4
> >    version of the APB patches out there, which might help adapting
> >    it). 
> The multi-host code?  Yes, I definitely agree, we need it in our first
> release.  I already gave it a +1, and while it is true that I haven't
> personally taken it and tested it, my vote of +1 is along the lines of 
> "I trust Cliff and Randy enough that if they have tested it sufficiently 
> to put their name on it, I believe them".  I have seen the version of 
> this patched against 1.3 work for 3 months on (try 
> - I can't test that it works myself since 
> neither hotwired nor hyperreal are using that feature (which involves 
> setting up a second ethernet interface, and I don't know how to do that 
> on SGI's and I don't have spare IP numbers to do this on hyperreal.)
> The most I can do is compile it on different platforms - if that works 
> and Cliff and Randy can absolutely verify its functionality let's do it.

Someone has been shouting at us to include this in 1.4, but it was a little
late in the development cycle, and I have nothing to test it on locally.
(Or time to learn how to get it on, I guess).  I might include it either 
in a separate patch directory, or else as #defines, but I wouldn't bet on
it.  Supposedly it patched into 1.4 with relative ease, but I haven't looked

By the way Rob, which machine (OS) did you run into that problem on (the 58
reloads), so I can start somewhere, or which access denied message appeared
in the error_log (was it always the same?)  On 1.4b3-3, I did 657 reloads of
the same page from Solaris 2.4 and couldn't reproduce any problems last week,
(Well, ok, 1.4b4pre, or some such).  Did you try moving the csd variable as


 Brandon Long   (N9WUC)     "I think, therefore, I am confused." -- RAW
 Computer Engineering   	Run Linux	It's that Easy. 
 University of Illinois
		Don't worry, these aren't even my views.

View raw message