This documentation is for WSO2 Data Services Server 3.1.0. View the home page of the latest release.

Unknown macro: {next_previous_link3}
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Caching stores responses for requests that are identical and therefore enhances the response times for subsequent requests. When caching is enabled, subsequent requests with the same hash value as the previous request whose response was cached, will be served with the same cached response.

Caching can be enabled at three levels as follows:

It is advisable to consider the dynamic nature of your services before enabling caching globally. For example, an operation that generates random numbers might not benefit by caching previous responses, because it generates a unique response for each invocation anyway.

Service-level response caching

Follow the steps below to add response caching to a service. 

  1. Log in to the management console and select Services > List under the Main menu. 
  2. From the Deployed Services page that appears, click the service to which you want to enable caching. 
  3. The service's dashboard opens. Click Response Caching from the Quality of Service Configuration panel. 
  4. Enable caching to the service by selecting Yes. 
  5. Change the default caching configuration settings as you need.

    The options of the above window are as follows:

    • Hash Generator : Specifies the fully qualified class name of the hash value generator. This class implements the org.wso2.caching.digest.DigestGenerator interface. It is responsible for generating a Hash value for each request message, so that a matching response message can be located from the cache. The default is org.wso2.caching.digest.DOMHASHGenerator. You can implement your own Hash generator class and use it with the WSO2 products. However, the default hash generator is enough for general use.
    • Timeout : Shows the time period, in milliseconds, during which a cached response is kept in memory. The counting starts from the time the first request is received. Any request received after the counter has started and is within the Timeout period is served with the response cached upon receiving the first request. Once the Timeout expires, the cache will be updated with the response generated for the first request that was received after the expiry.
    • Maximum Cache Size : Holds the maximum number of response messages that are cached. If the maximum number of responses are already cached and none of the cached responses' Timeouts have expired, then future responses are not cached until this memory is free enough to accommodate a new response.
    • Maximum Message Size : Shows the response message that is cached. Response messages larger than this (in size) are not cached. Caching is an expensive operation for larger messages, especially given the amount of memory required. Therefore, this value should be set considering the performance and resource trade-offs.
  6. Click Finish after the config is done.

    The rest of the function of buttons on this window are as follows:

    • Finish : Submits the current data
    • Reset : Loads the last submitted configuration
    • Default : Loads the default RM configuration. (Click Finish to submit)
    • Clear : Clears he text boxes
    • Cancel : Goes back to the service dashboard
  • No labels