httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeffrey A. Stuart" <jstuart-apa...@neo.rr.com>
Subject RE: Apache 2.0 final ?
Date Wed, 13 Jun 2001 20:26:32 GMT
Greg, you miss my point.  I think that Apache 2.0 has more of a potential to
handle more throughput.  IE the multi process/multi threaded model seems to me
to be a FAST config.  It will ALSO mean (I HOPE!) that my memory constraints
are lower.  Since I use mod_perl, my apache procs are HUGE. :D  (IE 6 Mb+)
I'm hoping that with the above model, I'll be able to handle more connections
per second since each process will be able to handle multiple requests via the
threads.

--
Jeff Stuart
jstuart@neo.rr.com

-----Original Message-----
From: Greg Stein [mailto:gstein@lyra.org]
Sent: Wednesday, June 13, 2001 3:39 PM
To: new-httpd@apache.org; jstuart-apache@neo.rr.com
Subject: Re: Apache 2.0 final ?

Reality check: Apache is intended to be speedy, but our goal is not to be
the fastest. Fine, let Zeus be faster. But they aren't nearly as flexible
as us. Dunno what their HTTP conformance is like, but that is also one of
our goals.

You could say that we aren't intending to "compete" on pure speed. If you
*really* want speed, get yourself a Linux box and install TUX or something.

Cheers,
-g

On Wed, Jun 13, 2001 at 11:55:49AM -0400, Jeffrey A. Stuart wrote:
> Ok, I've emailed this a couple of times and I'm gonna say it once again. :)
> We NEED Apache 2.0 out ASAP.  We needed Apache 2.0 out in January.  We
needed
> a beta back last year at the end of September or October whenever the UK
> ApacheCon was.  I can't stress this enough.  Apache is starting to fall
behind
> technologically.  I have a friend of mine who had to switch from Apache to
> Zeus cause Apache couldn't handle the load.  He was only able to get a max
> throughput of 12 Mb/s out of Apache and he PERSONALLY was able to get 40
Mb/s
> out of Zeus.  AND he told me that he's heard of people doing 80 Mb/s through
> Zeus.
>
> We NEED Apache 2.0. :)  I think the multi proc/multi threaded model will
> really give some oomph to the server.  Combine that soon with mod_perl 2.0
and
> some other technologies out there and we can compete with Zeus and some of
the
> other web servers in high load applications.
>
> --
> Jeff Stuart
> jstuart@neo.rr.com
>
> -----Original Message-----
> From: Bill Stoddard [mailto:bill@wstoddard.com]
> Sent: Wednesday, June 13, 2001 12:52 AM
> To: new-httpd@apache.org; William A. Rowe, Jr.
> Subject: Re: Apache 2.0 final ?
>
>
> > From: "Brian Behlendorf" <brian@collab.net>
> > Sent: Tuesday, June 12, 2001 10:01 PM
> >
> >
> > > On Tue, 12 Jun 2001, William A. Rowe, Jr. wrote:
> > > > Trick question, let me explain...
> > >
> > > I think people like him are asking: when is the fiddling done, and
people
> > > have a program they can start to incorporate into their operating system
> > > releases, deploy for production customers, etc?  While we're still
working
> > > on low-level issues like pools/sms in APR and fixing other big
performance
> > > issues, we're not there yet.
> >
> > Agreed, but let's not be too obsessed about performance vs. architecture.
> > If the architecture is right, optimization becomes trivial in 2.0.21, .22,
> etc,
> > so sms-enhanced pools are a precursor to a release.  Full implementation
of
> > twelve alternate memory allocation structures is not...
>
> a precursor to a release? Or not trivial? I hope it is not necessary to
fully
> implement
> twelve alternate memory blah blah before a release :-)
>
> >
> > I see very few showstoppers remaining to a general 'find the bugs' beta
> release
> > in the course of the next two weeks.  Resolving the query-scoreboard and
> getting
> > the lifetimes straightened out first is key (and sms helps with alternate
> > lifetimes.)  But I don't see any more "Big Things" to hold up 2.0.  We are
> close
> > enough to taste it.
>
> Yep.
>
> >
> > To have mod_ssl/tls all wrapped up for the general release would be
> fantastic,
> > of course, but it would be nice to know Apache 2.0 sans ssl is as solid
and
> > far superior to Apache 1.3 even before that's introduced.
>
> We definitely should not wait for SSL.
>
> >
> > If it means that we end up with a stable release in July, without the
> mod_ssl,
> > that's fine by me.
>
> Roger that.
>
> > If the next stable 2.0 incarnation rolls in mod_ssl, I think
> > everyone could live with that.  If proxy reaches stability when Apache
does,
> then
> > great, call them both stable.  Otherwise, we have Apache 2.0 stable,
> including
> > proxy beta candidate.  The parts ought to grow and stabilize on their own.
> >
> > The async and layered I/O ideas are great, and both would take some time
(6
> mos?)
> > to evolve.  But somewhere along the line we have to decide 'that's 2.1.'
>
> Sounds good to me. I agree that this should not hold up 2.0 (though I am a
fan
> of
> eventually getting both into the 2.* line).
>
> >
> > > I think it's enough to state "as soon as the showstoppers are out of
> > > the httpd-2.0/STATUS file" as a qualifier for that.  Hopefully it means
> > > folks are focusing on those issues.
> >
> > One hopes :-)  Can't forget though that it's one's own itches.  Apache
tries
> to prove
> > that many coders, pulling the oars to their own sense of rhythm, create
> something
> > worthwhile.  Some days the oars get tangled, but I think we succeed
> neverless.
>
> Heh... I recall telling Ryan on this list, around 8 months ago that
> introducing filters
> into Apache 2.0 would delay us 6 months. And Ryan said no way would filters
> delay us 6
> months, it would only be on the order of weeks.  Heh, heh... Still
> counting...Filters are
> way cool and scratch a big itch but there is a lesson here. :-/  If you want
> to see Bill
> go completely ape-shit, just propose that another big chunk-o-code like
> filters go into
> Apache 2.0 before it is released :-)
>
> Bill

--
Greg Stein, http://www.lyra.org/


Mime
View raw message