LDN - Luminis Developer Network

Here at the University of Ottawa, we did some calculations on the footprint of our Luminis page loads and we noticed that our average page load was just around 683KB with an empty cache (we've added a lot of new images, JavaScript and styles to Luminis). We did some calculations and we figured out that with an average of 4 page loads per minute under our max load of 10 000 concurrent users, we'd be pumping out just over 20GB of data per minute on the University network. Sufficed to say that scared us a little.

However, with a few tweaks here and there we were able to drop our average load to just around 250KB (that number should shrink even further with a few other tricks I have up my sleeve ;-) Here's what we did.

(Just a side note, I'd recommend installing Firebug in Firefox and then adding YSlow as well. A great way to measure just how much of a difference these changes are making)

1) Optimize your PNG files

If you don't need a full 32 bit PNG image, don't use a 32 bit PNG image, use a 24 bit image. In fact, with simple images, sometimes you can even drop down to an 8 bit PNG. You can use the latest version of Paint.NET or Photoshop's "Save for Web" feature to save your images in the smallest format possible. In Paint.NET, just click on "Save As..." and select the PNG type that generates the smallest image file size without compromising image quality. Photoshop's "Save for Web" gives you more control over this (but costs a lot more than free ;-)

2) Image Maps or Sprite Sheets

This was mentioned at the Sungard Summit during a presentation (I can't remember which University it was, if you're reading this please add a comment below to properly give yourselves credit for a great idea). Basically, concatenate as many of your smaller (and sometimes larger images) into single files and use the "background-position" CSS property to set which part of the image to display. This minimizes the number of HTTP requests sent in and out. Each HTTP request contains some extra data about the request which takes up space within the packets of data. If you make one request instead of five, then you don't send that extra info over and over again. It's only a few dozen to a few hundred bytes per request but it can add up pretty quickly.

3) GZip

This was a tricky one to pull off. When I contacted Sungard about this, they said flat out that GZip wasn't supported with Luminis. So keep that in mind when doing this, Sungard won't be helping you out if you run into problems. Also, if you run your portal behind a reverse proxy, GZip data has been known to have issues with that type of setup. So keep that in mind as well.

For those still reading, here's what you do. (I've copied and pasted from our wiki, keep in mind that your directories may or may not be on the D: drive, or not even on windows for that matter, but you should be able to figure it out)

Add the "jspbook.jar" file found on http://www.onjava.com/pub/a/onjava/2003/11/19/filters.html to

D:\luminis\products\tomcat\tomcat-cp\server\lib\
D:\luminis\webapps\luminis\WEB-INF\lib

I don't know why it needs to be in both, but I was getting intermittent errors if it was in only the tomcat-cp directory. Just add it to both, doesn't really hurt anything.

Look for this web.xml file in

D:\luminis\webapps\luminis\WEB-INF

Change the "web.xml" file to include the following just above the section for the mime types

(See Appendix 1, couldn't get the browser to render the XML properly)

You can change those patterns as you like but that worked out best for us. Remember, don't GZip images or PDF files. They're already compressed and doing so can cause problems with rendering or reading the file data.

DO NOT DUPLICATE URL PATTERNS IN WEB.XML FILES this will double compress files and the browser will display gibberish

Restart your tomcat server and you're good to go. You can test your results using YSlow (an add-on for the Firebug add-on for Firefox)

4) Cache Control

Yet another jar file addition and filter setting. This time, I've included the compiled JAR file (since only the source code was available online and it took me about 30 minutes to get Eclipse to compile it properly). You'll have to rename the file to a .jar since Lumdev won't let me upload a .jar file. Remember, don't extract the ZIP, just rename to .JAR

Here's where I got the source from

http://www.jguru.com/faq/view.jsp?EID=1311010

Add the "cachefilter.jar" file to both

D:\luminis\products\tomcat\tomcat-cp\server\lib\
D:\luminis\webapps\luminis\WEB-INF\lib\

(Same reason as before for having to install in both directories)

To "web.xml" found in

D:\luminis\webapps\luminis\WEB-INF\

and add the following code

(See Appendix 2, couldn't get the browser to render the XML properly)

Now I highly recommend that you tailor the cache settings to your specific setup. This is set on a Dev server which is strictly for testing the page load optimizations I've been doing. In production, I would imagine that our JavaScript files wouldn't be cached as long as the images and css files. So feel free to play around.

5) Minify JavaScript/CSS

Found this website (http://compressor.ebiene.de/) and ran all my CSS and JavaScript through it. I got an average savings of around 30% per file. Most of the time the "Powerful Compress" didn't work (javascript and/or CSS failed to be interpreted properly by the browser) but I found that the difference between basic and powerful was around only 3 or 4% per file. So you aren't losing much by sticking with the Basic minification.

BE SURE TO KEEP A COPY OF THE ORIGINAL JAVASCRIPT AND CSS FILES. They'll become unreadable after doing this so keep another folder somewhere with your originals and/or development files.

Well that's about all I've got for today, feel free to add to the list of optimizations in the comments. Hope this helps out a few of you out there.

Thanks,

Mathew Winstone
Web Analyst
University of Ottawa
mwinstone@uottawa.ca