Back in the R4 days (at Nokia) I was reading quietly in my cube about server performance, I read where there is no mystical ServerGoFaster=1 ini value, I about fell out of my chair laughing at the sillyness.

So, when asked that question now, "how do I performance tune my server?"  I've been passing along that sage wisdom, "there is no mystical ServerGoFaster=1 ini value"

Imagine my surprise when a setting just about that easy showed up.

OK, I might have overstated a little, but, It was a pretty easy setting.  Alright, I might have overstated a lot, but, I was still very impressed.

Chris Brandlehner has a pretty extensive writeup here and thats where I found out about it as well as how to test for effectiveness.

So, Im just going to do the short version here.

Under normal web conditions, when you visit a page, the server responds with the page and some header information, when you go to that page again, your client tells the server what version of the page it has in cache and if there is no update, the server sends back a response of "304" wich means, "you already have the current version"   This handshaking is very fast and the 304 messages are very, very small.

What Chris's page describes is how to set the header information to tell the browser in advance when it sends the first response that the page will be good until a certain date, so, the next time the page is needed it does not even ask the server, because it knows that the cached version is good.

This is especially good for pages that are known to not change /icons/* for instance, how about database.nsf/archive/*.

Heres how to implement.

Go to your sites view in the address book (er directory), select your site & create a Web Site Rule of type "HTTP response headers"

Add your server criteria, definitely the /icons/*

Add 304 to the list of supported response codes

Enter the Expires header "Add Header Only if an application did not"

and for the purposes of testing add 30 days. From the server console "tell http refresh config"

This is especially important when using the fckedit editor because of the large volume of image that get loaded over and over again, and they never change.

Thanks Chris!

No documents found