![]() 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. Instead, terminate it on your Front End or Load Balancer (whichever is most appropriate). Our solutions is straightforward: don't terminate SSL within Tomcat. This is especially the case when you have an Enterprise-sized user base on the system. 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. 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. ![]() However, with SSL termination, the way Tomcat handles these objects fundamentally changes. 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. Without SSL TerminationĪpache Tomcat is the only application server supported by Confluence. ![]() 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. 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. 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. ![]()
0 Comments
Leave a Reply. |