4 ms·

Also note that HTTP had it since early days. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Modified-Since https://developer.mozilla.org/en-US/do

Also note that HTTP had it since early days. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Modified-Since https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If... And Apache and other web servers support it out of the box. If your use case allows it consider ditching Redis and rather static cache your generated HTML/json files on the file system while serving. And let Apache serve from there as long as those cached files exist. You get all these features for free.

lf-non 5y ago
As an extension, for use cases where this is not feasible (eg. you have clustering, non-trivial permission checks or multi-entity payloads etc.) it is quite convenient to have nginx with openresty talk to redis.
- derefr 5y ago
  I would note that while Nginx itself doesn’t natively support Redis (and so you have to script things yourself in that case), it does have full native support for memcached (or rather, the memcached wire protocol, spoken by several backends, though sadly Redis isn’t one of those.) See http://nginx.org/en/docs/http/ngx_http_memcached_module.html http://nginx.org/en/docs/http/ngx_http_memcached_module.html for details. Basically, you can hand off to memcached as if handing off to an upstream, and then if memcached doesn’t have the key, continue on trying to resolve the response through your actual app-server upstream. (This is essentially the same thing you’re suggesting doing through scripting, to be clear; it’s just easier to implement for the memcached case.) This type of middleware-level “read-aside” caching is really neat, because it enables push-based response caching: rather than having a read-through cache that expires items out of itself, where an expired item potentially leads to a thundering herd of clients all trying to grab the expired item and so generating independent requests to your backend (that can hopefully be coalesced into a single recomputation, but that’s unlikely in a distributed environment), you can instead just keep the cache always-populated, and every once in a while — perhaps on a schedule, perhaps in response to discovering new primary-source data — recompute your denormalized/report resource, and atomically overwrite what was in the cache with the new data.

lf-non 5y ago

As an extension, for use cases where this is not feasible (eg. you have clustering, non-trivial permission checks or multi-entity payloads etc.) it is quite convenient to have nginx with openresty talk to redis.

derefr 5y ago
I would note that while Nginx itself doesn’t natively support Redis (and so you have to script things yourself in that case), it does have full native support for memcached (or rather, the memcached wire protocol, spoken by several backends, though sadly Redis isn’t one of those.) See http://nginx.org/en/docs/http/ngx_http_memcached_module.html http://nginx.org/en/docs/http/ngx_http_memcached_module.html for details. Basically, you can hand off to memcached as if handing off to an upstream, and then if memcached doesn’t have the key, continue on trying to resolve the response through your actual app-server upstream. (This is essentially the same thing you’re suggesting doing through scripting, to be clear; it’s just easier to implement for the memcached case.) This type of middleware-level “read-aside” caching is really neat, because it enables push-based response caching: rather than having a read-through cache that expires items out of itself, where an expired item potentially leads to a thundering herd of clients all trying to grab the expired item and so generating independent requests to your backend (that can hopefully be coalesced into a single recomputation, but that’s unlikely in a distributed environment), you can instead just keep the cache always-populated, and every once in a while — perhaps on a schedule, perhaps in response to discovering new primary-source data — recompute your denormalized/report resource, and atomically overwrite what was in the cache with the new data.