Caching
Cloud Drive Mapper (CDM) has two types of caching in the provider designed to minimize throttling and reduce the overall number of requests to the provider:
Delta requests are typically the largest and most impactful set of calls, especially for dynamic drives. CDM doesn’t apply caching to direct drives since the provider already returns only the changes based on the delta timestamp or token. However, CDM implements an artificial cache period independent of the delta frequency for endpoint types that require regular full enumeration (for example, listing all sites to display on a dynamic type).
The DeltaFrequency setting informs CDM how often to request updates from the provider. In contrast, the CacheLifetimeInSeconds (+/- user dispersion) setting determines whether the provider should return cached values to CDM or retrieve fresh data from the actual remote provider.
Delta caching
Delta caching is particularly crucial for dynamic drives, as retrieving data often requires a series of very large requests. Running these requests at the cadence of DeltaFrequency can be too aggressive, potentially overwhelming the provider with unnecessary calls. As such, once CDM successfully generates a delta response, it’s cached for the duration of CacheLifetimeInSeconds, in line with user dispersion to spread out refresh times across users.
This delta caching exists within the endpoint, so each endpoint has an independent cache, giving it control over caching behavior based on specific needs.
Persist to file
Delta caching includes support for persisting cached data to a file, by default, in the user's app data location, which helps reduce the number of calls during CDM startup. However, if users’ profiles are not persisted we do offer a central caching option if desired. CDM applies the following functionality:
-
Initial delta from cache: On startup, the first delta request can retrieve data from the cached file, reducing load times.
-
Centralized caching: In some environments, often found in some VDI scenarios where CDM might not be able to persist the user app data, it is possible to store this in a central location as a file share. This allows for faster drive enumeration even if the database is refreshed with each session (non-persisted).
Request caching
Request caching is a more sophisticated solution, it works across the provider type (across all endpoints).
Example
When a request is made to the provider, the wrapper can cache the result if requested, allowing future calls to return cached data if the TTL is valid. For example, when running a user delta for a dynamic drive (such as DynamicSharePointSites), the following sequence of requests might be made:
-
Call 1: Get all MS Teams
-
Call 2: Get all SharePoint sites
-
Call 3: Get all group memberships
-
Call 4: Loop over all sites and make a call to verify permissions and check if any document libraries exist within the library.
Suppose 100 sites are returned for call 2. This delta requires 103 calls to the provider. We automatically retry after receiving a 503 or 429 response using the Retry-After header provided.
So, let's say CDM performs the first 3 calls and then is in the loop. 75 of the sites have been processed, and CDM has now received a throttle back from the provider.
We will attempt to retry by default 5 times, honoring the Retry-After header each time. If this recovers within the retry threshold, it will resume from the 75th site.
However, if it does not recover within this threshold, it will cancel the request allowing us to better inform the user and keep stability in the client for the user. CDM will then retry again from scratch. Without request caching, all previous progress (calls 1-3 and the 75 sites) would be lost, necessitating a re-run of all calls on retry, substantially increasing the probability of getting throttled again and likely never mounting the drive due to consistently falling into this retry pattern.
With request caching, the wrapper described in the Request concurrency and burst management section can cache each response, allowing CDM to retrieve cached responses upon retry. This prevents redundant calls to the provider by returning cached data for the initial requests. When the next delta retry occurs, CDM initiates the sequence again. However, instead of re-running all previous requests, the wrapper serves cached data for the first 3 steps and the 75 already-processed sites, effectively resuming at the 76th site and minimizing duplicate calls.
Request caching is stored in memory only and does not persist in the file. File storage is reserved for complete responses rather than partial data from individual requests.
