Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Message-ID: <00f901c21df3$3db0f1a0$0201a8c0@apache.org>
From: "Remy Maucherat" <remm@apache.org>
To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
References: 
 <20020627081557.4179.h002.c007.wm@mail.distributopia.com.criticalpath.net>
Subject: Re: Performance Test Workload: HelloWorld Servlet
Date: Thu, 27 Jun 2002 08:56:45 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

>  I'm getting unusual preliminary results on some
> performance tests against a very simple servlet, and
> I'd like to see what results other people get. If
> you're going to run the tests yourself, don't look at
> my results ahead of time if you can resist (they're at
> the bottom of the message)
>
>  I'm http_load'ing against 4.0.3 and 4.1 HEAD using
> 8 threads and 0,1,8,16 and 32k response sizes. I ran
> http_load on one machine and Tomcat on another. I ran
> a couple rounds before the final test at each response
> size to let the jit warm things up.
>
>  The server.xml I used just declares a single HTTP
> connector and a simple Engine/Host/Context. No logging,
> valves, etc.
>
>  The results are preliminary because I haven't done the
> appropriate system tuning and didn't bother with the
> proper controls on what was running on my test box, I
> have a sneaking suspicion I'm a few days out of date
> on HEAD.etc, etc. Note also that hitting a single URL
> over and over is a totally bogus way to test
> "performance", but relative results between different
> versions of the same software can be interesting.

Other points.

On an absolute basis, HTTP request parsing is as fast on Coyote HTTP/1.1
than on the old HTTP connector. It's normal, as I reused (most of) the
algorithm for Coyote (the only improvement is the HTTP header
canonicalization algorithm), and I wrote it at the time I still had
illusions about the feasability of refactoring the old connector. Then I
realized that although I could make it much faster through refactoring, it
would still look really ugly. The j-t-c/util objects were also more adapted
and nicer than the crappy recyclable objects I was using. And that's how
Coyote was started in j-t-c.

The old HTTP connector has an advantage when the URL is US-ASCII (if it's
not, bad luck, it will be incorrecly read, but it's non standard anyway, so
it's not a big problem, I suppose) an is no byte is URL encoded (ie, there
are no %xx). If there's one or more, you'll get a nasty performance hit,
while Coyote won't suffer from any performance hit.
Basically, what it does is: read bytes, and cast them into an array of chars
(saves b2c if everything goes well). However, if you have a %xx, what will
happen is c2b (really expensive one) -> decoding (using string buffers
;-)) -> b2c (also a very expensive one). You can't avoid doing that, since
the connector architecture doesn't support delayed b2c.
OTOH, Coyote keeps the URL as an array of bytes, then, if needed, does the
%xx decoding by mutating the array of bytes (so it's zero object creation,
without any b2c or c2b needed), but then has to pay for the b2c conversion
(expensive), if needed (and because of Catalina mapping algorithms, it is
always needed). For the HelloWorld servlet, I've seem through profiling that
the b2c here "costs" about 15-20% of the total CPU time spent by Tomcat,
almost offsetting the other advantages Coyote has over the old HTTP
connector in the object recycling department.

So to summarize, the old connector *may* look ok in very specific synthetic
benchmarks (you chose the right one; I hope you didn't choose that one to
try to prove that Coyote sucks, or something like it), but actually, it has
(big) issues. All these could be refactored, but it would take a lot of
time, and you would end up with something like Coyote in the end.

Remy


--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>