Caching

From SpinetiX Support Wiki

(Redirected from Cache)
Jump to: navigation, search

This page is about remote resource caching. For data caching, see data feed caching.

Introduction

The HMP has a built-in caching mechanism that is designated to avoid excessive network traffic and to save bandwidth, meaning that whenever a remote resource needs to be displayed, the HMP first checks if that resource is already in its local cache. For instance, if inside your project, an image located on a remote web server needs to be displayed every 30 seconds, the HMP will not download that image each time - instead it will use the copy of the image stored in its local cache.

Process

First, some details about how a resource is cached:

  • actively cached = the resource was added to cache and the caching period has not ended.
  • passively cached = the resource was added to cache and the caching period has ended.


The process:

  • When the HMP requests the first time a resource (media files, data / feed sources etc.) from a remote web server, it also adds that resource to its local cache, if not instructed otherwise.
    • The caching duration depends on the remote web server configuration, nevertheless the active caching duration is determined and set by the HMP between ten seconds (10s) and two hours (7200s). The caching duration is accurate if the web server is returning the proper HTTP headers.
    • More details about caching periods can be found in the resources.log / player.log.
    • Any resource not used by the player is removed from cache after maximum 24 hours.
  • If the resource is actively cached, then the HMP displays it from its local cache.
  • If the resource is passively cached, then the HMP sends an HTTP HEAD request to determine whether the resource has been changed on the server side.
    • If the result is positive, then it sends an HTTP GET request to retrieve the new version of that resource and updates its cache. The resource is actively cached again.
    • If the result is negative or the remote server cannot be contacted, then the HMP continues to use the resource from its cache. The resource remains passively cached.

Update delay

The most common problem related to caching, is the delay in updating the cache on the HMP after the resource has been updated on the remote web server.

  • During this delay, that can last up to two hours, the HMP displays the version that is stored in its local cache.
  • This is due to improper HTTP headers (or the lack of them) returned by the remote web server.
  • You can use the LiveHTTPHeaders add-on for Firefox to verify the returned HTTP headers.
    1. Open a remote resource (for instance an image, a video or a xml file) inside your Firefox browser several times with and without updating the file on the server.
    2. Note each time the HTTP headers returned by the web server.
    3. Verify if the HTTP headers are properly modified or left unmodified.

It is recommended to ensure that the proper HTTP headers are returned by the remote web server, but if you don't have access to the remote web server configuration, then "force" the HMP to check the server after a fixed amount of time using the spx:cacheMaxAge attribute, the GETURL_ALWAYS_CHECK flag or not to use the caching mechanism at all.

  • The spx:cacheMaxAge attribute works only on remote files - using it on a local file does not have any effect.

HTTP headers

The HMP is using the following HTTP headers returned by the remote web server: Cache-Control, Last-Modified and ETag.

The player uses the Cache-Control: max-age directive to determine how long to wait before checking if the resource has been modified on the web server.

  • If the max-age directive is not found in the response header, the player computes a caching time depending on the Last-Modified directive. If the document has been modified recently, it will be cached for a short period of time, otherwise it will be cached for a longer one.
  • If the Last-Modified directive is not present, then the HMP starts by caching the document for a short period of time and, if the document remains unmodified, then the caching period increases.

Once the caching time has expired, the player sends a HEAD request to determine on its own whether the content has changed.

  • If the server has provided an ETag directive, then the player sends a HEAD request together with the If-None-Match directive. Otherwise the player sends a HEAD request together with the If-Modified-Since directive, where the modification date is either the Last-Modified date (if it was returned by the server) or the last time the document was downloaded.
  • If the server returns 304 Not Modified, the file is considered as still valid and therefore it will be checked again next time the cache expires. If the server returns 200 OK, the (new) file is downloaded.
  • If the ETag returned by the server is misreporting the state of the file, the player will ignore future server directives about that file and it will switch to checking periodically (every 10 minutes) whether the file has been changed (by downloading it and running an MD5 check).


Note Notes:
  • For effective Bandwidth management, especially when using 3G modems, you should ensure all remote resources are served with an ETag to avoid unnecessary traffic.
  • ASX files for streaming are cached differently, see Streaming for more details.
  • When creating php scripts to server data to the HMP make sure that a valid set of headers are sent, and that the script is capable of handling HEAD request with "If-None-Match" directives.
  • For IIS7, see also clientCache page.

Example

A web server might provide some content that should expire after 20 minutes - in that case, the server response would be something like this: 

HTTP/1.1 200 OK
Date: Thu, 19 Nov 2009 08:43:52 GMT
Cache-Control: max-age=1200
Expires: Thu, 19 Nov 2009 09:03:52 GMT
Vary: Accept-Encoding
Content-Type: text/xml;charset=UTF-8
Age: 0
Connection: close
Server: YTS/1.17.22

The directive "max-age=1200" above makes the cached content expire after 20 minutes. After that period, the player sends a HEAD request to determine whether the content has changed - if it did, it issues a GET request for the content, otherwise it continues playing the content from the cache, up to a maximum time of 24 hours.

Disable caching

The player cache is designed to save bandwidth and it should be used as much as possible. However, there may be some scenarios where you want to deliberately avoid the cache (for example, when timely information might be displayed incorrectly). In order to do this, you need to use one of the following methods:

  • For remote media elements (video, image, etc.), use the spx:cacheMaxAge attribute and set its value to 0.
  • For remote files retrieved using JavaScript code, you can use a unique query string on the resource URI each time it's invoked, or call jSignage.ajax() with the "cache" parameter set to "false", or the getURL() method without any flags.
  • For legacy HMD news templates, see how to set no caching.
Retrieved from "https://support.spinetix.com/w/index.php?title=Caching&oldid=18510"
This page was last modified on 14 November 2023, at 16:00.