Configuring Caching

When an API call hits the API Gateway, the Gateway carries out security checks to verify if the token is valid. During these verifications, the API Gateway extracts parameters such as access token, API name and API version that are passed on to it. Since the entire load of traffic to APIs goes through the API Gateway, this verification process needs to be fast and efficient in order to prevent overhead and delays. The API Manager uses caching for this purpose, where the validation information is cached with the token, API name and version, and the cache is stored in either the API Gateway or the key manager server.

The default cache size of any type of cache in a WSO2 product is 10,000 elements/records. Cache eviction occurs from the 10001st element. All caches in WSO2 products can be configured using the <PRODUCT_HOMe>/repository/conf/carbon.xml file. These configurations apply globally to all caches. You can override these values for specific caches using the UI or different configuration files as discussed under each section below.

This section covers the following: 

API Gateway cache

When caching is enabled at the Gateway and a request hits the Gateway, it first populates the cached entry for a given token. If a cache entry does not exist in cache, it calls the key manager server. This process is carried out using Web service calls. Once the key manager server returns the validation information, it gets stored in the Gateway. Because the API Gateway issues a Web service call to the key manager server only if it does not have a cache entry, this method reduces the number of Web service calls to the key manager server. Therefore, it is faster than the alternative method.

By default, the API Gateway cache is enabled as the <EnableGatewayTokenCache> element is set to true in the <APIM_HOME>/repository/conf/api-manager.xml file:

<EnableGatewayTokenCache>true</EnableGatewayTokenCache>

Clearing the API Gateway cache

To remove old tokens that might still remain active in the Gateway cache, you configure the <RevokeAPIURL> element in the api-manager.xml file by providing the URL of the Revoke API that is deployed in the API Gateway node. The revoke API invokes the cache clear handler, which extracts information form transport headers of the revoke request and clears all associated cache entries. If there's a cluster of API Gateways in your setup, provide the URL of the revoke API deployed in one node in the cluster. This way, all revoke requests route to the OAuth service through the Revoke API.

Given below is how to configure this in a distributed API Manager setup.

1. In the api-manager.xml file of the API Store node, point the revoke endpoint as follows:

   <RevokeAPIURL>https://${carbon.local.ip}:${https.nio.port}/revoke</RevokeAPIURL>

2. In the API Gateway, point the Revoke API to the OAuth application deployed in the key manager node. For example,

   <api name="_WSO2AMRevokeAPI_" context="/revoke">
           <resource methods="POST" url-mapping="/*" faultSequence="_token_fault_">
               <inSequence>
                   <send>
                       <endpoint>
                           <address uri="https://keymgt.wso2.com:9445/oauth2/revoke"/>
                       </endpoint>
                   </send>
               </inSequence>
               <outSequence>
                   <send/>
               </outSequence>
           </resource>
           <handlers>
               <handler class="org.wso2.carbon.apimgt.gateway.handlers.ext.APIManagerCacheExtensionHandler"/>
           </handlers>
   </api>

Resource cache

An API's resources are HTTP methods that handle particular types of requests such as GET, POST etc. They are similar to methods of a particular class. Each resource has parameters such as its throttling level, Auth type etc.

Users can make requests to an API by calling any one of the HTTP methods of the API's resources. The API Manager uses the resource cache at the Gateway node to store the API's resource-level parameters (Auth type and throttling level). The cache entry is identified by a cache key, which is based on the API's context, version, request path and HTTP method. Caching avoids the need to do a separate back-end call to check the Auth type and throttling level of a resource, every time a request to the API comes. It improves performance.

Note that if you update an API, the resource cache gets invalidated and the changes are reflected within a few minutes.

By default, the resource cache is enabled as the <EnableGatewayResourceCache> element is set to true in the <APIM_HOME>/repository/conf/api-manager.xml file:

<EnableGatewayResourceCache>true</EnableGatewayResourceCache>

Key Manager cache

The following caches are available: 

Key cache

In a typical API Manager deployment, the Gateway is deployed in a DMZ while the Key Manager is in MZ. By default, caching is enabled at the Gateway. To avoid caching token-related information in a leniently secured zone, you can store the cache on the Key Manager side. If you do, for each and every API call that hits the API Gateway, the Gateway issues a Web service call to the Key Manager server. If the cache entry is available in the Key Manager server, it is returned to the Gateway. Else, the database is checked for the validity of the token.

Storing the cache in the Key Manager causes lower performance than when storing it in the Gateway, but it is more secure. If you enable the key cache in a clustered environment, you should have only one Gateway per Key Manager, whereas you can have two Gateways per Key Manager when the Gateway cache is enabled instead. Note that you should always have one of the caches enabled, but we do not recommend using both caches combined. For more information, see Clustering Gateways and Key Managers with key caching in the WSO2 Clustering Guide.

You configure the key cache by editing the following elements in the <APIM_HOME>/repository/conf/api-manager.xml file:

OAuth cache

The OAuth token is saved in this cache, which is enabled by default. Whenever a new OAuth token is generated, it is saved in this cache to prevent constant database calls. Unless an OAuth expires or is revoked, the same token is sent back for the same user. Therefore, you do not need to change this cached token most of the time. 

Response cache

The API Manager uses WSO2 ESB's cache mediator to cache response messages per each API. Caching improves performance, because the backend server does not have to process the same data for a request multiple times. To offset the risk of stale data in the cache, you set an appropriate timeout period.

You enable response caching when creating a new API or editing an existing one using the API Publisher. Go to the API Publisher and click Add New API (to create a new API) or click the Edit icon associated with an existing API. Then, navigate to the Manage tab where you find the response caching section. You can set it to Enabled and give a timeout value. This enables the default response caching settings.

To change the default response caching settings, edit the following cache mediator properties in the <APIM_HOME>/repository/resources/api_templates/velocity_template.xml file:  

Invalidating Cached Responses Remotely

You can invalidate all cached response remotely by using any JMX monitoring tool such as Jconsole using the exposed MBeans. You can use the Invalidatemediatocache()operation of the org.wso2.carbon.mediation MBean for this as shown below.

API Store cache

The API Store has several caches to reduce the page-load times and increase its responsiveness when multiple users access it simultaneously.

• Tag cache: This cache saves the API's tags after they have been retrieved from registry. If your APIs and associated tags change frequently, it is recommended to configure a smaller cache refresh time (in milliseconds). This cache disabled by default. To enable it, uncomment the <TagCacheDuration> element in the <APIM_HOME>/repository/conf/api-manager.xml file. 

• Recently-added-API cache: This cache saves the five most recently added APIs. It is disabled by default. If you have multiple API modifications during a short time period, it is recommended to not enable this cache. To enable it, set the <EnableRecentlyAddedAPICache> to true in the <APIM_HOME>/repository/conf/api-manager.xml file.