Recent posts from Scott Farquhar

Back in July last year (how time flies), I investigated how we could use caching in our products to improve the user experience. This resulting in creating a framework for serving content that can be cached on the client. We now use this for JIRA, Confluence and Bamboo.

The idea is that some resources (css, images, javascript), never change between releases, and so we add 'caching headers' to say cache it forever. You can see how we have achieved that by using on the online services:

Test caching for Bamboo

However, when browsing certain sites like http://support.atlassian.com - these sites still felt very slow.

It turns out that SSL was the culprit! By default, firefox does not cache SSL content on disk, regardless of what the caching headers say. There is a property called browser.cache.disk_cache_ssl which by default if 'false'. Meaning that all content is cached in memory.

Turns out that Firefox also allows you to see what is in your browser's cache - type 'about:cache' into the location bar. With that property set, no https site will have anything in the memory cache.

Because the memory cache is so much smaller than the disk cache, the javascript and css etc will be pushed out much sooner than if it was on disk.

Turns out that Internet Explorer caches things to disk (correctly observing the caching headers), and there is an open bug for firefox: Change browser.cache.disk_cache_ssl default to true.

Note that if you do manually change the value to true, beware of this bug: mixed http/https warnings after enabling browser.cache.disk_cache_ssl.

Note that if you go through the proxy server, you probably won't see the slowness as much, as they will be cached by the proxy server.

Update: - this is now fixed in Firefox 3 if you set the Cache-control header to public. We will be updating all our applications shortly

I was going to write a long post about how fantastic Contegix is for java hosting, but I think that this email exchange pretty much says it all:

On Apr 22, 2006, at 12:09 AM, matthew.porter@contegix.com wrote:
 
Charles:
After multiple attempts to restart the javablogs.com system for the past 1 
hour, 18 minutes, we are unable to keep the system alive.  Within minutes 
of the site starting, it begins to throw OOMEs.
 
I have attempted to contact someone via phone at all none numbers, 
including office and mobile numbers with no success.
 
We have currently activated the maintenance page until the problem 
can be resolved.
 
I am still working on the problem and will update you with any progress.
 
Matthew
 
---
Matthew E. Porter
Contegix LLC
"Beyond Managed Hosting For Your Enterprise"

And then a few hours later, still not being able to contact Atlassian:

> On Sat, Apr 22, 2006 at 02:44:11AM -0500, Contegix Support wrote:
>> Charles:
>>    Well, desperate times call for desperate measures.  :-)
>>
>>    With the site repeatedly spiraling out of control and not being
>> able to find any way to keep it running and responsive, we decided
>> that it was as good of a time as any to go forward with the long
>> discussed plan of moving the database to the consolidated postgresql
>> 8.1 server on atlassian07 (athena).  With the maintenance page up and
>> the service stopped, we dumped the database, imported it into the new
>> database, and adjusted the javablogsContext.xml and data-sources.xml
>> files accordingly (preserving backup copies of the originals just in
>> case).
>>
>>    So far, so good.  The site has been up and running since 02:05 CDT
>> and has been nice and quick from the start.  With the load of the
>> database now off of the server, the max heap for javablogs could most
>> likely be bumped up a bit now if deemed necessary, but I opted for
>> taking one step (albeit a rather large one) at a time.
>>
>>    I hope that it was acceptable to have taken such drastic steps,
>> but we had reached a point where there was nothing else left to try
>> and wanted to do what we could to get the site back up and running.
>> Let us know if you have any questions or concerns.
>>
>> Cheers,
>> -craig

Now - can your managed hosting company do this?

Firstly - if you distribute server-side Java applications, then this URL will make your life a lot easier: http://java.sun.com/j2se/1.5.0/jdk/download.jsp. If that doesn't mean anything to you, read on...

As most Java programmers are aware, there are two distributions of Java from Sun. The Java Runtime Environment (JRE), and the Java Development Kit (JDK). The first one allows you to run Java programs, and the second also allows you to run programs, but also contains (amongst other things), tools to allow you to compile Java programs.

One barrier to Java's adoption on the client side has been getting the runtime environment installed on every computer. Whilst Apple ships a JRE with every computer, users of Linux and Windows have to download Java themselves.

For many years, Sun made downloading the JRE ridiculously hard. One reason that Macromedia's Flash has become the predominant language for writing rich web applications is that it is trivial to download and install. Contrast this to finding the JRE, downloading it, installing it, and adding it as a browser plugin for each browser that I use. On Linux I still don't have the JRE linked properly to the Firefox browser I am using to write this post.

In the last couple of years, Sun have realised the error of their ways, and have created http://java.com/, an easy way of downloading the JRE.

However, All is not so rosy over in server-side Java land. We all know that the main server-side Java language Java Server Pages get compiled using Java's compiler, which means that all JSP applications (until recently, when Tomcat shipped the eclipse compiler with 5.5) needed access to a compiler. Sun's licensing model prohibits a vendor from shipping the JDK with their application.

Ok - let's send our users over to http://java.sun.com/j2se/1.5.0/download.jsp to download the JDK. Take a quick peek at that page. Half our users download the Netbeans bundle, and half download the J2EE bundle. Finding the JDK was even harder last year, when for a few months, the renamed it to be called the SDK instead.

Late last year, I ran into Martin Hardee - whose title was 'Director of Web Experience' at Sun. "Fantastic", I thought to myself, someone who can do something. So, like a late Christmas present, I received an email from the web team at Sun today:

Happy New Year!

The J2SE team liked your recommendation of creating the redirect.

You can now go directly to http://java.sun.com/j2se/1.5.0/jdk/download.jsp

Thanks for your feedback,
Kenny Mikami

So - if you create server-side applications, you can now direct your clients to a URL to download the JDK directly!