Users see stale content in ProxySG deployment

Products

• ProxySG Software - SGOS

Issue/Introduction

Users see stale website content in a ProxySG deployment.

Resolution

The ProxySG appliance uses an algorithm to determine if an object should be served directly from cache, or revalidated with the OCS (Origin Content Server) to make sure the content is up to date (fresh). The more often an object is accessed, the more often the ProxySG will go check against the OCS to make sure the cached copy is up to date. Object that are rarely accessed are not automatically refreshed so it's possible that they will be returned from cache even if the OCS has a newer version of that object.

There are ways to reduce the odds that a stale object will be returned from cache. This does require checking more often with the OCS so it increases WAN traffic and has a slight performance impact but it is sometimes necessary to tweak the default cache behavior for sites that do update their content very often. 

Never serve after expiration (Configuration > Proxy Settings > HTTP Proxy > Acceleration Profile)

This option is disabled by default, which means the proxy will serve objects after expiration. The reason this option is disabled by default is because not every web server on the internet sets reasonable values for the expiration date of an object. Some servers might make every object expired right after serving them while other servers might stamp object valid for years. Enabling this option will force the proxy to revalidate the object according to the expiration date set by the server. This option is global and can't be configured via CPL or VPM.

Always check with source before serving objects (Configuration > Services > HTTP Proxy > Policies)

Disabled by default, this option would guarantee that a stale object isn't served from cache, but it comes at the cost of a big performance impact. It means that for every client request, the proxy has to check with the OCS and make sure the object is up to date (via a GET IMS request). Enabling this option is not recommended since the same behavior can be configured via policy and made very specific to a domain.

To force the proxy to always verify with the source, a Web Content layer can be created where the destination could be a URL and the action would be Always Verify. It is also possible to use CPL and get the same result. If, for example, mydomain.com needs to be verified at every access, this CPL code can be added to the local policy file:

<Cache>
    url.domain="mydomain.com" always_verify(yes)   

 

Do not cache

The option to not cache objects can be set via the VPM (Visual Policy Manager) or via CPL. This option simply tells the proxy that the objects are non-cacheable and are not to be saved to disk. Using 'do not cache' is rarely necessary and should be used as last resort. It is far better to use the 'Always verify' option than not to cache objects at all. Here is a CPL example on how not to cache objects from mydomain.com:

<Cache>
    url.domain="mydomain.com" cache(no)