You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are many times that the same request from different sessions all hit our REST server even though cloud CDN is enabled and the responses have proper cache control header set.
There are also periodic high rate of response code 304 from our REST server because some clients will issue a HEAD request with cache id to probe if the cache is still valid. Due to lack of head handler in our js REST module, it ends up to go though the get handler and query data, then expressjs learns the cache is still valid, zeros out the response body and sends a 304 response.
We should add a application layer cache to handle such scenarios so the rest server doesn't unnecessarily go to the database for the data.
Solution
Add logic in response handler middleware to cache responses in redis
we can use the hash of the request as the key
we should set the cache ttl the same as how it's configured by path in the response cache-control header
Add a middleware before any of the handlers to check if the request url has a cached response, and if so, respond with the cached response and terminate the request handling
Alternatives
No response
The text was updated successfully, but these errors were encountered:
Problem
There are many times that the same request from different sessions all hit our REST server even though cloud CDN is enabled and the responses have proper cache control header set.
There are also periodic high rate of response code 304 from our REST server because some clients will issue a HEAD request with cache id to probe if the cache is still valid. Due to lack of head handler in our js REST module, it ends up to go though the get handler and query data, then expressjs learns the cache is still valid, zeros out the response body and sends a 304 response.
We should add a application layer cache to handle such scenarios so the rest server doesn't unnecessarily go to the database for the data.
Solution
Alternatives
No response
The text was updated successfully, but these errors were encountered: