Dealing with Confluence and SSL termination issues

Caching at web browser and reverse proxy level is especially useful for optimising the delivery of static content in your Confluence instance CSS, JavaScript and images, for example. However, terminating SSL on Tomcat can cause serious issues with the way this content is cached and can result in extreme unnecessary load and poor response times.

In this post the final in my recent series of things I wish I'd known about Confluence when I started using it I want to show how you can avoid this problem and ensure optimum caching efficiency.

Without SSL Termination

Apache Tomcat is the only application server supported by Confluence. Without SSL termination, it does exactly as you'd expect to static content: it marks it as cache-able and caches it at either web browser or reverse proxy level. However, with SSL termination, the way Tomcat handles these objects fundamentally changes.

With SSL Termination

The Atlassian documentation recommends that to terminate SSL on Tomcat you should perform a particular set of steps, the unfortunate result of which is that static content is marked as uncacheable. Since they are prevented from being cached at any level, each and every request for such content makes it all the way over to the Java process itself, so the application workload is typically increased exponentially. This is especially the case when you have an Enterprise-sized user base on the system.

What are my recommendations?

Our solutions is straightforward: don't terminate SSL within Tomcat. Instead, terminate it on your Front End or Load Balancer (whichever is most appropriate). It can also be useful to know that in some instances, where larger amounts of SSL needs decryption, hardware SSL terminators can be quicker than Apache. Make sure you consider this option too.

For more information on Confluence and SSL termination issues and how Adaptavist can help you tune your Atlassian applications for peak performance, contact us today.