This is a follow up to the previous Clearing output cache in a multi server environment article. Before adding code to clear more caches, it may be useful to check whether the page is actually being rendered. Here is a small debugging example for Optimizely 11 running on ASP.NET MVC.
Say that an editor changes a heading and publishes the page. The new value is available when you inspect the published content, but an anonymous request to the page still returns the old heading. Restarting the application makes it work again. So far, this does not tell us very much about which cache was responsible.
A reasonable start is a breakpoint or log entry in the controller action. Make the request using the same hostname and language as the visitor, rather than through edit mode. Also check the document response in the browser’s Network tab, to make sure the old heading is actually in the HTML and not added afterwards by Javascript.
The following can be placed inside the existing controller action in a test environment. It adds the render time and machine name to the response headers, making them easy to inspect in the browser.
Response.Headers["X-Debug-Rendered-At"] =
System.DateTime.UtcNow.ToString("O");
Response.Headers["X-Debug-Rendered-By"] =
System.Environment.MachineName;
Request the page, publish another change, and request it again. If the timestamp stays the same and the action is not reached, something is returning the previous response. Disable the browser cache while the developer tools are open and try again. If that makes no difference, check server-side output caching and any reverse proxy or CDN in front of the site.
Note that the diagnostic headers can be cached too. The machine name tells you where the response was originally rendered, not necessarily which server received the latest request. Use the application logs to confirm that part, and remove the headers when you are done.
Optimizely’s content object cache and output cache are separate things. Loading a fresh content object will not help a request which is answered with previously rendered HTML before your controller gets to run.
If the action does run, inspect the heading it puts in the view model. An old value there means you need to follow the content loading or your own caching code instead. A new value there, followed by old HTML, means there is more to check in the rendering path, such as a cached child action. There is little point in clearing the content cache if the controller already has the right value.
In a multi server installation, repeat the test against each instance while preserving the site’s hostname. If only one instance keeps returning the old response, check whether the expected invalidation reaches it. See Acting on Optimizely Remote Events and the output cache article linked above for that part.
Once you have found the stale cache entry, clear that specific item and repeat the request. Then publish one more change without clearing anything manually. That is the test which tells you whether the problem is actually fixed.