httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter J. Cranstone" <Cranst...@worldnet.att.net>
Subject RE: Apache 164 percent speed increase
Date Wed, 13 Oct 1999 06:44:04 GMT
>>If you just want something to rag about, do it offline.  On-the-fly
compression sounds nice but what you win on the wire you lose on the CPU
both for compression and for detecting if the client is capable.  If the
latter isn't a worry, pre-compress everything (a content management
problem, not a server problem) and use multi views.  Yawn

The only sensible comment here is pre-compress the data. However you now
have the problem of determining  if the users browser can handle the
compressed content encoded data. If not you have one pissed off user.

Now back to your meaningless comment. ".  On-the-fly compression sounds nice
but what you win on the wire you lose on the CPU both for compression and
for detecting if the client is capable.

Wanna bet.  Go back and study our benchmark page. I mean really study it. We
use the STANDARD AB program from Apache. Exactly how can those stats be what
they are IF the server load was tanking in the background. It's all tied
together. As for detecting the client... stop being silly. According to
RFC's. User Agent field ( if present ) and or 'Accept encoding' field ( if
present ) and I can read those few bytes in about a millisecond. No slow
down there, compress the data, about 2 milliseconds and transmit the file
which is now 70% + smaller. Well I'm sure even you can do that math.

Seriously, why not do your own benchmarks before commenting on something
which you clearly don't understand.

Peter J. Cranstone
Cranstone@RemoteCommunications.com
http://www.remotecommunications.com

-----Original Message-----
From: new-httpd-owner@apache.org [mailto:new-httpd-owner@apache.org]On
Behalf Of Spidaman The Defenestrator
Sent: Wednesday, October 13, 1999 12:02 AM
To: new-httpd@apache.org
Subject: Re: Apache 164 percent speed increase

Meanwhile, back at the ranch...
> Would NOT be obviously meant as a base level URL request
> for a proxy server?

Get off your high horse, ever used URL's or URL fragments as path_info?

> Just in case you haven't used UNIX lately this is what happens
> if you try to actually have a directory called http://www.yahoo.com...
>
> # mkdir http://www.yahoo.com
> mkdir: cannot make directory `http://www.yahoo.com': No such file or
directory

<eyes rolling>

Er, duh, you need a -p option to mkdir or a directory 'http:' to exist
already.

> It would be nice if a program that calls itself a Server Benchmark test
> could actually bench mark things that call themselves Servers though,
> don't you think?

If you just want something to rag about, do it offline.  On-the-fly
compression sounds nice but what you win on the wire you lose on the CPU
both for compression and for detecting if the client is capable.  If the
latter isn't a worry, precompress everything (a content management
problem, not a server problem) and use multiviews.  Yawn.

--
Salon Internet                          http://www.salon.com/
  HTTP mechanic, Perl diver, Mebwaster, Some of the above
Ian Kallen <idk@salon.com> / AIM: iankallen / Fax: (415) 354-3326


Mime
View raw message