Quick Links
Helpful Links
Non-persistent Cache
ChallengeThere are a number of situations that call for a caching facility to be available to help reduce unnecessary load on backend directory servers. Usually, Symlabs will tend to advise against long-term use of a cache to overcome performance issues, as these tend to indicate that the infrastructure itself is overloaded and should be scaled up accordingly, however there are times when a cache makes perfect sense, such as in a particularly abnormal spike in the number of transactions that are taking place at any given moment.
There are also situations that require a long-term caching solution to be put in place, simply due to the design of a client application and the way in which it makes particular requests. In these situations, you may need to use a cache simply to protect your backend directories from unnecessary repeated processing.
You may consider a persistent cache as a feasible option in these scenarios, however there are a number of issues that arise when you make use of a persistent cache. The first is that you have a basic synchronization issue, where the persistent cache needs to replicate a series of operations over regular intervals to maintain its cache. As a result, these intervals tend to be spread quite far apart, causing the persistent cache to frequently be out of sync with the actual data stored in the directory.
Another problem with persistent caches is that you are ultimately relying on the cache to serve your data. Very rarely is a persistent cache developed with the same level of overall care and dedication to performance as the commercial-grade directories. So ultimately, using a persistent cache, you start to trade off some of the super functionality provided by the directory you invested in, in the first place.
Solution
Symlabs Virtual Directory Server and LDAP Proxy include various plugins that facilitate the caching of search requests and results, as well as the caching of particular entries. These caching plugins can be configured to control the size of the cache, the number of entries to store, the length of time that they should be stored for and how to handle a situation where once the entries have expired the backend is not available.
All of these caching plugins store cached data in memory, so that it can be served immediately to a client without requiring additional disk I/O or processing. The only overhead for these caching plugins is the memory required to store the actual cached data, so you are not relying on an inferior directory to store your cached responses.
Since the caching process that takes place using these plugins is actually triggered by real requests and responses, there is no automated synchronization of data. This keeps the cached data as closely in sync with your backend repositories as you need, with no additional load on your backends.
Caching can be used in conjunction with Symlabs 'Resolve Dynamic Groups' plugin, which can resolve a dynamic group and present it as a static one. Using the caching plugins in conjunction with this functionality can massivley enhance performance and reduce overhead on your backend servers. As the number of users within a dynamic group grows, the cache will prove to be an effective resource in environments where dynamic groups are frequently used and the application design is such that it struggles to cope with dynamic group functionality.