Bookmark and Share Share   

Configuring Mashable/Mashup Response Caching

In non-clustered environments, each Mashup Server has a local Response Cache that is disabled by default. In clustered environments, you can continue to use local response caching or you can use distributed caching for the cluster.

Distributed caching requires a third-party cache solution. See the Distributed Response and Artifact Caching for Clusters topic for more information.

You must have Presto administrator permissions to enable response caching.

For response caching to work, you must complete these steps:

  1. Enable response caching for the Mashup Server.

    Response caching configuration for individual mashables or mashups is ignored until a Presto administrator enables the Response Cache for the Mashup Server.

    1. Click Manage > Configure to open the Admin Console.

    2. Expand the Platform Features section and click Caching.

    3. Set the Enable Caching option to turn response caching on.

    4. Click Save.

  2. Configure caching requirements at one or more of the following levels:



    Each level overrides caching configuration at any lower level both to determine whether caching occurs and to set the expiration period for a specific cached response. You can also set a default expiration period. See the Response Caching Example for an illustration of the effects of caching configuration.

    If you want to cache responses in most cases, it is best to enable caching and configure the expiration for entire types of mashables or mashups.Then disable or change expirations for the exceptions individually. See Cache Responses by Default and Disable Exceptions for instructions.

    If you only need to cache responses for specific mashables or mashups, it is best to leave caching disabled for all mashable types and mashups and enable caching only for specific exceptions. See Cache Responses for Exceptions Only for instructions.

    You can also override cache settings for individual requests or responses. See Controlling Response Cache Entries Dynamically for more information.

Cache Responses by Default and Disable Exceptions

This pattern enables response caching for all mashables of one or more types or for all mashups and disables caching only for specific mashables or mashups. You can also use this pattern to enable response caching for individual mashables and disable caching for specific operations.

Only Presto administrators can configure response caching for all mashables of one type or all mashups. Only owners or Presto administrators can configure response caching for a specific mashable or mashup.

Steps:

  1. Enable response caching for all mashables of one type or for all mashups:

    1. Click Manage > Configure to open the Admin Console.

    2. Expand the Platform Features section and click Caching.

    3. If desired, change the Default Maximum Age for response cache entries. This defaults to 5 minutes. Enter a number and/or change the time interval.

    4. Set the caching option for a mashable type or for mashups to enable caching for all mashables of that type or for all mashups.

      For example, to enable caching for all mashups, set the Enable caching for Mashups option.

    5. If desired, set the maximum age for response cache entries for all mashables of this type or for all mashups. Enter a number or change the time interval.

      This default overrides the global default expiration period. Mashables or mashups can inheirit this expiration period or override it.

    6. Enable caching for mashups or other mashable types as desired.

    7. Click Save.

  2. For mashables or mashups that should not have responses cached or that should use a different expiration period:

    1. Use search or browse to find the mashable or mashup you want and open its artifact page.

    2. Click Settings > Cache.

      You can control response caching for all operations for a mashable, for mashups or for specific operations of a mashable as shown in the following example:



    3. To turn response caching off for all operations for this mashable or mashup, set Enable cache to No.

    4. To leave response caching on but change the expiration period for cache entries for all operations of this mashable or mashup, change the Cache expiry from Inherit to a specific value.

    5. If needed, select specific operations and turn response caching on or update their expiration periods in the corresponding operation fields.

    6. Click Close.

Cache Responses for Exceptions Only

With this pattern, you leave response caching disabled for mashable types and all mashups. Then enable response caching only for those artifacts and operations where it is needed.

You must own the mashable or mashup or be a Presto administrator to update response caching configuration for a mashable or mashup.

Steps:

  1. Use search or browse to find the mashable or mashup you want and click it to open its artifact page.

  2. Click Settings > Cache.

  3. Change Enable cache from Inherit to Yes for either:

    • All operations for the mashable or mashup.

    • A specific mashable operation.

  4. If needed, set the expiration period for cache entries for this operation. Change the Cache expiry from Inherit to a specific value.

  5. Update any other operations that should be cached.

  6. Click Close.

