HOWTO: serve jpeg2000 images with a scalable infrastructure

, so here I’ll cover my rationale and decisions I made to provide a scalable, stable infrastructure to provide the images as efficiently as possible.

When I started sketching out how I wanted to run djatoka, I knew I wanted it to provide security, caching for performance and scalability and fault tolerance. Our server runs Tomcat, which I didn’t want to be public facing. Because of this I proxy Tomcat requests through Apache with the use of ajp_proxy, the successor to the old mod_jk. Initially I was using nginx in place of Apache, but after reading about all the functionality and performance improvements ajp_proxy offered, it was a no brainier; this is how to present Tomcat in a production environment.


Caching for performance and scalability


Click for larger image

Fault tolerance

Roadmap / Code / Enhancements


We’re very excited to be one of the early adopters of djatoka, and thus far are very encouraged by it’s ability and stability. We now have a secure solution with multiple layers of defense against hostile traffic, our scaling problems are now a thing of the past, with caching and fault tolerance allowing multiple,flexible paths as we look to expand our operations. The CPU usage on the server is very light, giving us plenty of headroom, as seen form the following graph, where red and green represent system and user load respectively, and yellow being idle:

Meanwhile, server load shows a similar pattern, with a similar amount of headroom; it’s going to take a lot more traffic for this server to be straining for any reason.


As always, I enjoy feedback and am happy to answer questions and give further advice if needed. Leave a comment below or drop me a line at work.

Phil Cryer, BHL Developer phil.cryer (at)


Reblog this post [with Zemanta]