Guide to manual testing of Adaptive Caching
Adaptive Caching Concept The adaptive caching is a Read-Through cache designed to increase performance of common shapes of data requested via the landscape.
The components involved in adaptive caching are:
|landscape api||manages the swapping of normal queries to adaptive caching queries|
|question service||periodically polls the adaptive cache logs and manages the adding of adaptive cache data into neo|
|adaptive cache logs||stored in Sql Server, these log the user landscape request activity|
|adaptive cache entries||stored as context based sub-graphs in Neo4J, these are the data caches|
The pattern of progression to having an adaptive cache entry for a specific request is as follows:
- A user performs an action within landscape explorer. The single user action initiates several data request actions that fall within one of three categories: count, summary or table requests. These align to context planet counts, planet property summary cards and charts data requests.
- For each data request the system identifies which category the neo query falls into, and allocates it the category.
- When attempting to execute the cypher query, the system first performs an adaptive cache hit test based upon the current context id and specific checks given the query category.
- If an adaptive cache log is hit, then the hit count is incremented; if no cache log is hit, then the cypher query is executed as normal and a new cache log is written to sql (assuming the query took > 10 ms to finish).
- If an adaptive cache log was hit, but the cache log hasn't yet been added as a cache to neo, then the original cypher query is executed.
- However, if an adaptive cache log was hit, and the cache log has been added as a cache to neo, then the original cypher query is replaced with a specific neo cache query.
The only component which adds the cached data to Neo4J is the QuestionService, which polls the adaptive caching logs in Sql every X minutes.