Controlling Response Cache Entries Dynamically

You can use HTTP headers in requests or responses to provide individual control of cache entries that override all other cache configuration. This uses the HTTP Cache-Control header.

You can add HTTP headers to requests to run mashables or mashups using Presto Connect or the Presto REST API. To set caching headers in responses, wrap requests to run mashables in a mashup and use EMML statements in the mashup to add the HTTP headers to the response. See Adding HTTP Headers to the Mashup Result for instructions.

Where you add this header and the specific value determines the effect:

Steps:

  • To ensure that the response is no older than a specific number of milliseconds, set one of the following HTTP headers in a request to invoke a mashable or mashup:

    • CACHE-CONTROL: "max-age=number-of-seconds"

    • max-age=number-of-seconds

  • To set the maximum age of a new cache entry created for a specific response, set one of these HTTP headers in the mashable or mashup response:

    • CACHE-CONTROL: "max-age=number-of-seconds"

    • max-age=number-of-seconds

  • To force the Mashup Server to discard the current cache entry and invoke a mashable or mashup, set one of these HTTP headers in the mashable or mashup request:

    • CACHE-CONTROL: no-cache

    • no-cache

  • To ensure the current response is not cached, set one of these HTTP headers in the mashable or mashup response:

    • CACHE-CONTROL: no-cache

    • no-cache

Response Caching Example

The relationship between global, mashable-type and artifact level configuration for response caching provides a wealth of control, but sometimes can be confusing. This example illustrates some common configuration patterns and behavior.

  Event Cache Entry
1.

UserA turns response caching on for a spreadsheet mashable he just registered.

The caching configuration is saved, but no caching will occur because response caching has not been enabled.

2.

A Presto administrator turns response caching on in the Admin Console.

Response caching is now allowed but can occur only for the spreadsheet mashable configured in step 1.

If no caching configuration had been set in step 1, no response caching would occur after this step as both are required for caching to occur.

3.

A Presto administrator turns caching on for all RSS and Atom mashables, but does not configure an expiration period.

UserA adds a block to a mashup in Wires for the Yahoo Financial RSS mashable and previews the results.

The response from Yahoo is cached with an expiration of 5 minutes, taken from the global default expiration period.

4.

The owner of the Yahoo Financial RSS mashable changes the response cache expiration period for this mashable to 1 minute.

Within seconds UserA adds a filter block to his mashup, connects the Yahoo Financial block and previews the result of the filter.

The existing response cache entry for Yahoo Financial is used as the input to the filter block.

This cache entry will remain for the full 5 minutes and then expire. All subsequent responses for the Yahoo Financial mashable will use a 1 minute expiration period.

5.

UserA finishes his mashup and creates a basic App with it. He turns response caching on for his mashup and assigns an expiration period of 15 minutes.

UserB uses this App. Three minutes later, UserC also uses this App.

The mashup is run and caches its response when UserB runs the associated App. The mashup also runs the Yahoo Financial mashable and that response is also cached.

When UserC runs the App three minutes later, the cache entry for Yahoo Financial has expired. The App, however, simply uses the cached mashup response which is based on Yahoo Financial results from three minutes before that may now be considered stale.

6.

A Presto administrator sets the default response caching expiration period for all RSS and Atom mashables to 3 minutes.

As RSS or Atom mashables are run, their responses are cached for 3 minutes, except for Yahoo Financial which is cached for 1 minute.

7.

UserA registers a REST mashable with several operations for the Human Resources system in his organization. To ensure that sensitive information is not cached, he enables caching for the REST mashable as a whole but turns off response caching for two sensitive operations.

When users work with the REST mashable, or any mashup or App based on this mashable, responses will be cached except for those operations where caching has been disabled.

8.

A Presto developer creates a mashup that uses several Atom mashables. In the mashup he adds the HTTP Cache-Control header with a value of no-cache to the response of each of the Atom mashable invocations.

When this mashup is used, each Atom mashable will be invoked every single time with no response caching because of the HTTP response headers.