In my last post on this subject I talked about how where you store your images in Kentico can have a large impact on your site performance. Today I am going to talk about a little problem I mentioned in the last post that can also have a large impact if your storing your images in the CMS tree. It is important to note that this only affects items stored in the CMS (Files, Images, and CSS) and not files that are stored in media libraries (unless you are using permenant URLs to retrieve them), or files stored on the filesystem.
The 304 Not Modified Problem
While I was working one of my recent projects I noticed that even though I had setup caching in Kentico and enabled the CMSFullClientCache key in the web.config that my images were still being requested from the server. The server would dutifuly respond with a "304 Not Modfied" response and the browser would accept this and move on to the next image and the cycle repeated itself. This was puzzling to me because my understanding was that since I had enabled full client caching the browser shouldn't be downloading images (or CSS, etc...) unless they had expired in the browser cache. Since enabling CMSFullClientCache tells Kentico to use expires headers properly in the response, the browser should have had a cached image most of the time. After some sleuthing on the matter I found the culprit; Kentico was not always setting the expires header. This was causing the browser to get into a state where it had the item in cache, but the cache had expired so it was forced to retrieve the item from the server every time. Since it recieved a 304 response it did not refresh the item from the server and thus the cache was neither purged, nor refreshed. Essentially the client wasn't REALLY using it's cache; sure the actual data came from cache but the browser still had to make the request and get the 304 before it could use the image. This was causing slow page builds, "missing" images, and other problems.
Here is the technical walkthrough of what happens in a default Kentico install that causes this problem. This walkthrough was performed with Kentico 5.5 R2 and one of images contained in that install. I used Firebug to capture the response headers for the images below. I chose a 2 minute cache time for demonstration purposes, in practice this would be much higher; example an hour long cache time would allow images that are going to be re-used on the site to be cache by the browser for the duration of most web browsing sessions, but would require that the browser re-download those images for future visits. This is a great way of both maximixing user experience and content freshness.
Notice how the "Expires" and the "Date" values are the same. This tells the browser not to cache this file, it will always go back to the server. This behaviour is expected since the cache settings are at 0 min.
Again you can see that the Expires and Date values are the same. Without CMSFullClientCache turned on the cache settings only control if Kentico will try and re-retrieve the image from the database, it has no effect on the browser cache. This is the expected and desired behaviour.
For this screen capture I changed the view in Firebug so that you can see the raw headers for this request. You can now see here that the Date and Expires headers are not the same, in fact you can see that the expires header is set to exactly 2 minutes in the future. This allows the browser to cache the image for 2 minutes before requesting it from the server again; this is a good thing when this image will be shown more than once per visit to a site.
For this request I turned on a feature in Firebug that lets you see cache responses. Here you can see that the file is greyed out, meaning that it was a cache response, and you can see that the headers match exactly was sent the last time. This is because the browser didn't actually request it at all, it saw that it had a valid item in cache and stopped. If you turn off the Firebug feature that allows you to see this response you actually see no request at all, no matter how many times you refresh the image.
About 2 minutes later I requested the image again. As you can see after the cache expired the browser asked for the file again. You will also notice that in this 304 response there is no "expires" header. Since the server is not sending an expires header with the 304 response the browser now has an expired cache item that it will try and use everytime. No matter how many times you request the image it will now always request it from the server, and will get the 304 response. This issue in this situation is that the browser cache never gets refreshed, and will not get refreshed until either Kentico thinks that the item has changed, or the browsers cache is cleared. Even though it is getting the 304 response the browser still has to make the request, wait on the server, and in many cases wait on Kentico to go check and see if the file has been modified. This can causs poor perceived performance since the users "sees" the image load everytime the browser requests it. If you are using the CMS tree to serve files that make up the structure of your site; such as navigation, avatar images, product images, images stored as attachments, or something similar then your users going to see those items load as the page builds. This can cause builds to look slow, rather than the silky smooth page near instant builds that users have come to expect when browsers are caching items properly.
Some might argue that you should could just set the cache value to be large value and that could mostly eliminate this problem. I would argue against that approach since setting a large value into the cache means that the browser will not download that file again until it has expired, if this file is updated in the mean time then you will have users who are not seeing the latest content on your site. The largest value I set for the caching time is the longest time I am willing too accept that users might have out-dated images (or CSS) on your site. For most of my projects this is about 1 hour, for some 1 day, but rarely does it go longer than that.
I do not feel that leaving a browser with an expired cache item in-definatly is the desired behavour of the "CMSFullClientCache" key so I came up with a solution that I feel more accurately reflects the intended behaviour of this feature.
DISCLAIMER: I am about to show you edits that I made to a built-in Kentico file. I do not warranty what will happen to your site(s) if you make these changes, and I accept no liability for anything that might happen from you doing so. If you are not comfortable making these changes then please do not attempt them. Making these changes requires some level of comfort with .NET code and Visual Studio. In addition since your changing a built-in Kentico file there is a possibility that your changes could be overwritten when you upgrade Kentico. I also believe there is probably a reason why Kentico coded it this way and since I don't understand that reason I could be disabling or tampering with functionality in Kentico that I am just not using. That being said please know that I have submitted this as a bug report in the Kentico forums, and explained this situaiton to Kentico when I attended the Kentico Developers Conference in Prague this year so I imagine that they will improve this in a future version of Kentico.
Since I knew the problem was in the way that Kentico was sending files back to the browser I figured that to fix this problem I needed to edit the code in the CMSPages\GetFile.aspx.cs file as shown below.
This is the file is responsible for processing and sending the vast majority of binary files from Kentico to the browser. After reading through the file and performing some debugging, I found the following lines of code in the file:
Based on my debugging, I determined that this code is responsible for sending the "304 Not Modified" response to the browser. Futher inspection also revealed the following code elsewhere in the file:
Again I used debugging to verify that this code is repsonsible for sending the 200 response with the proper expires header when the CMSFullClientCache key, and the cache settings are configured properly.
I decided that in order to achieve my goal of sending expired headers for 304 responses the easiest way was to modify the part of the file that sends the 304 response to include the expires header to include the code above. The result is below:
The lines I added are noted in the comments starting on line 412 of the file. You can see that all I really did was copy the block of code that checks the cache settings from the 200 response and paste them into the block that handles the 304 response prior to the "return;" statement. Here is the code that I added:
//Added to fix 304 cache handling
DateTime expires = DateTime.Now;
// Send last modified header to allow client caching
Response.Cache.SetLastModified(file.LastModified);
if (!file.IsSecured)
{
Response.Cache.SetCacheability(HttpCacheability.Public);
if (DocumentBase.AllowClientCache() && DocumentBase.UseFullClientCache)
{
expires = DateTime.Now.AddMinutes(CacheHelper.CacheImageMinutes(CurrentSiteName));
}
}
Response.Cache.SetExpires(expires);
//END Added to fix 304 Cache handling
After making this change the resulting response from the server now looks like this:
As you can see here the 304 response now includes an expires header which reset the expire time in the browsers cache and allow it to continue using the cached image without forcing it to be redownloaded. This had a dramatic effect in the percieved performance on the project I was working on. Since during my investigation I found the same issue was happening for CSS files, I went on to make similar changes in the "GetCSS.aspx.cs" file.
I am sure that Kentico will improve this soon, but in the mean time this fix has allowed me to increase the performance of my sites for the end user, hopefully the information here helps you do the same.
This - my first official blog entry- will be about how to store your images and media using Kentico for maximum site responsiveness and perceived performance.
There is quite a bit of information out there currently about how to tweak and tune Kentico performance in addition to tips on code sites so that they perform well. I recommend you read the blog by Kentico on the subject, as well as the very through blog by Brian Soltis. They are excellent sources of information about general Kentico performance.
A perfect example of Kentico's flexibility is in the way that Kentico handles images and media files. You could for instance:
In addition there are other options that affect the way images are loaded / cached both on the server and the client side for you to consider:
Lastly you can have the system check to see if the current user has permissions for the file and/or the file is published before retrieving it.
Each and every option above affects how long it takes an image to be sent to the client browser, and thus how performant your site feels to and end user. I set out to compare these methods side by side to determine which approach offers the best performance. It is worth noting that each approach has positives and negatives that go beyond just performance and it is important to understand these before choosing the approach that works best for you.
Here are the approaches that I tested and the positives and negatives of these approaches.
1) Store the files in the Kentico CMS tree
This method provides the highest level of flexibility for content editors (let's face it images are frequently part of the content of a site). This also allows for the easiest transition between multiple cultures since the files would be considered a document and thus have a different(or the same) version for each culture. The downsides to this approach are that Kentico doesn't like to can't have two files with the same name in the same folder. This defeats a popular method of back-browser compatibility where you would store a newer transparent PNG for modern browsers and a transparent GIF for IE6. Some of the options you can use for performance tuning on this approach are:
Kentico Caching
This is configured in Site Manager under the settings for the web site as show in this screen shot
This setting tells Kentico not to re-retrieve the information from the database unless it has changed since the last time it was retrieved. If
<add key="CMSFullClientCache" value="true"/>
is added to the web.config then Kentico will also send an expires header to the client browser telling it not to re-request the image until the cache is expired. In my opinion there is a flaw in this implementation that I will cover in my next blog. If client caching is not enabled then Kentico will send a "304" response so that at least the browser doesn't have to re-download the file.
Output Caching
This is configured under the properties for the file (or preferably the entire folder of files) in the "General" section near the bottom as show in this screen shot
This setting tells .NET not to re-run the code required to retrieve this image once it has been retrieved the first time, unless the cache is invalidated. Kentico will invalidate the cache once a file has been changed so there is little danger here unless you are not using the Kentico API to update your files in the CMS.
Store Files on Filesystem
This is configured in Site Manager in the Files section as shown below
This setting will tell Kentico to store the files on the disk which should offer slightly better performance in some cases vs files stored on a database. In my experience this setting does not work well in a multi-cultural website where you are using the exact same image in multiple cultures with different data. In this case the first culture that is accessed will write the image to the disk and all other cultures will access this version rather than the correct version. I will caveat this by saying that I have not tested this behavior since Kentico version 4 and it could have well been corrected. Your mileage in this case may vary.
Check if files are published / files permissions
This setting is also configured in the files setting section of Site Manager as shown
This setting will cause Kentico to check every time a file is accessed to determine if that file is currently published, and that the current user has permissions to it respectively. This can be important for some implementations so make sure you understand how your files are being used before you turn off this setting. This is a global setting for the whole site, it would be really nice to see this setting on a folder by folder, or file by file basis.
Redirect files to disk
Once again this setting is configured in the Files section of Site Manager
This setting will cause Kentico to re-direct the browser to the disk based version of the file rather than it's own version. Kentico will re-write these files as they change so again little danger here if your using the Kentico API for everything (as you should be).
2) Media Libraries
This approach allows Kentico to keep meta-data about a file in the CMS system but the file is always stored on the file system. Since the meta-data is in the CMS system these files can be accessed, updated, and linked to using common CMS controls. How to setup a media library is beyond the scope of this blog, but there is lots of good documentation about it on the Kentico documentation website. The downside to using this approach is that media library files are not versioned, they are not culture aware, and I have had problems with using content staging for large files. If you are developing a multi-cultural site then you will need to come up with an effective way of handling using different version of the same file in different cultures. Using different files in each culture, or the exact same files. is not an issue.
Since the files for the media library are stored on the file system there are few options for performance tuning in the media library as the files come directly from IIS, any performance tuning would be done in IIS.
There is one setting to be aware of when using media libraries, "Use permanent URLs" in the "Media libraries" settings section of Site Manager will cause files referenced in a media library to use a "permanent URL". This permanent URL goes through the CMS system; in this case you effectively end up with the same thing as storing files in the CMS tree, but having them stored on disk.
3) Store the files in the codebase
This is the simplest, but also the least flexible of all of the approaches. In this case you simply place the files on the filesystem and allow IIS to serve them. you will not be able to leverage any of the built in Kentico web controls for accessing, or modifying these images so this is the least accessible method for content administrators. This method could be most appropriate for images and files which are part of the structure of the site and should not be routinely modified (layout images, javascript, etc...). My general approach when developing a site on a CMS system is to make as much as possible available in the CMS and then restrict based on permissions and roles rather than create an artificial limitation in the system. For this reason I would tend to shy away from this method entirely, particularly when you consider that you get effectively the same effect using media libraries (files served by IIS directly) while still maintaining some control inside of Kentico.
Note: Any time your deal with files directly on the file system that are being served by IIS, regardless if this is through a media library or through the codebase directly you are limited by the MIME types that IIS is aware of. In IIS6+ the web server will throw a 404 for any file extension that it does not understand, this can cause problems in shared hosting environments, or environments where configuring the IIS MIME types is not possible.
In order to test the performance of these various approaches and various settings I used Firefox 3.6 with Firebug installed. I cleared my cache between each test run and recorded the results from the Firebug Net panel.
To simulate a "cold" Kentico cache, the Kentico cache was cleared and the application was restarted using the System section of Administration in Site Manager. The image that was downloaded was 4.1Kb and is below:
The image was placed in the Kentico CMS tree as well as in the codebase and I created a page where I could review the results side by side to make sure that I was not seeing variance based on network conditions. The page was served by Kentico in order to simulate a real world environment. I performed three test runs per approach I was testing and recorded the results in an Excel file; I then averaged the results to create the final table.
Here are the results, all numbers are times in milliseconds and "Cold" means without Kentico having cached the file yet. The important column here is "Total" which indicates the total amount of time before the browser can "use" the file.
| Type of Load | Waiting | Receiving | Total |
| Static File (IIS / Media Library) | 66 | 34 | 100 |
| Kentico Cold | 339 | 37 | 375 |
| Kentico w/Cache | 191 | 35 | 226 |
| Kentico Cold w/o Permissions Check | 303 | 36 | 339 |
| Kentico Cached w/o Permissions Check | 127 | 44 | 170 |
| Kentico Cold (No Cache) Store on File System | 364 | 37 | 400 |
| Kentico Cached Store on File System | 137 | 36 | 174 |
| Kentico Cold (No Cache) w/o Perms Check Store on FS | 364 | 35 | 399 |
| Kentico Cached w/o Permissions Check Store on File System | 98 | 38 | 136 |
| Kentico Cold (No Cache) Store on File System w/Redirect | 537 | 34 | 571 |
| Kentico Cached Store on File System w/Redirect | 194 | 35 | 228 |
| Kentico Cold (No Cache) w/o Perm Store on FS w/Redirect | 334 | 54 | 388 |
| Kentico Cached w/o Permissions Check Store FS w/Redirect | 211 | 35 | 246 |
Here is the XLS file with the RAW results: Download Kentico File Load Times
Using the "Redirect files to disk" option actually causes the browser to make 2 requests. The first is the request to the original file in the CMS system for which Kentico returns a "301" redirect. The second is the request the the file on the disk, this actually causes a rather unique "double latency" effect and could have a profound impact on the number of requests a browser has to make to load the files for a page. This behavior is show below:
Serving files off the file system, or through media libraries offers the best performance; however it restricts some of the flexibility you get using files in the CMS tree. If you need to store files in the CMS tree then you should disable the permission and published checks if at all possible. If you need to use either of these features in your implementation then I recommend only storing the files where you need to use features in the CMS tree and using the file system or media libraries for the bulk of the files. As always there is no "one size fits all" solution to how to store files in Kentico, however these findings should provide you with the information you need to make educated decisions about your approach and deliver the highest quality experience possible.
