INTRODUCTION

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.

HOW TO

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

1. Request comes to Apache
2. Apache proxies it via HTTP to downstream Tomcat to port 8080
3. Tomcat sends response to Apache via HTTP
4. Apache delivers content to User’s browser

Well, so what are the pros and cons of this situation? We will provide some comparison tables below, but in general:

Pros:

1. Easy and quick to configure
2. Works for all downstream application servers

Cons:

1. We do not have sticky sessions: if a user logs in to Tomcat1 and sends another request it will most likely go to Tomcat2 and the user will get a session expired error.
2. mod_proxy does not support failover detection, so it will continue to send requests to downstream Tomcat even if it is down.
3. Some Java applications exhibit unpredictable behavior when they are under a proxy environment. (From my experience, Atlassian Bamboo and Fisheye server’s progress bars stalled on several pages, but this was corrected by moving to JK; I have heard about other strange problems as well. )

Now let’s see Situation 2, where we use JK for downstream servers:

A REAL LIFE EXAMPLE

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:

1. User opens http://www.yourdomain.com in their browser
2. Request comes to Apache
3. Apache proxies it via AJP 13 to downstream Tomcat to the port 8009
4. Tomcat sends response to Apache via AJP
5. Apache receives AJP and delivers content to Users browser via HTTP

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:

Pros:

1. After a little tweaking we can have sticky sessions just by adding sticky_session=True on Apache and jvmRoute=”NODENAME” on the Tomcat sides. After this, users who are logged in to Tomcat1 will never be dropped to Tomcat2 until Tomcat1 is alive. (Actually you can Use Membase or Memcached as session store so users will never lose their session until it expires normally)
2. We have node failure detection, so if Tomcat1 fails, Apache will not send requests to it until it detects that it is back.
3. JK configuration is much more advanced than that of mod_proxy and allows lots of tweaking, which will result in better performance and make the environment work just as you need it to.
4. JK has a web admin tool that allows you to decommission, suspend and play with the LB factor in real time.

Cons:

1. So far I have found only one bad thing: it is a little harder to configure, so it required some administrator skills.

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:

1. User does DNS request, gets ip address of one of the Varnish servers and the Static content server/s (NGINX).
2. NGINX delivers content directly.
3. Varnish caches whatever needs to be cached and sends request downstream to one of the Apaches.
4. Apache gets JSESSIONID and forwards request via JK to the required Tomcat server or does balance if user does not have cookie.
5. Tomcat servers keep sessions in local RAM and copy in Membase cluster (so even if one Tomcat fails another can retrieve its session from Membase ). Membase is clustered memcache so it is fault tolerant by nature (we will have a closer look at Membase in another article).
6. Tomcat does needed application logic, (retrieves information from Hadoop/HBase database, etc.) and responds to Apache.
7. Apache sends response back to Varnish.
8. Varnish updates cache if needed and does delivery to client.

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.

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.

mod_proxy:

The graphic below depicts Apache worker’s status while busy (upper line) and idle (lower line) while benchmarking using

mod_proxy balancer.

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:

mod_jk:

The graphic below represents Apache worker’s busy (upper line) and idle (lower line) status while benchmarking using

mod_jk.

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:

CONCLUSION

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:

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.