How does it work?
Apigee Edge uses Cassandra for its persistent datastore and cached data is stored in Cassandra. This enables us to provide distributed caching across multiple processing servers when we scale and even across regions. However, Edge caching does function as a 2 level cache. When a request hits an Apigee message processor (MP), it will try to return from an in-memory cache first. If it doesn't exist in memory, it fetches from Cassandra and then populates the value in memory for the next time.
What is the need for a distributed cache?
Depending on your solution, you may need to maintain state in Apigee across multiple API requests and be fault tolerant. As Edge typically has more than 1 message processor taking traffic, the distributed caching feature allows any message processor to have access to the same cache, persisted across any application restarts. An example solution needing a distributed cache is providing server-side storage for web sessions.
How are cache updates and invalidations handled in the distributed scenario?
When a cache entry's value is updated or invalidated, the message processor handling the event will notify the other message processors that the value has changed. These MPs will then remove their in-memory value for the given cache key. When the other MPs have to lookup the cache value again, it can be fetched from cassandra.
Can you control the configuration and limits of the cache?
There is no way to configure how much (in terms of size) can be cached. A named cache resource in Apigee has a concept of # of elements in memory with no relation to overall size. What does this mean? The 2nd level of cache (Cassandra) allows to you cache as much as you want, but the in-memory level will always have a finite space limitation since it's dependent on memory. The memory elements setting allows you to optimize which objects you want to return slightly faster from memory. Also, be aware that cache policy execution, today, doesn't tell you where the value returned from(memory/cassandra).
Configurable percentage limits do exist for the message processor to ensure caching does not consume all of the application's memory. When using Apigee's cloud offering, these settings are managed by Apigee and the customer does not have control. If deploying Apigee on-premises in a private cloud, the settings can be changed but typically it's not necessary alter the default configuration.
For more information on how to use the caching policies and configure named cache resources, please see the docs pages: Cache Policies , Cache Resources, Cache Internals
Michael - in the following article:
http://apigee.com/docs/api-services/content/manage-caches-environment
Reference is made to the shared cache - which does not have all of the fancy settings of the defined caches.
one thing we want to understand is if this shared cache is also a distributed cache?
Also - we are looking to understand if that memory limit mentioned above applies to a total utilization from ALL caches as a total or to each cache independently?
The default (shared) cache should also be distributed. As far as the memory limits, here are the differences. # max elements configuration - this is set on the cache resource so limit is per cache resource
configurable percentage limit - this is a usage memory limit across all cache resources
I'll try to clarify this more in the article when I get a chance. Thanks!
On this doc, the last point in "Level 1 is an in-memory cache" states "Each in-memory cache instance is isolated and cache entries are not distributed across message processors". This contradicts the information in this post.
Specifically, I'm referring to the diagram and "When a cache entry's value is updated or invalidated, the message processor handling the event will notify the other message processors that the value has changed".
Does it just notify other MPs of the change, or will it share the change (with k & v)?
Any clarification on this would be great!
Thanks,
Omid
Contributors
10 People are following this .
