httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TOKI...@aol.com
Subject Apache 164 percent speed increase
Date Tue, 12 Oct 1999 22:56:29 GMT

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

Mime
View raw message