httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter J. Cranstone" <>
Subject RE: Apache and the opposition (Was: Apache 164..)
Date Wed, 13 Oct 1999 21:17:13 GMT

>> This is why I would like to make a really slick configuration tool for

The design of this application is extremely important. Right now it's
written in C and with all the reporting capabilities weighs in around 70K.
if we strip out the stats, if falls to around 35K.. We have Linux and
Solaris binaries.

The idea is really very simple... funnel bits at the Apache web server as
fast as you can without slowing any processes down and make the compression
algorithms as fast as possible.

What you cannot do is have the forked child processes handling each
compression cycle. Essentially each get request spawns multiple child
requests which in turn would mean that you would have multiple compression
algorithms running simultaneously, we tried this early on and the results
were really, really bad. CPU utilization dropped below 20% and tps was

No the key is the design, which after a year of work we can show handles the
processes correctly and enhances performance. I've watched the discussions
on this forum regarding performance and how important it is to optimize
every piece of code to maximize performance.

This is no trivial effort, more work can be done to further improve it's
efficiency, and we will posts the resulting stats for all to see. HTML is
bloated especially with JavaScript but it's nothing compared to XML which we
will deal with in a likewise manner when the relevant standards are posted
for all to see.


Peter J. Cranstone

-----Original Message-----
From: []On
Behalf Of Henrik Vendelbo
Sent: Wednesday, October 13, 1999 2:16 PM
Subject: Apache and the opposition (Was: Apache 164..)

> We've figured out how to improve the performance of your (the Apache
> Apache web server. We use your own ab benchmarks to prove out point. We
> detail the equipment we used to complete the test. We follow all
> RFC's and are totally 100% HTTP 1.x compliant.

No bull, I like that.

> Bottom line. Apache runs much faster and is more efficient with
> technology. If you don't care about this say so. But everyday I see a new
> statistic which talks about dwindling market share, about how Zeus and Boa
> out perform Apache and how MS is making inroads. I would have thought
> would welcome a simple solution which provides an speed improvement to an
> Apache server.

I don't really think that the reason is performance. Since I have only
joined the web community recently
may I offer some points from the sideline.
- The Commercial server vendor has a sales department, Apache doesn't. I'm
sure that M$ and others are pounding on the doors on every major potential
customer. With the whole marketing campaign against you, it will often be
hard for the technical department to convince management that Apache is the
best choice. Don't forget that most people can't tell the difference between
good and bad software, so they go for what sounds good.

- The Apache package itself is just an engine. If you are not knowledgable
in web technology it is hard to get started. I mean look at the Win32 SDK;
They have tons of examples, how to's, and thousands of documentation pages.

- Say you want to install the Apache Server with comparable to IIS. Then you
need to download and install three different packages. Install three layers
of software, with three different installation tools. Then you must get into
the flow of 5-10 config files. On the other side IIS is already installed on
NT, so you just get a nice fat book on IIS and start reading.

This is why I would like to make a really slick configuration tool for

> We've now set the benchmark for real time on the fly compression, your
> welcome to ignore it... but it has been set.

I'm glad somebody did it, keep it up.


P.S. Don't start complaining that people are stupid, we all do the same
thing; If we don't have the knowledge to tell the difference, we do what our
eyes and ears tell us. This is why FUD is so effective.

View raw message