Higher Logic notes on screwing with tech…

23Mar/102

HTTP vs mod_proxy_ajp vs mod_jk (Part 1 Speed)

Hey all,

I have a very hard time finding out information around this topic, so I figured I'll just add my unnecessary 2 cents onto the web. When it comes to hosting a Java Application Server (or any application server) sooner or later you will want to have a good look at separating out the web layer from the application. Couple of major reasons are:

  • Better security/containment via abstraction
  • More logical network layout via separation of functional servers
  • Nice single point of entry/exit
  • Cleaner more manageable application configuration… and more…

Options, Options, Options… like chocolates...

Any who I run Apache and Tomcat for most of my setup. When it comes to Apache you got three options for achieving what we just spoke about. There are two categories available protocols this can occur over HTTP or AJP. AJP is a binary protocol where additional information can crammed into those interesting packets. For more information on the AJP13 protocol see here for  AJP13 on Apache.org.

  • Straight out HTTP(s) proxying

This is usually where apache serves as a standard reverse proxy and it passes all the traffic back to tomcat's existing http connector. So its like pass the parcel, HTTP/HTTP(s) -> HTTP. Usually there's no need to have route between Apache and Tomcat SSL encoded, this indeed causes even more issues with persistence and other funny hair-tearing scenarios… The next two are different implementations of AJP protocol.

  • mod_proxy_ajp

This looks (to me at least) like the proposed Apache solution going forward. Its bundled in with mod_proxy and shipped as standard on a lot of linux distributions like Ubuntu (my fav server distro… thats a story for another day).  Clustering can be done with mod_proxy_balancer.

  • mod_jk

This implementation driven by the Apache Tomcat team has been around for quite some time, possibly the most fully featured of the AJP implementations. Complete with clustering solution, more options than you can shake a stick at. mod_jk options.

  • mod_jk2

Mod_jk2 was meant to be the refractoring of mod_jk with Apache Portable Runtime (apr) but it never got the developer momentum behind it and ended up being ditched and unloved :(

  • other failed/unloved projects

There are others but none worth mentioning here. If you are interested here check here at wiki.apache.org.

Testbed… like a real bed only with less sleep

  1. Apache 2.2.8-1ubuntu0.15
  2. Tomcat 5.5.25-5ubuntu1.2
  3. Java GCJ 1.0.77-2ubuntu2
  4. Ubuntu Hardy (Ubuntu 8.04.4 LTS) updated to latest system packages as off March 23 2010.
  5. Jakata Jmeter

Jmeter parameters:

100 concurrent users Generating 1000 requests each = 100000 test samples
All requests hitting a heartbeat JSP file serving the date and time from Tomcat server

Cases like with in Boston Legal…

The three most important aspects in evaluating this solution will be performance, functionality and clustering ...

  1. JSP Hosted in Tomcat over HTTP/SSL measuring throughput, average request time... while hitting heartbeat app
  2. Functionality features
  3. Measuring throughput while testbed upgraded with load balancing

I wonder whats down that well…

First test is over HTTP, SSL will come soon.

HTTP

http

MOD_PROXY_AJP

ajp

MOD_JK

jk

Caned.

AJP claims 10% better throughput than JK
AJP an average response time claims 15% quicker than JK
AJP had a 47% imporvement on throughput JK
AJP average response time was 45% better than JK
JK had 33% increased throughput than HTTP
JK had average response time 36% better HTTP

I realise some of my tests are quite simple in scope, please let me know if some areas need more explanation or there are some glaring issues… I warn you I'm very lazy...

Now I gotta write up Part 2 and onwards… (soon I promise)

Filed under: Infrastructure 2 Comments
   
css.php