XslGenerator Cache

This is a sub-article of the XslGenerator.

Overview

If XslGenerator's Xml Data Source is from the DynamicXmlBuilder or from a web service, you may choose to configure the XslGenerator definition to save the XML file on the web server for faster access. You can set a refresh rate so that the data will be regenerated on an interval of every 10 minutes, 60 minutes, 24 hours, or whatever setting is appropriate.

The files will be stored in the \eweb\temp\Cache\xml\ sub-folder on the eWeb web server. Note that in 2006.02 and onward, the files are stored in \root\CacheRoot\Cache\xml. When anyone runs the clear cache process, all these files are deleted and they will be start regenerating when called on.

Setting this property will make pages load faster, reduce network traffic and tax the SQL Server less, but at the cost of serving real-time data.

Suppose, for example, you have a page that outputs a trade show exhibitor directory, and that it takes several seconds to run the SQL stored procedure and return the data over the network. If you have thousands of users accessing this page every day, then the network traffic and SQL server resource cost can be considerable. If this page can be cached and regenerated every 60 minutes, then the stored procedure will only need to fire at most 24 times per day (once per hour). The data on each page will not be 100% real time, but if this compromise is acceptable, the pages will load much faster and the SQL Server will be taxed less.

Suppose the exhibitor listing has a drill-down link to an exhibitor detail page. If you have hundreds of exhibitors, then you probably do NOT want to enable caching on the drill down page, as it might be more important to serve this data real time, and also because the likelihood of getting multiple page hits within the same caching window is not as likely. Plus, a single drill down page can usually load faster as there is probably less data to return.

See XslGenerator Cache Before and After for a dramatic "before and after" example of the SQL command that fire with and without caching.

How to Enable Caching

To enable caching of a page, enter this in the page detail definition, where n is the value in minutes: 

{BeginCacheDurationMinutes}n{EndCacheDurationMinutes}

If you want pages to cache for one hour, enter this: 

{BeginCacheDurationMinutes}60{EndCacheDurationMinutes}

Regenerating a Cached Page

If you have a cached page that you need to regenerate right away, you can navigate to that page and then add the following to the end of the URL address: 

&cache=no

and then reload the page. This will cause the XML source to be regenerated at once. Adding this querystring to the URL address has the effect of temporarily setting the cache duration to one minute, which essentially ensures that the next time the page is loaded, the page will be refreshed. (Theoretically, if the page had been reloaded two seconds earlier, then you would need to wait 58 seconds.)

If this page can accept a variety of parameters, then you would need to do this step for every possible combination of parameters. If this is impractical, then you could either turn off caching on that page, or you can go to the web server and delete the files stored in the Cache folder or clear cache.

When and When Not to Cache

Please note that this setting is not appropriate for pages that serve content dynamically based on wildly variable querystring parameters or user searches. For example, a searchable member directory should not be cached because each search could have different search terms. Caching is only appropriate for pages that serve the same content every hit, or if there are only a few parameters that accept a limited number of values.

For example, suppose you have ten committees. You might have a committee listing page, with each committee hyperlinked to a drill-down dynamic committee roster page. In this case, it could make sense to cache these pages. The web server will actually cache one version of the committee listing page, and then one version for each committee listing page, for a total of eleven cached pages. If the committee roster page had a drill-down hyperlink to a page for each committee member, then it might make sense for that page to be real-time as this is not likely to be a page that is accessed frequently.

Another example is a member directory that allows the user to search on Zip code. This page should NOT be cached. The caching engine saves the results based on search parameters, and given that users will search on every possible zip code, there is very little value to be gained in caching this data. Even if you set the refresh rate at 24 hours, is it unlikely that you will be having many searches on the same zip code within the same 24 hour period, so the caching engine will need to rebuild the file anyway.

Arguments in Favor of Caching

In summary, the choice of whether to enable caching will depend on whether you can answer yes to most or all of these:

  • Your XML web service is an RSS feed -- then you MUST cache! It is poor form for aggregators to not to cache RSS feeds; moveover, it is a huge perfomance killer as the web server will be calling the same RSS feed over and over every time the page loads, even though this feed might be updated only once a day.
  • Displaying real-time data is not essential
  • The data is used to generate menus or links that do not change frequently if at all
  • The data does not change very much, making it acceptable to show a small amount of data that is potentially out of date
  • There is a large amount of data to return from the SQL Server or the SQL Server query/SP is slow to return data
  • You are displaying hierarchical data that required many return trips to the SQL Server
  • The emphasis of the page is passively viewing data, not manipulating data

Scenarios that Rule Out Caching

If the answer to any of these is yes, then do NOT cache the page:

  • The data must be real time
  • The user is manipulating this data and will want to see the adjusted data right away after saving changes
  • The page has wildly variable parameter values (such as a member directory search with search values for name, zip, city, etc.) that influence the data being returned; in this scenario caching a file is pointless because there could ultimately be infinite numbers of files, one for each combination of parameter values.

Troubleshooting

Q. The page does not seem to cache.

A. Ensure that the "anonymous user" has write access to cache subfolder. You might have to just create the subfolder manually if it does not exist.

Q. I have thousands of XML files eating up space in my "cache" folder.

A. The clear cache tool will delete these.