At 03:35 PM 4/10/2001 -0700, you wrote:
Yeah, it surprises me a little. All the docs say ajp13 is faster due to it's
connection re-use.
I can tell the connections are being re-used (by monitoring with
netstat). But it hasn't turned out to be a time saver for me.
I tested mod_jserv (ajp12) against mod_jk (ajp13) in my own tests and found
mod_jk to be about 40% faster. It also scaled more smoothly and handled the
load less erratically. I was doing simple inserts into a MySQL database from
my servlet. However, I didn't test mod_jk (ajp12) vs. mod_jk (ajp13). I
might have to go back and try that...
That would be great if you have a chance. I was just hitting a "hello world"
servlet in my tests. Although I found mod_jk/ajp12 to be faster than
mod_jk/ajp13, nothing beat the speed of hitting the HttpConnectionHandler
running on port 8080 or whatever.
-mahaffey
--jeff
- Original Message -----
From: "Tom Mahaffey" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, April 10, 2001 5:48 AM
Subject: Performance of AJP12 vs. AJP13
I've been developing/testing/staging with Apache 1.3.14 / mod_jk / Tomcat
3.2.1 for the last
several months (started with Tomcat 3.1 and upgraded to 3.2.1 soon after
its release).
I had not seen any performance problems (of course!) until I hit
production
and saw my CPU
utilization go through the roof and my app's response time slow to a
crawl. After cruising
through the mailing list archives, I tried using mod_jk as a handler
(instead of a filter) and
tried upgrading to JDK1.3 from JDK1.2. Neither of these gave much of a
performance
increase.
The one thing that gave me a dramatic increase in speed was to change my
JkMount
directives to use AJP12 workers instead of AJP13. Using the Apache
benchmark tool (ab), I saw
an increase of 5-fold or more for the number of requests per second I
could
handle.
Does this surprise anyone out there? I saw advice for speeding mod_jk,
but
did not come
across using AJP12 instead of AJP13. In addition to a increased rate of
requests per second,
my application server hardware also seems to be spending less cycles on
individual
httpd processes as well as the Java process which owns the running Tomcat.
Particulars:
+ Solaris 2.6
+ Apache 1.3.14
+ Tomcat 3.2.1 binary drop
+ mod_jk compiled as shared object from Tomcat 3.2.1 source
-mahaffey
