aboutsummaryrefslogtreecommitdiffstats
path: root/guides/source/caching_with_rails.md
diff options
context:
space:
mode:
Diffstat (limited to 'guides/source/caching_with_rails.md')
-rw-r--r--guides/source/caching_with_rails.md19
1 files changed, 12 insertions, 7 deletions
diff --git a/guides/source/caching_with_rails.md b/guides/source/caching_with_rails.md
index 31bc478015..5dde6f34fa 100644
--- a/guides/source/caching_with_rails.md
+++ b/guides/source/caching_with_rails.md
@@ -32,7 +32,7 @@ Basic Caching
This is an introduction to three types of caching techniques: page, action and
fragment caching. By default Rails provides fragment caching. In order to use
page and action caching you will need to add `actionpack-page_caching` and
-`actionpack-action_caching` to your Gemfile.
+`actionpack-action_caching` to your `Gemfile`.
By default, caching is only enabled in your production environment. To play
around with caching locally you'll want to enable caching in your local
@@ -100,9 +100,9 @@ called key-based expiration.
Cache fragments will also be expired when the view fragment changes (e.g., the
HTML in the view changes). The string of characters at the end of the key is a
-template tree digest. It is an MD5 hash computed based on the contents of the
-view fragment you are caching. If you change the view fragment, the MD5 hash
-will change, expiring the existing file.
+template tree digest. It is a hash digest computed based on the contents of the
+view fragment you are caching. If you change the view fragment, the digest will
+change, expiring the existing file.
TIP: Cache stores like Memcached will automatically delete old cache files.
@@ -465,6 +465,10 @@ is often faster than waiting more than a second to retrieve it. Both read and
write timeouts default to 1 second, but may be set lower if your network is
consistently low latency.
+By default, the cache store will not attempt to reconnect to Redis if the
+connection fails during a request. If you experience frequent disconnects you
+may wish to enable reconnect attempts.
+
Cache reads and writes never raise exceptions. They just return `nil` instead,
behaving as if there was nothing in the cache. To gauge whether your cache is
hitting exceptions, you may provide an `error_handler` to report to an
@@ -480,9 +484,10 @@ like this:
cache_servers = %w[ "redis://cache-01:6379/0", "redis://cache-02:6379/0", … ],
config.cache_store = :redis_cache_store, url: cache_servers,
- connect_timeout: 30, # Defaults to 20 seconds
- read_timeout: 0.2, # Defaults to 1 second
- write_timeout: 0.2, # Defaults to 1 second
+ connect_timeout: 30, # Defaults to 20 seconds
+ read_timeout: 0.2, # Defaults to 1 second
+ write_timeout: 0.2, # Defaults to 1 second
+ reconnect_attempts: 1, # Defaults to 0
error_handler: -> (method:, returning:, exception:) {
# Report errors to Sentry as warnings