...

• Minimum: 4 vCPU, 8 GB RAM (heap) - VM 12GB, 100GB dedicated partition on SSD ( on XFS filesystem ) ← THIS STATES MEM, CPU AND DISK REQS

• Recommended: 8 vCPU 12 GB RAM(heap) - VM 16 GB, 200GB dedicated partition on SSD ( on XFS )

CPU

• The system must have adequate CPU resources, as caching can lead to higher CPU utilization due to cache management (e.g., cache eviction policies, invalidation, etc.).

• Cache with complex data structures or serialization/deserialization can impact CPU usage. Basically already stated above

Network

• If any.

Disk

• If any.

Limitations

• Client-Specific Binding: Bound to a dedicated client, with no cross-gateway sharing allowed. The gateway must be able to intercept every write and delete that happens in Swarm.

• Non-Persistent Cache: The disk/memory cache is discarded by default on restart.

• Limited Lifecycle and Recursive Deletion Support: No support for bucket lifecycle policies, delete lifepoints, or recursive deletes. All writes and deletes must originate from the gateway.

• Stale Data: If data changes frequently, Listing Cache can serve outdated (stale) data unless proper cache invalidation mechanisms are in place.This is an implementation detail and no concern for the user.

• Memory Constraints: Caching large volumes of data can quickly consume system memory. Misconfiguring cache sizes can lead to memory exhaustion or excessive eviction, reducing cache effectiveness.

• Cache Invalidation Complexity: Managing cache invalidation (i.e., ensuring cached data is refreshed when source data changes) can be complex, especially in distributed environments or when working with dynamic data. Ditto

• Overhead on Writes: When new data is added or existing data is modified, cache updates and invalidation can add extra overhead, potentially slowing down write operations. Because LC allows switching of synchronous indexing, writes actually became faster. I do not think we need to raise this point.

• Cache Miss Penalties: If the cache miss rate is high (meaning data isn’t found in the cache often), the overhead of checking the cache and then falling back to the database could negatively impact performance. The worst case is no worse than without caching so I do not see this as a limitation.

• Custom delimiters are not yet supported, only forward slash "/"

How Does Listing Cache Work

...

1. Locate the cache configuration settings in your system’s configuration file or interface. In gateway.cfg, just set [storage_cluster]disableListingCache=false

2. Set the cache engine (e.g., Redis, Memcached) and specify settings such as cache size, eviction policies (e.g., LRU - Least Recently Used), and TTL (Time to Live) for cached items. I don’t know where you got this from. None of these technologies were used in LC????

3. Update code to leverage the Listing Cache. For example, fetch listings from the cache instead of querying the database, and store listings in the cache after the first database query. This is all transparent to gateway S3/SCSP clients.

4. Add checks to ensure cache invalidation happens when the data changes (e.g., if product details are updated).

5. After testing in a staging environment, roll out the Listing Cache to production by deploying the necessary configurations and code changes.

6. Monitor performance impact closely during the rollout phase.

7. Optional. Pre-warm the cache with commonly accessed listings before enabling it in production, so the initial requests are served from the cache.

...

How to Determine Listing Cache is Working Correctly

1. Monitor Cache Hit Rate

   • Use cache statistics (available through the cache system, such as Redis or Memcached) to monitor cache hit-and-miss rates. If they have telemetry and grafana available, they can check the LC dashboard.

   • A high cache hit rate (e.g., above 90%) indicates that the cache effectively serves requests.

2. Check Response Time

   • Compare the response time before and after enabling the Listing Cache. Reduced response times, particularly for frequently requested data, indicate the cache functions correctly.

3. Resource Utilization

   • Monitor memory usage and CPU utilization. Increased memory usage and steady CPU activity are normal in a caching system, but excessively high CPU or memory usage may indicate misconfiguration or over-reliance on the cache.

4. Log Analysis

   • Review application logs for cache access events, if you have implemented custom logging for cache hits, misses, and evictions. This helps verify that requests are being served from the cache. This requires switching on DEBUG logging. Do we want customers to do that? If yes I can explain which log messages to look for.

5. Data Consistency Checks

   • Ensure that cached data remains consistent with the data source after cache invalidation events. You can periodically run checks comparing cache data with the database to verify consistency. The only way to do this is to setup a second gateway WITHOUT listing cache and compare listing results from both.