httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter J. Cranstone" <>
Subject RE: Apache 164 percent speed increase
Date Wed, 13 Oct 1999 06:32:51 GMT
Hi Tani...

Not sure what he's talking about to tell you the truth, but even if it's bps
then it's still a whole bunch over a 28K line :)

Anyway moving on.

Clarification: The music file sits on Rocky Mountain Internet's Sun ultra
dog server... It really is a dog, because they are hosting 247 other users
on the same box.

Both files reside in the same DIR. One is compressed, the other is
uncompressed. All things being equal you are downloading 663K and 45K
respectfully. Exactly how long did it take each respective file to reach
your PC? At 28K it should take184 seconds for the uncompressed file and 13
seconds for the compressed file.

Regarding CPU cycles. Again we need to be fair and put out some stats on
this. But some simple math should point the way.

Let's use the music example. It's large so differences will be easily shown.

Uncompressed the file is 663,000 bytes. Our compression server compresses
this file in less than a second (a whole lot less). It's now 48K or
thereabouts. What's key here is the amount of time required to process the
users GET request, determine that it's a content encoding aware browser, GET
the file either locally or off the web at backbone speeds, compress said
file and transmit the data. If the file is onboard, it's already compressed
ergo all the server does is transmit 48K. If it has to do all the other work
then total time including transmission (13 seconds) is going to be less than
15 seconds. In the meantime the other file still has over 2 1/2 minutes of
transmission time remaining.

At our main site we run a small server. It's a PII 300
with 128MB of RAM and a 4GB SCSI hard drive running SlackWare Linux. Nothing
very fancy. It's hooked through a slow router to a shared T1 line. We run a
multitude of server software, including MATHOPD, THTTPD, Apache, Boa, Zeus,
Squid 2.x and Squid 1.x at all times on this server. Utilizing the Unix TOP
command we can observe the CPU Idle stat. In all the testing we have done, I
personally have never seen the % fall below 75% idle. Most times it sits in
the 95% and higher range.

The compression server runs in real time and we proxy to it to surf the web.
In testing (over 9 million hits using regular HTML pages from the web) we
have yet to encounter a single error. The bandwidth savings on pure HTML are
impressive over a 131GB saved to date.

Real time on the fly compression is a complex task, and badly coded can
result in tanking the server. I would not be on this forum using AB
performance stats if the best the server could do was deliver the data but
the number of TPS were reduced due to server loading.

The key thing to remember here is this. If you have an Apache web server,
there is no reason files stored on the site can not be pre-compressed then
all you are doing is transmitting fewer bytes! TPS had to improve, the
TCP/IP sub system has less work to do. What if a browser requests a page and
it's not content encoding aware. Simple, decompress the file and transmit
the uncompressed version, same as a standard web server.

Bottom line... reduce the number of bytes you transmit albeit with a little
"cost" (compression) and your server has more time to do other task. The key
is to write the application to handle this in such a way that it doesn't
toast the server, which is exactly what we've done.


Peter J. Cranstone

-----Original Message-----
From: []On
Behalf Of Tani Hosokawa
Sent: Tuesday, October 12, 1999 11:50 PM
Subject: Re: Apache 164 percent speed increase

On Wed, 13 Oct 1999, Manoj Kasichainula wrote:

> On Tue, Oct 12, 1999 at 11:34:38PM -0600, Peter J. Cranstone wrote:
> > 10 transactions per second was your 'laugh test'.... 10 transactions per
> > second of a 10,495 byte  document over a dial up modem is IMPOSSIBLE.
> > 1,049,500 ( 1 MILLION plus ) BYTES PER SECOND!
> 10,495 * 10 = 104,950.

I assume he's talking about bits.  800kpbs is nice.  Still, here's
something interesting about this:  I've got a crappy little cable modem
here, and when I download music.htm.gz from the demo page I get it at
about 4k/sec, but when I download the uncompressed version I download at
35k/sec.  Nice that it's going to get to me quicker, but I bet that CPU is
churning at 100% to get it to me (much slower than normal).  I also doubt
that there's no way a server that's spending that much time on compression
is going to be able to compete against a normal Apache that's handling
real traffic (300+ requests/sec, 10k average request?).  OTOH, I'd love to
try it, and I'd be willing to use my traffic to test that theory...

tani hosokawa
river styx internet

View raw message