Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

Neptune Result Cache Ineffective

0

I have enabled Result Caching in AWS Neptune. My Slow Query logs tell me that my cache is being hit, but that there is no performance improvement over misses. I have tested on db.t4g.medium and db.r6g.large, with small and large traversals and I see no difference.

  • Taylor-AWS
    2 years ago

    Can you provide some further details of how you're using the query results cache? The results cache is not supported on the smaller t3 or t4g instances. Are you using the with('Neptune#enableResultCache', true) query hint as noted in the docs here: https://docs.aws.amazon.com/neptune/latest/userguide/gremlin-results-cache.html. The first time the query is executed, it will take the same amount of time as if executed without the results cache. For later invocations, it will execute faster (including when using range() based calls).

  • Dude-Bro
    2 years ago

    Some progress made. The first thing I should note is that the db.t4g.medium is indeed producing Slow Query logs indicating that Result Caching is supported for this instance. If it is not truly supported, but AWS is still logging hit, miss, and put (which it certainly appears to be) that seems like a problem.

    It also appears that the cache is taking multiple hits to warm. I had previously been invalidating the cache too quickly in an attempt to better benchmark hit and miss execution runtime as the traffic increased on the node.

    Portions of the query response are included below for reference. Thanks!

    {
    "queryStats": {
        "query": "g.withStrategies(new org.apache.tinkerpop.gremlin.process.traversal.strategy.decoration.OptionsStrategy(Neptune#enableResultCache: true)).V().limit((int) 1000)",
        "queryFingerprint": "g.withStrategies(org.apache.tinkerpop.gremlin.process.traversal.strategy.decoration.OptionsStrategy.create(new org.apache.commons.configuration.MapConfiguration([(string0):(true)]))).V().limit(integer0)",
        "queryLanguage": "Gremlin"
    },
    "queryTimeStats": {
        "startTimeEpoch": 1730470935513,
        "startTime": "2024-11-01T14:22:15.513Z",
        "overallRunTimeMs": 3,
        "waitingTimeMs": 1,
        "serializationTimeMs": 2
    },
    "resultCacheStats": {
        "hitCount": 1
    }
}
  • Taylor-AWS
    2 years ago

    We're investigating as to why the Slow Query Log is producing stats for the Results Cache on smaller instances. That is unexpected. I'm not certain whether the SLQ is mis-reporting those or if the Results Cache is actually getting enabled (when it shouldn't). The smaller instances are memory-bound, hence we chose not to enable the Results Cache on those instance types/sizes. I'll report back here once I know more.

Topics
Database
Tags
Amazon Neptune
Language
English

asked 2 years ago368 views

1 Answer
-3

It appears that you're experiencing an issue where enabling the query results cache in Amazon Neptune is not providing the expected performance improvements. There are a few potential reasons for this:

  1. Instance Type: The instance types you mentioned (db.t4g.medium and db.r6g.large) may not be optimal for leveraging the results cache effectively. The lookup cache, which can significantly improve read performance, is only available on R5d instance types. These instances have additional NVMe-based SSD storage specifically designed for caching property values and RDF literals.

  2. Query Complexity: The effectiveness of the results cache depends on the nature of your queries. If your queries are not returning properties of a very large number of vertices and edges, or RDF triples, the cache may not provide significant benefits.

  3. Cache Warming: When you first enable the cache, it starts in a cold state. It needs time to warm up as it processes queries and adds results to the cache. You may not see immediate performance improvements until the cache has had time to populate with frequently accessed data.

  4. Query Patterns: The cache is most effective for read-only queries that are repeated frequently. If your workload consists of many unique queries or write-heavy operations, the cache may not provide substantial benefits.

  5. Data Size: If your dataset is small enough to fit entirely in memory, you might not see significant improvements from caching.

To potentially improve your situation:

  1. Consider upgrading to an R5d instance type if your workload involves many property lookups or RDF literal retrievals.

  2. Monitor your CloudWatch metrics, particularly the BufferCacheHitRatio. A drop in this metric during read queries can indicate that the lookup cache might be beneficial.

  3. Use query hints like 'enableResultCache' or 'enableResultCacheWithTTL' to explicitly cache specific queries that you know are frequently repeated.

  4. Analyze your query patterns to ensure they are suitable for caching. Queries that return a large number of property values are more likely to benefit from caching.

  5. Give the cache time to warm up and populate with frequently accessed data before drawing conclusions about its effectiveness.

If these steps don't help, you may need to further analyze your specific workload and query patterns to determine if caching is the right optimization strategy for your use case.
Sources
Caching query results in Amazon Neptune Gremlin - Amazon Neptune
Use cases for the Neptune lookup cache - Amazon Neptune
Using the lookup cache - Amazon Neptune

answered 2 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content