You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by TO...@aol.com on 1999/10/13 04:56:29 UTC
Apache 164 percent speed increase
In the course of testing our new online real-time document
compression server at http://www.rctp.com we have found a
number of problems with regards to ApacheBench.
RCI's online compression servers work with ANY version of
ANY HTTP compliant server but when used in conjunction with
Apache there is a 164 ( ONE HUNDRED AND SIXTY FOUR ) percent
performance increase for Apache.
You can see the official testing results yourself online at
http://www.remotecommunications.com/t1000.htm
This URL
http://www.rctp.com:5010/getstat1/squid
Shows the server running in REAL TIME in conjunction
with SQUID 2.1 compressing all documents requested and
shows over 9 MILLION hits with a total byte savings
of over 131 GIGABYTES.
Performance increase when used in conjunction with SQUID
( Any version ) is much the same if not a few percentage
points better than Apache. 164+ percent increase.
* ApacheBench problem 1
Line 778 of ApacheBench in Apache_1.3.9\src\support\ab.c
is incorrect. If you add an 'Accept-Encoding: gzip, compress'
header option via the command line it gets added to the BODY
of the document and not the HEADER where it belongs.
Relevant 'clip' from AB.C...
/* setup request */
if (!posting) {
sprintf(request, "GET %s HTTP/1.0\r\n"
"User-Agent: ApacheBench/%s\r\n"
"%s" "%s" "%s"
"Host: %s\r\n"
"Accept: */*\r\n"
"\r\n" "%s", <---- Line 778 of AB.C is incorrect
path,
VERSION,
keepalive ? "Connection: Keep-Alive\r\n" : "",
cookie, auth, hostname, hdrs);
}
There is no need for a CVS 'diff' or a PATCH on this.
It's just a simple mistake and needs a quick re-type
on the part of someone who knows where the 'real' master
source module is.
The header build for a POST statement directly below the
bad header build is fine with regards to 'hdrs'. 'hdrs'
buffer ends up in the header where it belongs.
We fixed it here and ran ApacheBench test against RCI's new
online compression server and ApacheBench correctly reports
a 164 percent speed increase when using the online
compression server with Apache.
While ApacheBench is adequate for most purposes and is
a good 'standard benchmark'... real-time online document
compression is here NOW and it is here to stay so ApacheBench
really needs to start including some decompression code to come
up with some 'truly' accurate stats.
There needs to be a new 'result' field called
'Virtual Transfer Rate' which shows how many 'real' bytes
were transferred after decompression.
The 'Virtual Transfer Rate' field would show you how
compressing mime types results in a 'virtual' kb/s rate that
is much, much HIGHER than the 'actual' transfer rate which is
the only thing currently reported by ApacheBench.
When compressed text/xxxx is being transmitted the actual
transfer time means very little... what is really important
is how many 'uncompressed' bytes were received.
THAT is the 'real' transfer rate from the user's perspective
and will become the new relevant 'benchmark' figure
in the very near future.
* ApacheBench and PROXY servers.
The only thing stopping ApacheBench from being used to test
ANY Proxy Server as well as a Web Server is just a simple
glitch in the 'parse_url()' routine that refuses to remove
the forward slash from the command line URL if that URL is a
fully qualified name such as 'http://www.somwhere.com/some.document'
A simple fix to parse_url() that recognizes a 'proxy' request
and removes the leading slash allows ApacheBench to be used
to test ANY proxy server.
We made the fix here and tested the compression server(s)
running with SQUID using ApacheBench. Works fine once
the fix is in.
Kevin Kiley
CTO, Remote Communications, Inc.
http://www.RemoteCommunications.com
mailto: Kiley@RemoteCommunications.com
and/or TOKILEY@aol.com
Re: Apache 164 percent speed increase
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
TOKILEY@aol.com wrote:
>
> There is no need for a CVS 'diff' or a PATCH on this.
> It's just a simple mistake and needs a quick re-type
> on the part of someone who knows where the 'real' master
> source module is.
You've been here long enough to know that's not how things
work. Your remark is roughly equivalent to "I know what
the problem is and how to fix it, but I'm only going to
tell you about it rather than supplying the fix I already
have."
Besides, as Marc points out, this was already fixed. :-)
--
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://ASFD.MeepZor.Com/>
Compression
Posted by Henrik Vendelbo <hv...@bluprints.com>.
Sure this is a tricky thing. If we can send compressed text instead of text over the internet it should help the bandwidth, but I think the problem is twofold if proper performance improvement is to be reached.
1) The .html .xml .text files would have to be uploaded in a compressed version. I mean this is a web server, not an application server, and the compression feature could easily be added to modern tools.
2) The browsers would need a standard for accepting the zipped version, that sounds like a new HTTP version to me. Browsers that support compression would then add a flag in the HTTP header when requesting a page. Then if an older browser requests the page, the server will decompress it before transmitting.
This solution would allow for transition and leave the descision up to the webmaster. If no compressed pages are uploaded the feature is never used. Generated pages by Servlets/PHP/Perl/ASP/JSP etc. would just be handled normally as uncompressed pages.
The performance of the webserver would be improved by quicker disk access and transfer time, but degraded when decompressing. I'm no compression specialist, but I believe that would end up as an improved server performance on most systems (given a choice of a compression that i quick to decompress). Over time browsers would support the feature taking over the decompression task.
thoughts ?
RE: Apache 164 percent speed increase
Posted by "Peter J. Cranstone" <Cr...@worldnet.att.net>.
Jeff,
No you are not a........
A) gzip compression is supported by client browsers because someone did
think that it was a good idea to compress data one day.
B) I would believe that the compression of gzip uses much more CPU time than
the compression that is built into the hardware of your modem.
Let me make it clear that we all understand that "pie is not free in this
universe". The actual compression cycle is going to require just that,
cycles. But we need to look at this further... the average file (HTML) on
the web probably weighs in at about 50K or more, but less than 100K.
Depending on HOW you code you compression program you should be able to
compress this size file in about a millisecond or so. The compression cycle
is now over. What you have to do next is get it to the user which is the job
of the server. Considering it's 70% smaller this is going to take a fraction
of the time required by the uncompressed file... we're no longer taking
milliseconds here, were talking SECONDS... during those seconds the server
is using cycles to send the data through the tcp/ip sub layer.
We've spent over a year working on this program. The first versions caused
the very problems that everyone on this forum is talking about, it CRUSHED
the server. Apache is a forking server and requires it's own memory
resources for each new child process which is spawned. Spawning and
compression is combustible combination and resulted in such poor performance
that we shelved the approach.
As Warner Von Braun is quoted as saying "You can usually recover from
production flaws but you can never fully recover from a bad design." We had
a bad design and that's all there was too it. We went back to the drawing
board and now we have a new design which gives us the stats you've seen on
our site. Apache is free to do it's work and we handle the "bits" coming
into and leaving the server.
Final point on hardware compression in your modem. Most of the time the
modem is spent receiving data, i.e. you make a get request which sends out a
small packet of data for the web server to process, the HTML pages are then
returned to your PC in packets. The modems are not smart enough, yet, to
know what type of data it is, or whether or not it can be compressed..
Remember we don't compress data sent from a users PC to GET a web page, we
only compress the returning data, the modem has no idea what is coming back
into the PC. Decompression whilst it consumes cycles is ALWAYS faster than
compression (entropy encoding scheme discussed here) we've moved the
decompression stage to the clients PC which even if it's 386 is very fast,
especially on a small page.
Regards,
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 Jeff Johnson
Sent: Wednesday, October 13, 1999 8:07 AM
To: Peter J. Cranstone
Cc: new-httpd@apache.org
Subject: Re: Apache 164 percent speed increase
On Tue, Oct 12, 1999 at 11:34:38PM -0600, Peter J. Cranstone wrote:
> Anyway, as you can see we actually more than DOUBLE the number of
> transactions per second using compression. 21 transactions per second
jumped
> to 56 or a 166% improvement. "The assertion about saving modem users
> bandwidth is ludicrous". What is ludicrous is that statement. I'm going to
> let you do the math. It's very simple.
Not to intrude on this conversation, however, I see two points here:
a) gzip compression of pages, if supported seamlessly by clients is
both something that should be supported by HTTP and by Apache,
because it is a Good Idea (tm).
b) However, is the server actually free the handle more requests?
I would believe that the compression of gzip uses much more
CPU time than the compression that is built into the hardware
of your modem. Doesn't the modem try to compress the data again
as well? Because of this, you'll always get a 'higher' throughput
rating when transferring, say, a text file when compared to a .ZIP file.
We all learned this in our BBS days. While the data may get to the
client
"166% faster", with the extra CPU overhead, I seriously doubt that you
would be able to process 166% more ACTUAL REQUESTS by enabling gzip
compression.
Am I a total moron here?
--
Jeffrey H. Johnson, jeff@websitefactory.net
The Web Site Factory, http://www.websitefactory.net
Re: Apache 164 percent speed increase
Posted by Jeff Johnson <je...@websitefactory.net>.
On Tue, Oct 12, 1999 at 11:34:38PM -0600, Peter J. Cranstone wrote:
> Anyway, as you can see we actually more than DOUBLE the number of
> transactions per second using compression. 21 transactions per second jumped
> to 56 or a 166% improvement. "The assertion about saving modem users
> bandwidth is ludicrous". What is ludicrous is that statement. I'm going to
> let you do the math. It's very simple.
Not to intrude on this conversation, however, I see two points here:
a) gzip compression of pages, if supported seamlessly by clients is
both something that should be supported by HTTP and by Apache,
because it is a Good Idea (tm).
b) However, is the server actually free the handle more requests?
I would believe that the compression of gzip uses much more
CPU time than the compression that is built into the hardware
of your modem. Doesn't the modem try to compress the data again
as well? Because of this, you'll always get a 'higher' throughput
rating when transferring, say, a text file when compared to a .ZIP file.
We all learned this in our BBS days. While the data may get to the client
"166% faster", with the extra CPU overhead, I seriously doubt that you
would be able to process 166% more ACTUAL REQUESTS by enabling gzip
compression.
Am I a total moron here?
--
Jeffrey H. Johnson, jeff@websitefactory.net
The Web Site Factory, http://www.websitefactory.net
RE: Apache 164 percent speed increase
Posted by "Peter J. Cranstone" <Cr...@worldnet.att.net>.
Thanks for the correction Manoj...
104,950 bytes per second over a 28K modem is still a stretch to do though :)
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 Manoj Kasichainula
Sent: Tuesday, October 12, 1999 11:39 PM
To: new-httpd@apache.org
Subject: Re: Apache 164 percent speed increase
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.
That's
> 1,049,500 ( 1 MILLION plus ) BYTES PER SECOND!
10,495 * 10 = 104,950.
--
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
RE: Apache 164 percent speed increase
Posted by "Peter J. Cranstone" <Cr...@worldnet.att.net>.
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 http://www.rctp.com 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.
Regards,
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 Tani Hosokawa
Sent: Tuesday, October 12, 1999 11:50 PM
To: new-httpd@apache.org
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.
That's
> > 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
Re: Apache 164 percent speed increase
Posted by Tani Hosokawa <un...@riverstyx.net>.
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. That's
> > 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
Re: Apache 164 percent speed increase
Posted by Manoj Kasichainula <ma...@io.com>.
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. That's
> 1,049,500 ( 1 MILLION plus ) BYTES PER SECOND!
10,495 * 10 = 104,950.
--
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
RE: Apache 164 percent speed increase
Posted by "Peter J. Cranstone" <Cr...@worldnet.att.net>.
ROFL...
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. That's
1,049,500 ( 1 MILLION plus ) BYTES PER SECOND!
Sorry, I thought you'd understand the results put out by ab better than
this.
Anyway, as you can see we actually more than DOUBLE the number of
transactions per second using compression. 21 transactions per second jumped
to 56 or a 166% improvement. "The assertion about saving modem users
bandwidth is ludicrous". What is ludicrous is that statement. I'm going to
let you do the math. It's very simple.
Index.html at Yahoo is 10,495 bytes. connected at 28K it takes 2.92 seconds
to transmit that document and consumes 10,495 bytes of bandwidth. Please
enter here:______ what the modem saves.
Now lets compress index.html even gzip gets about 72% to reduce the file to
2,886 bytes. transmission time is 8 tenths of a second and consumes 2,886
bytes. Please enter here:_____ what the modem saves.
If the second answer is SMALLER than the first which it will be, then guess
what. Compressing HTML output is more efficient than transmitting it
uncompressed.
What don't you understand here. The server transmits 72% FEWER bytes to the
user. It gets there 72% FASTER than a standard web server. Which FREE's the
web server up to handle MORE requests.
I'm sorry you can't understand simple math, as for "spew" well I think you
need to revisit AB and understand how it works.
Regards,
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 Jeffrey W. Baker
Sent: Tuesday, October 12, 1999 11:21 PM
To: new-httpd@apache.org
Subject: Re: Apache 164 percent speed increase
"Peter J. Cranstone" wrote:
[...]
> As for your "whatever" comment. Let's see, with compression turned on, the
> server is faster, bandwidth is saved, the consumers experience is improved
> and the web server transmission cycles are reduced. Please respond as to
why
> this is not a desired feature for any web server.
[...]
In what way is 0.56 requests per second on static content faster than
anything? Even with only one client, I would expect to see at least 10
requests per second before your system even passed my laugh test.
The assertion about saving modem users' bandwith is ludicrous. Even old
modems have hardware compression algorithms that compress HTML and other
repetitive text very well. With good hardware (~$50) 2:1 text
compression is unremarkable.
Honestly I was completely unable to glean the slightest bit of a point
from this spew.
-jwb
Re: Apache 164 percent speed increase
Posted by "Jeffrey W. Baker" <jw...@cp.net>.
"Peter J. Cranstone" wrote:
[...]
> As for your "whatever" comment. Let's see, with compression turned on, the
> server is faster, bandwidth is saved, the consumers experience is improved
> and the web server transmission cycles are reduced. Please respond as to why
> this is not a desired feature for any web server.
[...]
In what way is 0.56 requests per second on static content faster than
anything? Even with only one client, I would expect to see at least 10
requests per second before your system even passed my laugh test.
The assertion about saving modem users' bandwith is ludicrous. Even old
modems have hardware compression algorithms that compress HTML and other
repetitive text very well. With good hardware (~$50) 2:1 text
compression is unremarkable.
Honestly I was completely unable to glean the slightest bit of a point
from this spew.
-jwb
Re: Apache 164 percent speed increase
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Peter J. Cranstone wrote:
>
> As for your "whatever" comment. Let's see, with compression turned on, the
> server is faster, bandwidth is saved, the consumers experience is improved
> and the web server transmission cycles are reduced.
It's a zero-sum game once a limiting factor has been reached.
How is the server faster if it's devoting cycles to compressing
data? Only if it had the cycles to spare (which it probably,
but far from certainly, did). And the 'faster' aspect is
illusory even then, being measured as response time. Which
is, of course, one of the best measures -- it's perception,
which is all-important.
Yes, bandwidth consumption would almost certainly be
reduced, as would the server transmission cycles (I'm
not sure exactly what you mean by that, but I'm
assuming you mean the amount of wall-clock time the
server experiences processing the sending of the response
from the first byte to the last.)
The consumer's experience is improved *only* if the
response time is improved. That happens only as a
result of other things; it won't be any better if the
wall-clock time spent compressing exceeds the wall-clock
time it would have taken to transmit the uncompressed
data. Which is situational; you're exchanging I/O
duration for CPU duration. That's *usually* a more-than-fair
exchange, but not always.
> As for our views on compression. I respect your opinion and in the mean time
> I suggest that you post your own views on how you would do compression (if
> you are able to do so) or better still maybe you can tell us why it is an
> unimportant feature for Apache.
I don't think we regard it as unimportant -- it's just
that it hasn't yet lit enough of a fire in anyone's belly
to do something about it.
--
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://ASFD.MeepZor.Com/>
RE: Apache 164 percent speed increase
Posted by "Peter J. Cranstone" <Cr...@worldnet.att.net>.
>> Whatever. There has already been far too much attention given to your...
>>odd views about how compression should be done. Hmm, I notice that your
>>solution still only works on IE running on Windows and that your demo of
>>how well your product works consists of comparing the size of a gzipped
>>file to a non-gzipped file. Sorry, compression has actually been around
>>for a while and people have been gzipping files since the week before
>>last.
Might want to review your facts. Gzip content encoding is supported in MSIE
4.x and higher, along with Netscape 4.51 and higher. Compression has been
around for years, funny how useful it is and yet Apache has no native real
time support for it, until now that is. Our solution operates with these
browsers without the need for a client piece. Older browsers obviously
require a client side app. With regard to gzip. It is a useful compression
algorithm but sorely outdated when compressing HTML and XML documents. It is
slow and poorly designed for the dataset. We have already have designed
algorithms which outperform gzip's compression levels by an additional 8-10%
As for your "whatever" comment. Let's see, with compression turned on, the
server is faster, bandwidth is saved, the consumers experience is improved
and the web server transmission cycles are reduced. Please respond as to why
this is not a desired feature for any web server.
As for our views on compression. I respect your opinion and in the mean time
I suggest that you post your own views on how you would do compression (if
you are able to do so) or better still maybe you can tell us why it is an
unimportant feature for Apache.
Last time I checked, one of the biggest problems on the web is speed and as
for the foreseeable future at least 98% of the web will connect at 28K or
slower I see the need for more efficient software. Unless Apache makes
changes towards efficient delivery of documents, other servers which address
these problems will surely make significant inroads into your market share.
XML is significantly more bloated than HTML, Apache's native performance
will suffer greatly without significantly reducing the size of these
documents.
Personally I could care less what you think of our compression technology or
our approach. I have followed this forum for a year now and have watched
many, many interesting exchanges. The compression technology works, there is
a clear and significant benefit to using it. People who have poor low
bandwidth connections and those who pay for their bandwidth are always
interested in ways to save money.
Bottom line Mark. A compressed Apache server will 'always" outperform a non
compressed Apache server by a considerable margin. Guess your stuck in the
slow.
Cheers.
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 Marc Slemko
Sent: Tuesday, October 12, 1999 10:01 PM
To: new-httpd@apache.org
Subject: Re: Apache 164 percent speed increase
On Tue, 12 Oct 1999 TOKILEY@aol.com wrote:
>
> In the course of testing our new online real-time document
> compression server at http://www.rctp.com we have found a
> number of problems with regards to ApacheBench.
>
> RCI's online compression servers work with ANY version of
> ANY HTTP compliant server but when used in conjunction with
> Apache there is a 164 ( ONE HUNDRED AND SIXTY FOUR ) percent
> performance increase for Apache.
Whatever. There has already been far too much attention given to your...
odd views about how compression should be done. Hmm, I notice that your
solution still only works on IE running on Windows and that your demo of
how well your product works consists of comparing the size of a gzipped
file to a non-gzipped file. Sorry, compression has actually been around
for a while and people have been gzipping files since the week before
last.
> * ApacheBench problem 1
>
> Line 778 of ApacheBench in Apache_1.3.9\src\support\ab.c
> is incorrect. If you add an 'Accept-Encoding: gzip, compress'
> header option via the command line it gets added to the BODY
> of the document and not the HEADER where it belongs.
>
> Relevant 'clip' from AB.C...
>
> /* setup request */
> if (!posting) {
> sprintf(request, "GET %s HTTP/1.0\r\n"
> "User-Agent: ApacheBench/%s\r\n"
> "%s" "%s" "%s"
> "Host: %s\r\n"
> "Accept: */*\r\n"
> "\r\n" "%s", <---- Line 778 of AB.C is incorrect
> path,
> VERSION,
> keepalive ? "Connection: Keep-Alive\r\n" : "",
> cookie, auth, hostname, hdrs);
> }
>
> There is no need for a CVS 'diff' or a PATCH on this.
> It's just a simple mistake and needs a quick re-type
> on the part of someone who knows where the 'real' master
> source module is.
This is already fixed in the current CVS tree.
[...]
> While ApacheBench is adequate for most purposes and is
> a good 'standard benchmark'... real-time online document
> compression is here NOW and it is here to stay so ApacheBench
> really needs to start including some decompression code to come
> up with some 'truly' accurate stats.
Erm... I don't think so thanks.
> There needs to be a new 'result' field called
> 'Virtual Transfer Rate' which shows how many 'real' bytes
> were transferred after decompression.
>
> The 'Virtual Transfer Rate' field would show you how
> compressing mime types results in a 'virtual' kb/s rate that
> is much, much HIGHER than the 'actual' transfer rate which is
> the only thing currently reported by ApacheBench.
>
> When compressed text/xxxx is being transmitted the actual
> transfer time means very little... what is really important
> is how many 'uncompressed' bytes were received.
> THAT is the 'real' transfer rate from the user's perspective
> and will become the new relevant 'benchmark' figure
> in the very near future.
I don't think so. If you can do x amount of traffic, then that is x
amount of traffic period. If you compress it, you may need less traffic
to send the same thing but that isn't something that ab should care
about.
> * ApacheBench and PROXY servers.
>
> The only thing stopping ApacheBench from being used to test
> ANY Proxy Server as well as a Web Server is just a simple
> glitch in the 'parse_url()' routine that refuses to remove
> the forward slash from the command line URL if that URL is a
> fully qualified name such as 'http://www.somwhere.com/some.document'
>
> A simple fix to parse_url() that recognizes a 'proxy' request
> and removes the leading slash allows ApacheBench to be used
> to test ANY proxy server.
You would need to be a bit more explicit about what you are talking
about. Posting diffs always helps. How does fixing a "simple glitch
in parse_url" let you specify what proxy to use and what origin server
to talk to?
Re: Apache 164 percent speed increase
Posted by Marc Slemko <ma...@znep.com>.
On Tue, 12 Oct 1999 TOKILEY@aol.com wrote:
>
> In the course of testing our new online real-time document
> compression server at http://www.rctp.com we have found a
> number of problems with regards to ApacheBench.
>
> RCI's online compression servers work with ANY version of
> ANY HTTP compliant server but when used in conjunction with
> Apache there is a 164 ( ONE HUNDRED AND SIXTY FOUR ) percent
> performance increase for Apache.
Whatever. There has already been far too much attention given to your...
odd views about how compression should be done. Hmm, I notice that your
solution still only works on IE running on Windows and that your demo of
how well your product works consists of comparing the size of a gzipped
file to a non-gzipped file. Sorry, compression has actually been around
for a while and people have been gzipping files since the week before
last.
> * ApacheBench problem 1
>
> Line 778 of ApacheBench in Apache_1.3.9\src\support\ab.c
> is incorrect. If you add an 'Accept-Encoding: gzip, compress'
> header option via the command line it gets added to the BODY
> of the document and not the HEADER where it belongs.
>
> Relevant 'clip' from AB.C...
>
> /* setup request */
> if (!posting) {
> sprintf(request, "GET %s HTTP/1.0\r\n"
> "User-Agent: ApacheBench/%s\r\n"
> "%s" "%s" "%s"
> "Host: %s\r\n"
> "Accept: */*\r\n"
> "\r\n" "%s", <---- Line 778 of AB.C is incorrect
> path,
> VERSION,
> keepalive ? "Connection: Keep-Alive\r\n" : "",
> cookie, auth, hostname, hdrs);
> }
>
> There is no need for a CVS 'diff' or a PATCH on this.
> It's just a simple mistake and needs a quick re-type
> on the part of someone who knows where the 'real' master
> source module is.
This is already fixed in the current CVS tree.
[...]
> While ApacheBench is adequate for most purposes and is
> a good 'standard benchmark'... real-time online document
> compression is here NOW and it is here to stay so ApacheBench
> really needs to start including some decompression code to come
> up with some 'truly' accurate stats.
Erm... I don't think so thanks.
> There needs to be a new 'result' field called
> 'Virtual Transfer Rate' which shows how many 'real' bytes
> were transferred after decompression.
>
> The 'Virtual Transfer Rate' field would show you how
> compressing mime types results in a 'virtual' kb/s rate that
> is much, much HIGHER than the 'actual' transfer rate which is
> the only thing currently reported by ApacheBench.
>
> When compressed text/xxxx is being transmitted the actual
> transfer time means very little... what is really important
> is how many 'uncompressed' bytes were received.
> THAT is the 'real' transfer rate from the user's perspective
> and will become the new relevant 'benchmark' figure
> in the very near future.
I don't think so. If you can do x amount of traffic, then that is x
amount of traffic period. If you compress it, you may need less traffic
to send the same thing but that isn't something that ab should care
about.
> * ApacheBench and PROXY servers.
>
> The only thing stopping ApacheBench from being used to test
> ANY Proxy Server as well as a Web Server is just a simple
> glitch in the 'parse_url()' routine that refuses to remove
> the forward slash from the command line URL if that URL is a
> fully qualified name such as 'http://www.somwhere.com/some.document'
>
> A simple fix to parse_url() that recognizes a 'proxy' request
> and removes the leading slash allows ApacheBench to be used
> to test ANY proxy server.
You would need to be a bit more explicit about what you are talking
about. Posting diffs always helps. How does fixing a "simple glitch
in parse_url" let you specify what proxy to use and what origin server
to talk to?