Apigee Edge provides caching for persistence of data across requests. When API data is received, it is stored in cache for a brief period of time and then deleted. The maximum amount of time a piece of data is kept before being deleted is called the expiry, or time-to-live (TTL), of the cache. Each cache has a default TTL, but in some cases you may need to change the TTL value to improve API performance.
Types of cache
API data is stored in two types of cache:
- Level 1 (L1): In-memory cache, which has faster access but less available storage capacity.
- Level 2 (L2): Persistent cache in a Cassandra data store, which has slower access but more available storage capacity.
When a data entry in L1 cache reaches the L1 TTL, it is deleted. However, a copy of the entry is kept in the L2 cache (which has a longer TTL than L1 cache), where it remains accessible to other message processors. See In-memory and persistent cache levels for more details about cache.
Max L1 TTL
In Edge for Private Cloud, you can set the maximum L1 cache TTL for each message
processor using the Max L1 TTL property (
An entry in the L1 cache will expire after reaching the Max L1 TTL value and be deleted.
- By default, Max L1 TTL is disabled (with the value
-1), in which case the TTL of an entry in L1 cache is determined by the PopulateCache policy's expiry settings (for both L1 and L2 cache).
- Max L1 TTL only has an effect if its value is smaller than the overall cache expiry.
Setting Max L1 TTL
You can set Max L1 TTL on a message processor as follows:
- Open the
/opt/apigee/customer/application/message-processor.propertiesin an editor. If the file doesn't exist, create it.
- Set the Max L1 TTL property to the desired value:
conf_cache_max.l1.ttl.in.seconds = 180
We recommend the value
- Make sure the properties file is owned by the "apigee" user:
chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
- Restart the message processor:
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
Guidelines for setting Max L1 TTL
When setting Max L1 TTL, keep the following guidelines in mind:
- RPC misses: If you are noticing remote procedure call (RPC) misses between
message processors (MPs)—
especially across multiple data centers—
it's possible that the L1 cache has stale entries, which will remain stale until they are deleted
from L1 cache. Setting Max L1 TTL to a lower value forces any
stale entries to be removed, and replaced with fresh values from L2 cache, sooner.
- Excessive load on Casandra: When you set a value for Max L1 TTL, L1 cache entries
will expire more often,
leading to more L1 cache misses and more L2 cache hits. Since L2 cache will be hit more often,
Cassandra will incur an increased load.
As a general rule, tune Max L1 TTL to a value that balances the frequency of RPC misses between MPs with the potential load on Cassandra.
We recommend setting the value of
conf_cache_max.l1.ttl.in.seconds to at least
180 seconds (3 minutes) to keep processing running smoothly.