skip to Main Content

I have a backend API service that requires bearer-token authorization, and it is fronted by Azure API Management. One particular endpoint returns a large dataset (at least 3MB in size) but the endpoint has no parameters so any given response is valid for all users.

I have an external Azure Redis Cache configured for this APIM instance, and I want to add caching to this one endpoint, with the response cached for ALL users (not per-user).

To start off, I’m trying to get this working on a different parameter-less endpoint that only returns a 3Kb response – when I get it working, I’ll apply the policy to the 3MB+ endpoint.

I tried adding a simple cache-store/cache-lookup policy:

<cache-lookup vary-by-developer="false" vary-by-developer-groups="false"
              downstream-caching-type="none" caching-type="external" />

But that didn’t work, and the following cache-lookup trace message was displayed:

"Request contains Authorization header. Cache Lookup policy was not applied."

So, I had to add another parameter to the cache-lookup policy:

allow-private-response-caching="true"

When I did this, the cache-lookup ran, but the trace message showed it was a miss:

{
    "message": "Cache lookup resulted in a miss. Cache headers listed below were removed from the request to prompt the backend service to send back a complete response.",
    "cacheKey": "**************************************************************",
    "cacheHeaders": [
        {
            "name": "Cache-Control",
            "value": "no-cache, no-store"
        }
    ]
}

However, the cache-store trace message said that the response would be cached:

"Response will be buffered during streaming and stored in the cache after it is received in full."

So I ran the trace again, but it resulted in another "cache miss". No matter how many times I run the trace, it always says the cache is a miss, but the cache-key is identical every time. The cache duration is 3600, so the response should be cached for an hour.

If the key isn’t changing, why does each lookup always result in a miss?

2

Answers


  1. Chosen as BEST ANSWER

    It turns out that there was a configuration on the NSG (Network Security Group) that was preventing communication between APIM and the REDIS server on the ports that Redis requires.

    FIX - We had to create Inbound/Outbound security rules to allow communication on ports 6380-6383 and this resolved the issue.

    Thanks for your input!


  2. Check if my below findings help to fix your issue:

    • If your request comes within the cache duration specified such as 3600 seconds, then the result will be Cache lookup resulted in a hit instead of Cache lookup resulted in a miss under Inbound Section.

    • Also, Check in the policy-chain that cache-lookup policy should be written before the Cache-store section, also correctly scoped to the target gateway such as Product of APIs, Operations or the API level and then try re-run by clearing the cache.

    • And If your APIM is in Consumption tier, this would be one of the reasons for getting the message like Cache lookup resulted in a miss. In Consumption Tier of Azure APIM, you have to use external Redis compatible cache as specified in this GitHub Issue #43964.

    If the key isn’t changing, why does each lookup always result in a miss?

    This could be because of the cache policy which is set in APIM.

    • If the policy is set to cache the response based on the request parameters, then each request with different request parameters will result in a cache miss.
    • If the policy is configured to cache the response for a short period, each consecutive request results in a cache miss.
    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search