httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <dgaudet-list-new-ht...@arctic.org>
Subject Re: Concerns wrt Apache and SGI's patches
Date Mon, 26 Feb 2001 00:48:11 GMT
On Wed, 21 Feb 2001, Jonathan Day wrote:

>    IMHO, Apache is in danger of taking the same road. For certain
> specific types of content, it's being out-classed. mod_ssl's EAPI

if you search through the archives you'll find that EAPI (and KEAPI) were
considered to be good ideas, but that they weren't considered to be the
best implementations of those ideas.  many alternatives were discussed,
but no code has ever been written.

i had a bad experience with EAPI was discovering that the EAPI patch
included in the redhat-6.2 version of apache does a memset() of 8192 bytes
of data per request -- 8188 bytes of those arrays are never used.  fixing
this bug was a big perf boost (i forget how much).  i've not found the
time to track down if this is still a problem in the latest EAPI or what.
it's just one of several performance nits with EAPI.

> , or
> something functionally similar, should be standard in Apache, by now.
> For static content, khttpd and tux are between 1.5 - 2.5 orders of
> magnitude faster than Apache. Cheetha (the Exokernel's web server) is
> nearer 3 orders of magnitude faster.

i'd like to point out that the going price for datacenter internet
bandwidth is $750 per Mbit/s per month.  i don't really have much
difficulty filling up a single 100baseT segment with apache given any
cheapo x86 from the past 3 or 4 years.  and i seriously doubt i'd ever be
spending $75K per month to feed a single server, i'd probably have a
cluster behind a load balancer.

on the other extreme of things, the full dynamic server, apache is a small
piece of the performance picture.  folks tend to use PHP, Perl, or Java
here, and deal with transactional data, and other such latencies.  a 3x
performance improvement on 6% of the overall picture is only a 2% overall
improvement.

nothing we ever do in userland will exceed TUX.  TUX is the last word
essentially -- to top TUX (and the SWC thinger on win32) the kernel
developers would have to start writing the TCP core in assembly.

(incidentally, khttpd is about as fast as zeus, or phhttpd ... i've never
quite understood the point of khttpd.)

>    To me, this indicates that there is a design problem that needs to
> be addressed. And, given the history of "Open Source", it'll either be
> by the Apache group or by an independent group starting from there as
> a base.

yes as you can see, redhat and dell wanted more performance than apache,
or anything else in userland for that matter, could offer, so they created
TUX.  unfortunately everyone who isn't using linux will lose out...  but
WIN32 has SWC, and Sun has some in-kernel thing whose acronym i'm not sure
of.

redhat didn't just skip straight to the kernel, there was an interim step
of trying out the linux sendfile() API in the phhttpd server ... they got
some pretty nice results.  but they realised it wasn't enough to grab the
#1 performance trophy.

yes, it'd be really nice to see performance improve, but the priorities
have never been such that the ASF would want to sacrifice maintainability
for it.  if you go all the way back in time to when Mike Abbott originally
submitted his patches to us you'll find that our complaints were all about
maintainability.  i essentially started dropping off the scene after that
so i don't know if the maintainability problems were ever addressed.
someone had to do the work... and there was a lot of other work going on
at the same time.

btw, this debate is not unlike any of a zillion debates i've watched on
linux-kernel.  they all start with some person or group going off and
writing a lot of useful code, but without much communication with the core
project folks (ASF in this case, torvalds and co. in the linux case).
then they submit a big monolithic patch and much angst occurs when the
core project folks aren't ready to accept it as is.  in an ideal world
we'd all have enough time to rewrite patches.

if you, and others who've commented, care so strongly about this issue i
suggest you join in and help Mike and the ASF work together by assisting
with the patch rework.  if the rework is looking to be too big to fit into
2.0 then start planning for 2.1.  (ditto for EASI functionality which 2.0
doesn't already have.)

-dean


Mime
View raw message