There are a variety of ways to implement proxying capabilities for web servers. As Apache is the most popular web server, we will try to implement proxying on it. Everyone who knows Apache well, probably knows that Apache implements proxying capability for AJP13 , FTP, CONNECT , HTTP/1.x.
The choice of reverse proxy server is fully dependent on what is actually trying to be hidden behind it. Each proxy mechanism has its own benefits and bottlenecks. Only for Apache, there are several ways to hide application servers (mod_proxy, mod_passenger, mod_wsgi, mod_jk). While mod_passenger and mod_wsgi are good for ruby and python servers respectively, these are a little bit outside the proxying idea. In this article I would like to discuss mod_proxy and mod_jk.
Now let’s think about what we have and what we want to put under proxy. The most common case is to put a pool of Tomcat servers behind Apache. Tomcat servers by default listen to 8080 for HTTP and 8009 for AJP. Now, we want to have Apache listen to 80 for incoming HTTP requests and 443 for HTTPS. People who have configured Tomcat for SSL will undoubtedly agree with me that SSL on Tomcat is quite annoying, so it’s better to implement SSL on the Apache side rather than playing with Tomcat’s keystores.
Okay, now we have two Tomcat servers on 2 different servers with our application installed, and both are on 8080 and an 8009 HTTP/AJP respectively. And one Apache on a third which will do HTTP on 80 , HTTPS on 443 for us and process requests to downstream Tomcat servers.
Situation 1 with mod_proxy and mod_proxy_http:
OK, here’s what this means:
User opens http://www.yourdomain.com in their browser
Well, so what are the pros and cons of this situation? We will provide some comparison tables below, but in general:
Now let’s see Situation 2, where we use JK for downstream servers:
At first sight we can see that nothing has been changed, but this is only at first sight. The main difference here is that now Apache is talking to the Tomcats via AJP 13 and not HTTP protocol. So the process of opening the web site is the following:
It seems there is a little overhead with jumping around on HTTP and AJP, but there are benefits as well. Let’s see the Good and Bad sides of JK balancing:
At this moment you may be asking “Why do I need this? I have a single Tomcat server and it’s working fine”. As a matter of fact, you need to build a network which can handle your current load, be scalable and which will not affect the normal behavior of your websites. From this point of view, the choice of reverse proxy solution is quite reasonable.
Here is a real life example of one of our client server architectures, which I think is a good one
In general, the process is as follows:
This is a real live working scenario, and it proved itself to be fault tolerant and extremely fast.
I know that after reading this article a lot of people will ask, “why is Apache needed when Varnish can do session stickiness, etc. …”
But the idea here is to use the best possible software for each particular role, software which has real and approved redundancy and reasonable layers of architecture which can help us to easily and quickly detect problems and fix them as they appear. Also, if we keep in mind that the client uses not only HTTP, but also HTTPS, I did not see any webserver which worked with SSL as smoothly as Apache did. Even if we do not have SSL initially, we will have it soon, and I do not believe that any web project can go far without SSL.
Following is a little comparison of JK and mod_proxy, so you can see more closely what these tools are.
|Node failure detection||mod_proxy_balancer has to be present in the server||7||Advanced||10|
|Backend SSL||supported (mod_ssl required)||5||not supported||0|
|Session stickiness||not supported||0||Supported via JVM Route||10|
|Protocols||HTTP, HTTPS||10||AJP 13||8|
|Node decommissioning||Manual needs Apache reload||3||Online via web admin||10|
|Web admin interface||Not present||0||Advanced with RO and RW support||10|
|Large AJP packet sizes||8K||5||Larger than 8K||10|
|Compatibility with other app. servers||Works with all HTTP application servers||10||AJP Compatible (Tomcat, Glassfish, etc. …)||5|
|Configuration||Compatible with Apache Httpd configuration file||10||Need separate JK Workers file in .properties format||8|
So now let’s do some stress tests on both mod_jk and mod_proxy. The Installation schema is as described above (one load balancer, two application servers.) On both Apache server hosts, monitoring software from Monitis.com is installed which will check the servers’ health in real time.
We have used Amazon EC2 medium instances for this test. Here are the load test results in both graphical and plain text mode.
Monitoring is implemented using Monitis M3 monitors.
There are 2 monitors used:
apache_monitor – used for apache server’s health check.
http_load monitor - used to check the load time difference during Apache benchmarking.
The mentioned monitors provide useful information which helps to find relationships between various metrics.
The graphic below depicts Apache worker’s status while busy (upper line) and idle (lower line) while benchmarking using
This graph shows Apache busy and idle worker processes on the Apache web server, so we can see that of 150 enabled processes, almost all are busy during the stress test.
Http content load time (time connect, time transfer, time total)
Following is data provided by siege after benchmarking 7 times (using mod_proxy), each time increasing the concurrent users’ number by 100:
|Concurrent conns.||Trans||Elap Time||Data Trans||Resp Time||Trans Rate||Throughput||Concurrent||Failed|
The graphic below represents Apache worker’s busy (upper line) and idle (lower line) status while benchmarking using
This graph shows Apache busy and idle worker processes on the Apache webserver, so we can see that of 150 enabled processes, almost all are busy during the stress test.
Http content load time (time connect, time transfer, time total)
Following is data provided by siege after benchmarking 7 times (using mod_jk), each time increasing the concurrent users number by 100:
|Concurrent conns.||Trans||Elap time||Data Trans||Resp Time||Trans time||Throughput||Concurrent||Failed|
Both mentioned modules, mod_proxy and mod_jk, are used as balancers for backend application servers such as Tomcat and GlassFish. What are the most important features in load balancing? I assumed node failure detection at first, and ease of session stability and load balancing configuration, without requiring any other extra tools or packages. Do not forget about performance, as well.
So what do we have? The resulting tables show that when advanced load balancing or node failure detection is needed, mod_jk is preferable. However, it cannot provide flexibility such as mod_proxy does when configuring (mod_proxy configuration is as easy as Apache configuration and there is no need for separate files like workers.properties) nor for compatibility needs with servers, other than AJP compatibility.
Now a little bit about performance. While the concurrent users count is not so high (in our case: 400), both servers’ behavior is similar, and it seems mod_proxy is able to provide better performance, but things changed as the number of concurrent users grew.
Take a look at this table:
|Concurrent users||Failed requests(10 Seconds Timeout)|
As you see, with an almost equal number of connections, mod_proxy fails approximately 59% more often.
If you have a small project, or need to hide a variety of application servers (Tomcat+Rails+Django), and if you need an easily configurable and fast SSL solution and your server load is not heavy, then use mod_proxy.
But if your goal is to loadbalance Java applications servers, then JK is definitely the better solution.