/
caching_with_rails.html
741 lines (674 loc) · 47.2 KB
/
caching_with_rails.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Caching with Rails: An Overview — Ruby on Rails Guides</title>
<link rel="stylesheet" type="text/css" href="stylesheets/style.css" data-turbolinks-track="reload">
<link rel="stylesheet" type="text/css" href="stylesheets/print.css" media="print">
<link rel="stylesheet" type="text/css" href="stylesheets/syntaxhighlighter/shCore.css" data-turbolinks-track="reload">
<link rel="stylesheet" type="text/css" href="stylesheets/syntaxhighlighter/shThemeRailsGuides.css" data-turbolinks-track="reload">
<link rel="stylesheet" type="text/css" href="stylesheets/fixes.css" data-turbolinks-track="reload">
<link href="images/favicon.ico" rel="shortcut icon" type="image/x-icon" />
<script src="javascripts/syntaxhighlighter.js" data-turbolinks-track="reload"></script>
<script src="javascripts/turbolinks.js" data-turbolinks-track="reload"></script>
<script src="javascripts/guides.js" data-turbolinks-track="reload"></script>
<script src="javascripts/responsive-tables.js" data-turbolinks-track="reload"></script>
</head>
<body class="guide">
<div>
<img src="images/edge_badge.png" alt="edge-badge" id="edge-badge" />
</div>
<div id="topNav">
<div class="wrapper">
<strong class="more-info-label">Veja mais em <a href="http://rubyonrails.org/">rubyonrails.org:</a> </strong>
<span class="red-button more-info-button">
Mais Ruby on Rails
</span>
<ul class="more-info-links s-hidden">
<li class="more-info"><a href="https://weblog.rubyonrails.org/">Blog</a></li>
<li class="more-info"><a href="https://guides.rubyonrails.org/">Guia</a></li>
<li class="more-info"><a href="http://api.rubyonrails.org/">API</a></li>
<li class="more-info"><a href="https://stackoverflow.com/questions/tagged/ruby-on-rails">Pedir ajuda</a></li>
<li class="more-info"><a href="https://github.com/rails/rails">Contribuir no GitHub</a></li>
</ul>
</div>
</div>
<div id="header">
<div class="wrapper clearfix">
<h1><a href="index.html" title="Return to home page">Guides.rubyonrails.org</a></h1>
<ul class="nav">
<li><a class="nav-item" href="index.html">Home</a></li>
<li class="guides-index guides-index-large">
<a href="index.html" id="guidesMenu" class="guides-index-item nav-item">Guias</a>
<div id="guides" class="clearfix" style="display: none;">
<hr />
<div class="guides-section-container">
<div class="guides-section">
<dt>Comece Aqui</dt>
</div>
<div class="guides-section">
<dt>Models</dt>
</div>
<div class="guides-section">
<dt>Views</dt>
</div>
<div class="guides-section">
<dt>Controllers</dt>
</div>
<div class="guides-section">
<dt>Other Components</dt>
</div>
<div class="guides-section">
<dt>Digging Deeper</dt>
</div>
<div class="guides-section">
<dt>Extending Rails</dt>
<dd><a href="rails_on_rack.html">Rails on Rack</a></dd>
<dd><a href="generators.html">Creating and Customizing Rails Generators & Templates</a></dd>
</div>
<div class="guides-section">
<dt>Contributions</dt>
<dd><a href="contributing_to_ruby_on_rails.html">Contributing to Ruby on Rails</a></dd>
<dd><a href="api_documentation_guidelines.html">API Documentation Guidelines</a></dd>
<dd><a href="ruby_on_rails_guides_guidelines.html">Guides Guidelines</a></dd>
</div>
<div class="guides-section">
<dt>Policies</dt>
<dd><a href="maintenance_policy.html">Maintenance Policy</a></dd>
</div>
<div class="guides-section">
<dt>Release Notes</dt>
<dd><a href="upgrading_ruby_on_rails.html">Upgrading Ruby on Rails</a></dd>
<dd><a href="5_2_release_notes.html">Version 5.2 - April 2018</a></dd>
<dd><a href="5_1_release_notes.html">Version 5.1 - April 2017</a></dd>
<dd><a href="5_0_release_notes.html">Version 5.0 - June 2016</a></dd>
<dd><a href="4_2_release_notes.html">Version 4.2 - December 2014</a></dd>
<dd><a href="4_1_release_notes.html">Version 4.1 - April 2014</a></dd>
<dd><a href="4_0_release_notes.html">Version 4.0 - June 2013</a></dd>
<dd><a href="3_2_release_notes.html">Version 3.2 - January 2012</a></dd>
<dd><a href="3_1_release_notes.html">Version 3.1 - August 2011</a></dd>
<dd><a href="3_0_release_notes.html">Version 3.0 - August 2010</a></dd>
<dd><a href="2_3_release_notes.html">Version 2.3 - March 2009</a></dd>
<dd><a href="2_2_release_notes.html">Version 2.2 - November 2008</a></dd>
</div>
</div>
</div>
</li>
<li><a class="nav-item" href="contributing_to_ruby_on_rails.html">Contribua</a></li>
<li class="guides-index guides-index-small">
<select class="guides-index-item nav-item">
<option value="index.html">Guias</option>
<optgroup label="Comece Aqui">
</optgroup>
<optgroup label="Models">
</optgroup>
<optgroup label="Views">
</optgroup>
<optgroup label="Controllers">
</optgroup>
<optgroup label="Other Components">
</optgroup>
<optgroup label="Digging Deeper">
</optgroup>
<optgroup label="Extending Rails">
<option value="rails_on_rack.html">Rails on Rack</option>
<option value="generators.html">Creating and Customizing Rails Generators & Templates</option>
</optgroup>
<optgroup label="Contributions">
<option value="contributing_to_ruby_on_rails.html">Contributing to Ruby on Rails</option>
<option value="api_documentation_guidelines.html">API Documentation Guidelines</option>
<option value="ruby_on_rails_guides_guidelines.html">Guides Guidelines</option>
</optgroup>
<optgroup label="Policies">
<option value="maintenance_policy.html">Maintenance Policy</option>
</optgroup>
<optgroup label="Release Notes">
<option value="upgrading_ruby_on_rails.html">Upgrading Ruby on Rails</option>
<option value="5_2_release_notes.html">Version 5.2 - April 2018</option>
<option value="5_1_release_notes.html">Version 5.1 - April 2017</option>
<option value="5_0_release_notes.html">Version 5.0 - June 2016</option>
<option value="4_2_release_notes.html">Version 4.2 - December 2014</option>
<option value="4_1_release_notes.html">Version 4.1 - April 2014</option>
<option value="4_0_release_notes.html">Version 4.0 - June 2013</option>
<option value="3_2_release_notes.html">Version 3.2 - January 2012</option>
<option value="3_1_release_notes.html">Version 3.1 - August 2011</option>
<option value="3_0_release_notes.html">Version 3.0 - August 2010</option>
<option value="2_3_release_notes.html">Version 2.3 - March 2009</option>
<option value="2_2_release_notes.html">Version 2.2 - November 2008</option>
</optgroup>
</select>
</li>
</ul>
</div>
</div>
<hr class="hide" />
<div id="feature">
<div class="wrapper">
<h2>Caching with Rails: An Overview</h2><p>This guide is an introduction to speeding up your Rails application with caching.</p><p>Caching means to store content generated during the request-response cycle and
to reuse it when responding to similar requests.</p><p>Caching is often the most effective way to boost an application's performance.
Through caching, web sites running on a single server with a single database
can sustain a load of thousands of concurrent users.</p><p>Rails provides a set of caching features out of the box. This guide will teach
you the scope and purpose of each one of them. Master these techniques and your
Rails applications can serve millions of views without exorbitant response times
or server bills.</p><p>After reading this guide, you will know:</p>
<ul>
<li>Fragment and Russian doll caching.</li>
<li>How to manage the caching dependencies.</li>
<li>Alternative cache stores.</li>
<li>Conditional GET support.</li>
</ul>
<div id="subCol">
<h3 class="chapter"><img src="images/chapters_icon.gif" alt="" />Chapters</h3>
<ol class="chapters">
<li>
<a href="#basic-caching">Basic Caching</a>
<ul>
<li><a href="#page-caching">Page Caching</a></li>
<li><a href="#action-caching">Action Caching</a></li>
<li><a href="#fragment-caching">Fragment Caching</a></li>
<li><a href="#russian-doll-caching">Russian Doll Caching</a></li>
<li><a href="#shared-partial-caching">Shared Partial Caching</a></li>
<li><a href="#managing-dependencies">Managing dependencies</a></li>
<li><a href="#low-level-caching">Low-Level Caching</a></li>
<li><a href="#sql-caching">SQL Caching</a></li>
</ul>
</li>
<li>
<a href="#cache-stores">Cache Stores</a>
<ul>
<li><a href="#configuration">Configuration</a></li>
<li><a href="#activesupport-cache-store">ActiveSupport::Cache::Store</a></li>
<li><a href="#activesupport-cache-memorystore">ActiveSupport::Cache::MemoryStore</a></li>
<li><a href="#activesupport-cache-filestore">ActiveSupport::Cache::FileStore</a></li>
<li><a href="#activesupport-cache-memcachestore">ActiveSupport::Cache::MemCacheStore</a></li>
<li><a href="#activesupport-cache-rediscachestore">ActiveSupport::Cache::RedisCacheStore</a></li>
<li><a href="#activesupport-cache-nullstore">ActiveSupport::Cache::NullStore</a></li>
</ul>
</li>
<li><a href="#cache-keys">Cache Keys</a></li>
<li>
<a href="#conditional-get-support">Conditional GET support</a>
<ul>
<li><a href="#strong-v-s-weak-etags">Strong v/s Weak ETags</a></li>
</ul>
</li>
<li><a href="#caching-in-development">Caching in Development</a></li>
<li><a href="#references">References</a></li>
</ol>
</div>
</div>
</div>
<div id="container">
<div class="wrapper">
<div id="mainCol">
<h3 id="basic-caching"><a class="anchorlink" href="#basic-caching">1 Basic Caching</a></h3><p>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 <code>actionpack-page_caching</code> and
<code>actionpack-action_caching</code> to your <code>Gemfile</code>.</p><p>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
environment by setting <code>config.action_controller.perform_caching</code> to <code>true</code> in
the relevant <code>config/environments/*.rb</code> file:</p><div class="code_container">
<pre class="brush: ruby; gutter: false; toolbar: false">
config.action_controller.perform_caching = true
</pre>
</div>
<div class="note"><p>Changing the value of <code>config.action_controller.perform_caching</code> will
only have an effect on the caching provided by the Action Controller component.
For instance, it will not impact low-level caching, that we address
<a href="#low-level-caching">below</a>.</p></div><h4 id="page-caching"><a class="anchorlink" href="#page-caching">1.1 Page Caching</a></h4><p>Page caching is a Rails mechanism which allows the request for a generated page
to be fulfilled by the webserver (i.e. Apache or NGINX) without having to go
through the entire Rails stack. While this is super fast it can't be applied to
every situation (such as pages that need authentication). Also, because the
webserver is serving a file directly from the filesystem you will need to
implement cache expiration.</p><div class="info"><p>Page Caching has been removed from Rails 4. See the <a href="https://github.com/rails/actionpack-page_caching">actionpack-page_caching gem</a>.</p></div><h4 id="action-caching"><a class="anchorlink" href="#action-caching">1.2 Action Caching</a></h4><p>Page Caching cannot be used for actions that have before filters - for example, pages that require authentication. This is where Action Caching comes in. Action Caching works like Page Caching except the incoming web request hits the Rails stack so that before filters can be run on it before the cache is served. This allows authentication and other restrictions to be run while still serving the result of the output from a cached copy.</p><div class="info"><p>Action Caching has been removed from Rails 4. See the <a href="https://github.com/rails/actionpack-action_caching">actionpack-action_caching gem</a>. See <a href="http://signalvnoise.com/posts/3113-how-key-based-cache-expiration-works">DHH's key-based cache expiration overview</a> for the newly-preferred method.</p></div><h4 id="fragment-caching"><a class="anchorlink" href="#fragment-caching">1.3 Fragment Caching</a></h4><p>Dynamic web applications usually build pages with a variety of components not
all of which have the same caching characteristics. When different parts of the
page need to be cached and expired separately you can use Fragment Caching.</p><p>Fragment Caching allows a fragment of view logic to be wrapped in a cache block and served out of the cache store when the next request comes in.</p><p>For example, if you wanted to cache each product on a page, you could use this
code:</p><div class="code_container">
<pre class="brush: ruby; html-script: true; gutter: false; toolbar: false">
<% @products.each do |product| %>
<% cache product do %>
<%= render product %>
<% end %>
<% end %>
</pre>
</div>
<p>When your application receives its first request to this page, Rails will write
a new cache entry with a unique key. A key looks something like this:</p><div class="code_container">
<pre class="brush: plain; gutter: false; toolbar: false">
views/products/1-201505056193031061005000/bea67108094918eeba42cd4a6e786901
</pre>
</div>
<p>The number in the middle is the <code>product_id</code> followed by the timestamp value in
the <code>updated_at</code> attribute of the product record. Rails uses the timestamp value
to make sure it is not serving stale data. If the value of <code>updated_at</code> has
changed, a new key will be generated. Then Rails will write a new cache to that
key, and the old cache written to the old key will never be used again. This is
called key-based expiration.</p><p>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 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.</p><div class="info"><p>Cache stores like Memcached will automatically delete old cache files.</p></div><p>If you want to cache a fragment under certain conditions, you can use
<code>cache_if</code> or <code>cache_unless</code>:</p><div class="code_container">
<pre class="brush: ruby; html-script: true; gutter: false; toolbar: false">
<% cache_if admin?, product do %>
<%= render product %>
<% end %>
</pre>
</div>
<h5 id="collection-caching"><a class="anchorlink" href="#collection-caching">1.3.1 Collection caching</a></h5><p>The <code>render</code> helper can also cache individual templates rendered for a collection.
It can even one up the previous example with <code>each</code> by reading all cache
templates at once instead of one by one. This is done by passing <code>cached: true</code> when rendering the collection:</p><div class="code_container">
<pre class="brush: ruby; html-script: true; gutter: false; toolbar: false">
<%= render partial: 'products/product', collection: @products, cached: true %>
</pre>
</div>
<p>All cached templates from previous renders will be fetched at once with much
greater speed. Additionally, the templates that haven't yet been cached will be
written to cache and multi fetched on the next render.</p><h4 id="russian-doll-caching"><a class="anchorlink" href="#russian-doll-caching">1.4 Russian Doll Caching</a></h4><p>You may want to nest cached fragments inside other cached fragments. This is
called Russian doll caching.</p><p>The advantage of Russian doll caching is that if a single product is updated,
all the other inner fragments can be reused when regenerating the outer
fragment.</p><p>As explained in the previous section, a cached file will expire if the value of
<code>updated_at</code> changes for a record on which the cached file directly depends.
However, this will not expire any cache the fragment is nested within.</p><p>For example, take the following view:</p><div class="code_container">
<pre class="brush: ruby; html-script: true; gutter: false; toolbar: false">
<% cache product do %>
<%= render product.games %>
<% end %>
</pre>
</div>
<p>Which in turn renders this view:</p><div class="code_container">
<pre class="brush: ruby; html-script: true; gutter: false; toolbar: false">
<% cache game do %>
<%= render game %>
<% end %>
</pre>
</div>
<p>If any attribute of game is changed, the <code>updated_at</code> value will be set to the
current time, thereby expiring the cache. However, because <code>updated_at</code>
will not be changed for the product object, that cache will not be expired and
your app will serve stale data. To fix this, we tie the models together with
the <code>touch</code> method:</p><div class="code_container">
<pre class="brush: ruby; gutter: false; toolbar: false">
class Product < ApplicationRecord
has_many :games
end
class Game < ApplicationRecord
belongs_to :product, touch: true
end
</pre>
</div>
<p>With <code>touch</code> set to <code>true</code>, any action which changes <code>updated_at</code> for a game
record will also change it for the associated product, thereby expiring the
cache.</p><h4 id="shared-partial-caching"><a class="anchorlink" href="#shared-partial-caching">1.5 Shared Partial Caching</a></h4><p>It is possible to share partials and associated caching between files with different mime types. For example shared partial caching allows template writers to share a partial between HTML and JavaScript files. When templates are collected in the template resolver file paths they only include the template language extension and not the mime type. Because of this templates can be used for multiple mime types. Both HTML and JavaScript requests will respond to the following code:</p><div class="code_container">
<pre class="brush: ruby; gutter: false; toolbar: false">
render(partial: 'hotels/hotel', collection: @hotels, cached: true)
</pre>
</div>
<p>Will load a file named <code>hotels/hotel.erb</code>.</p><p>Another option is to include the full filename of the partial to render.</p><div class="code_container">
<pre class="brush: ruby; gutter: false; toolbar: false">
render(partial: 'hotels/hotel.html.erb', collection: @hotels, cached: true)
</pre>
</div>
<p>Will load a file named <code>hotels/hotel.html.erb</code> in any file mime type, for example you could include this partial in a JavaScript file.</p><h4 id="managing-dependencies"><a class="anchorlink" href="#managing-dependencies">1.6 Managing dependencies</a></h4><p>In order to correctly invalidate the cache, you need to properly define the
caching dependencies. Rails is clever enough to handle common cases so you don't
have to specify anything. However, sometimes, when you're dealing with custom
helpers for instance, you need to explicitly define them.</p><h5 id="implicit-dependencies"><a class="anchorlink" href="#implicit-dependencies">1.6.1 Implicit dependencies</a></h5><p>Most template dependencies can be derived from calls to <code>render</code> in the template
itself. Here are some examples of render calls that <code>ActionView::Digestor</code> knows
how to decode:</p><div class="code_container">
<pre class="brush: ruby; gutter: false; toolbar: false">
render partial: "comments/comment", collection: commentable.comments
render "comments/comments"
render 'comments/comments'
render('comments/comments')
render "header" translates to render("comments/header")
render(@topic) translates to render("topics/topic")
render(topics) translates to render("topics/topic")
render(message.topics) translates to render("topics/topic")
</pre>
</div>
<p>On the other hand, some calls need to be changed to make caching work properly.
For instance, if you're passing a custom collection, you'll need to change:</p><div class="code_container">
<pre class="brush: ruby; gutter: false; toolbar: false">
render @project.documents.where(published: true)
</pre>
</div>
<p>to:</p><div class="code_container">
<pre class="brush: ruby; gutter: false; toolbar: false">
render partial: "documents/document", collection: @project.documents.where(published: true)
</pre>
</div>
<h5 id="explicit-dependencies"><a class="anchorlink" href="#explicit-dependencies">1.6.2 Explicit dependencies</a></h5><p>Sometimes you'll have template dependencies that can't be derived at all. This
is typically the case when rendering happens in helpers. Here's an example:</p><div class="code_container">
<pre class="brush: ruby; html-script: true; gutter: false; toolbar: false">
<%= render_sortable_todolists @project.todolists %>
</pre>
</div>
<p>You'll need to use a special comment format to call those out:</p><div class="code_container">
<pre class="brush: ruby; html-script: true; gutter: false; toolbar: false">
<%# Template Dependency: todolists/todolist %>
<%= render_sortable_todolists @project.todolists %>
</pre>
</div>
<p>In some cases, like a single table inheritance setup, you might have a bunch of
explicit dependencies. Instead of writing every template out, you can use a
wildcard to match any template in a directory:</p><div class="code_container">
<pre class="brush: ruby; html-script: true; gutter: false; toolbar: false">
<%# Template Dependency: events/* %>
<%= render_categorizable_events @person.events %>
</pre>
</div>
<p>As for collection caching, if the partial template doesn't start with a clean
cache call, you can still benefit from collection caching by adding a special
comment format anywhere in the template, like:</p><div class="code_container">
<pre class="brush: ruby; html-script: true; gutter: false; toolbar: false">
<%# Template Collection: notification %>
<% my_helper_that_calls_cache(some_arg, notification) do %>
<%= notification.name %>
<% end %>
</pre>
</div>
<h5 id="external-dependencies"><a class="anchorlink" href="#external-dependencies">1.6.3 External dependencies</a></h5><p>If you use a helper method, for example, inside a cached block and you then update
that helper, you'll have to bump the cache as well. It doesn't really matter how
you do it, but the MD5 of the template file must change. One recommendation is to
simply be explicit in a comment, like:</p><div class="code_container">
<pre class="brush: ruby; html-script: true; gutter: false; toolbar: false">
<%# Helper Dependency Updated: Jul 28, 2015 at 7pm %>
<%= some_helper_method(person) %>
</pre>
</div>
<h4 id="low-level-caching"><a class="anchorlink" href="#low-level-caching">1.7 Low-Level Caching</a></h4><p>Sometimes you need to cache a particular value or query result instead of caching view fragments. Rails' caching mechanism works great for storing <strong>any</strong> kind of information.</p><p>The most efficient way to implement low-level caching is using the <code>Rails.cache.fetch</code> method. This method does both reading and writing to the cache. When passed only a single argument, the key is fetched and value from the cache is returned. If a block is passed, that block will be executed in the event of a cache miss. The return value of the block will be written to the cache under the given cache key, and that return value will be returned. In case of cache hit, the cached value will be returned without executing the block.</p><p>Consider the following example. An application has a <code>Product</code> model with an instance method that looks up the product's price on a competing website. The data returned by this method would be perfect for low-level caching:</p><div class="code_container">
<pre class="brush: ruby; gutter: false; toolbar: false">
class Product < ApplicationRecord
def competing_price
Rails.cache.fetch("#{cache_key_with_version}/competing_price", expires_in: 12.hours) do
Competitor::API.find_price(id)
end
end
end
</pre>
</div>
<div class="note"><p>Notice that in this example we used the <code>cache_key_with_version</code> method, so the resulting cache key will be something like <code>products/233-20140225082222765838000/competing_price</code>. <code>cache_key_with_version</code> generates a string based on the model's <code>id</code> and <code>updated_at</code> attributes. This is a common convention and has the benefit of invalidating the cache whenever the product is updated. In general, when you use low-level caching for instance level information, you need to generate a cache key.</p></div><h4 id="sql-caching"><a class="anchorlink" href="#sql-caching">1.8 SQL Caching</a></h4><p>Query caching is a Rails feature that caches the result set returned by each
query. If Rails encounters the same query again for that request, it will use
the cached result set as opposed to running the query against the database
again.</p><p>For example:</p><div class="code_container">
<pre class="brush: ruby; gutter: false; toolbar: false">
class ProductsController < ApplicationController
def index
# Run a find query
@products = Product.all
...
# Run the same query again
@products = Product.all
end
end
</pre>
</div>
<p>The second time the same query is run against the database, it's not actually going to hit the database. The first time the result is returned from the query it is stored in the query cache (in memory) and the second time it's pulled from memory.</p><p>However, it's important to note that query caches are created at the start of
an action and destroyed at the end of that action and thus persist only for the
duration of the action. If you'd like to store query results in a more
persistent fashion, you can with low level caching.</p><h3 id="cache-stores"><a class="anchorlink" href="#cache-stores">2 Cache Stores</a></h3><p>Rails provides different stores for the cached data (apart from SQL and page
caching).</p><h4 id="configuration"><a class="anchorlink" href="#configuration">2.1 Configuration</a></h4><p>You can set up your application's default cache store by setting the
<code>config.cache_store</code> configuration option. Other parameters can be passed as
arguments to the cache store's constructor:</p><div class="code_container">
<pre class="brush: ruby; gutter: false; toolbar: false">
config.cache_store = :memory_store, { size: 64.megabytes }
</pre>
</div>
<div class="note"><p>Alternatively, you can call <code>ActionController::Base.cache_store</code> outside of a configuration block.</p></div><p>You can access the cache by calling <code>Rails.cache</code>.</p><h4 id="activesupport-cache-store"><a class="anchorlink" href="#activesupport-cache-store">2.2 ActiveSupport::Cache::Store</a></h4><p>This class provides the foundation for interacting with the cache in Rails. This is an abstract class and you cannot use it on its own. Rather you must use a concrete implementation of the class tied to a storage engine. Rails ships with several implementations documented below.</p><p>The main methods to call are <code>read</code>, <code>write</code>, <code>delete</code>, <code>exist?</code>, and <code>fetch</code>. The fetch method takes a block and will either return an existing value from the cache, or evaluate the block and write the result to the cache if no value exists.</p><p>There are some common options that can be used by all cache implementations. These can be passed to the constructor or the various methods to interact with entries.</p>
<ul>
<li><p><code>:namespace</code> - This option can be used to create a namespace within the cache store. It is especially useful if your application shares a cache with other applications.</p></li>
<li><p><code>:compress</code> - Enabled by default. Compresses cache entries so more data can be stored in the same memory footprint, leading to fewer cache evictions and higher hit rates.</p></li>
<li><p><code>:compress_threshold</code> - Defaults to 1kB. Cache entries larger than this threshold, specified in bytes, are compressed.</p></li>
<li><p><code>:expires_in</code> - This option sets an expiration time in seconds for the cache entry, if the cache store supports it, when it will be automatically removed from the cache.</p></li>
<li><p><code>:race_condition_ttl</code> - This option is used in conjunction with the <code>:expires_in</code> option. It will prevent race conditions when cache entries expire by preventing multiple processes from simultaneously regenerating the same entry (also known as the dog pile effect). This option sets the number of seconds that an expired entry can be reused while a new value is being regenerated. It's a good practice to set this value if you use the <code>:expires_in</code> option.</p></li>
</ul>
<h5 id="custom-cache-stores"><a class="anchorlink" href="#custom-cache-stores">2.2.1 Custom Cache Stores</a></h5><p>You can create your own custom cache store by simply extending
<code>ActiveSupport::Cache::Store</code> and implementing the appropriate methods. This way,
you can swap in any number of caching technologies into your Rails application.</p><p>To use a custom cache store, simply set the cache store to a new instance of your
custom class.</p><div class="code_container">
<pre class="brush: ruby; gutter: false; toolbar: false">
config.cache_store = MyCacheStore.new
</pre>
</div>
<h4 id="activesupport-cache-memorystore"><a class="anchorlink" href="#activesupport-cache-memorystore">2.3 ActiveSupport::Cache::MemoryStore</a></h4><p>This cache store keeps entries in memory in the same Ruby process. The cache
store has a bounded size specified by sending the <code>:size</code> option to the
initializer (default is 32Mb). When the cache exceeds the allotted size, a
cleanup will occur and the least recently used entries will be removed.</p><div class="code_container">
<pre class="brush: ruby; gutter: false; toolbar: false">
config.cache_store = :memory_store, { size: 64.megabytes }
</pre>
</div>
<p>If you're running multiple Ruby on Rails server processes (which is the case
if you're using Phusion Passenger or puma clustered mode), then your Rails server
process instances won't be able to share cache data with each other. This cache
store is not appropriate for large application deployments. However, it can
work well for small, low traffic sites with only a couple of server processes,
as well as development and test environments.</p><p>New Rails projects are configured to use this implementation in development environment by default.</p><div class="note"><p>Since processes will not share cache data when using <code>:memory_store</code>,
it will not be possible to manually read, write, or expire the cache via the Rails console.</p></div><h4 id="activesupport-cache-filestore"><a class="anchorlink" href="#activesupport-cache-filestore">2.4 ActiveSupport::Cache::FileStore</a></h4><p>This cache store uses the file system to store entries. The path to the directory where the store files will be stored must be specified when initializing the cache.</p><div class="code_container">
<pre class="brush: ruby; gutter: false; toolbar: false">
config.cache_store = :file_store, "/path/to/cache/directory"
</pre>
</div>
<p>With this cache store, multiple server processes on the same host can share a
cache. This cache store is appropriate for low to medium traffic sites that are
served off one or two hosts. Server processes running on different hosts could
share a cache by using a shared file system, but that setup is not recommended.</p><p>As the cache will grow until the disk is full, it is recommended to
periodically clear out old entries.</p><p>This is the default cache store implementation (at <code>"#{root}/tmp/cache/"</code>) if
no explicit <code>config.cache_store</code> is supplied.</p><h4 id="activesupport-cache-memcachestore"><a class="anchorlink" href="#activesupport-cache-memcachestore">2.5 ActiveSupport::Cache::MemCacheStore</a></h4><p>This cache store uses Danga's <code>memcached</code> server to provide a centralized cache for your application. Rails uses the bundled <code>dalli</code> gem by default. This is currently the most popular cache store for production websites. It can be used to provide a single, shared cache cluster with very high performance and redundancy.</p><p>When initializing the cache, you need to specify the addresses for all
memcached servers in your cluster. If none are specified, it will assume
memcached is running on localhost on the default port, but this is not an ideal
setup for larger sites.</p><p>The <code>write</code> and <code>fetch</code> methods on this cache accept two additional options that take advantage of features specific to memcached. You can specify <code>:raw</code> to send a value directly to the server with no serialization. The value must be a string or number. You can use memcached direct operations like <code>increment</code> and <code>decrement</code> only on raw values. You can also specify <code>:unless_exist</code> if you don't want memcached to overwrite an existing entry.</p><div class="code_container">
<pre class="brush: ruby; gutter: false; toolbar: false">
config.cache_store = :mem_cache_store, "cache-1.example.com", "cache-2.example.com"
</pre>
</div>
<h4 id="activesupport-cache-rediscachestore"><a class="anchorlink" href="#activesupport-cache-rediscachestore">2.6 ActiveSupport::Cache::RedisCacheStore</a></h4><p>The Redis cache store takes advantage of Redis support for automatic eviction
when it reaches max memory, allowing it to behave much like a Memcached cache server.</p><p>Deployment note: Redis doesn't expire keys by default, so take care to use a
dedicated Redis cache server. Don't fill up your persistent-Redis server with
volatile cache data! Read the
<a href="https://redis.io/topics/lru-cache">Redis cache server setup guide</a> in detail.</p><p>For a cache-only Redis server, set <code>maxmemory-policy</code> to one of the variants of allkeys.
Redis 4+ supports least-frequently-used eviction (<code>allkeys-lfu</code>), an excellent
default choice. Redis 3 and earlier should use least-recently-used eviction (<code>allkeys-lru</code>).</p><p>Set cache read and write timeouts relatively low. Regenerating a cached value
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.</p><p>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.</p><p>Cache reads and writes never raise exceptions; they just return <code>nil</code> instead,
behaving as if there was nothing in the cache. To gauge whether your cache is
hitting exceptions, you may provide an <code>error_handler</code> to report to an
exception gathering service. It must accept three keyword arguments: <code>method</code>,
the cache store method that was originally called; <code>returning</code>, the value that
was returned to the user, typically <code>nil</code>; and <code>exception</code>, the exception that
was rescued.</p><p>To get started, add the redis gem to your Gemfile:</p><div class="code_container">
<pre class="brush: ruby; gutter: false; toolbar: false">
gem 'redis'
</pre>
</div>
<p>You can enable support for the faster <a href="https://github.com/redis/hiredis">hiredis</a>
connection library by additionally adding its ruby wrapper to your Gemfile:</p><div class="code_container">
<pre class="brush: ruby; gutter: false; toolbar: false">
gem 'hiredis'
</pre>
</div>
<p>Redis cache store will automatically require & use hiredis if available. No further
configuration is needed.</p><p>Finally, add the configuration in the relevant <code>config/environments/*.rb</code> file:</p><div class="code_container">
<pre class="brush: ruby; gutter: false; toolbar: false">
config.cache_store = :redis_cache_store, { url: ENV['REDIS_URL'] }
</pre>
</div>
<p>A more complex, production Redis cache store may look something like this:</p><div class="code_container">
<pre class="brush: ruby; gutter: false; toolbar: false">
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
reconnect_attempts: 1, # Defaults to 0
error_handler: -> (method:, returning:, exception:) {
# Report errors to Sentry as warnings
Raven.capture_exception exception, level: 'warning',
tags: { method: method, returning: returning }
}
}
</pre>
</div>
<h4 id="activesupport-cache-nullstore"><a class="anchorlink" href="#activesupport-cache-nullstore">2.7 ActiveSupport::Cache::NullStore</a></h4><p>This cache store implementation is meant to be used only in development or test environments and it never stores anything. This can be very useful in development when you have code that interacts directly with <code>Rails.cache</code> but caching may interfere with being able to see the results of code changes. With this cache store, all <code>fetch</code> and <code>read</code> operations will result in a miss.</p><div class="code_container">
<pre class="brush: ruby; gutter: false; toolbar: false">
config.cache_store = :null_store
</pre>
</div>
<h3 id="cache-keys"><a class="anchorlink" href="#cache-keys">3 Cache Keys</a></h3><p>The keys used in a cache can be any object that responds to either <code>cache_key</code> or
<code>to_param</code>. You can implement the <code>cache_key</code> method on your classes if you need
to generate custom keys. Active Record will generate keys based on the class name
and record id.</p><p>You can use Hashes and Arrays of values as cache keys.</p><div class="code_container">
<pre class="brush: ruby; gutter: false; toolbar: false">
# This is a legal cache key
Rails.cache.read(site: "mysite", owners: [owner_1, owner_2])
</pre>
</div>
<p>The keys you use on <code>Rails.cache</code> will not be the same as those actually used with
the storage engine. They may be modified with a namespace or altered to fit
technology backend constraints. This means, for instance, that you can't save
values with <code>Rails.cache</code> and then try to pull them out with the <code>dalli</code> gem.
However, you also don't need to worry about exceeding the memcached size limit or
violating syntax rules.</p><h3 id="conditional-get-support"><a class="anchorlink" href="#conditional-get-support">4 Conditional GET support</a></h3><p>Conditional GETs are a feature of the HTTP specification that provide a way for web servers to tell browsers that the response to a GET request hasn't changed since the last request and can be safely pulled from the browser cache.</p><p>They work by using the <code>HTTP_IF_NONE_MATCH</code> and <code>HTTP_IF_MODIFIED_SINCE</code> headers to pass back and forth both a unique content identifier and the timestamp of when the content was last changed. If the browser makes a request where the content identifier (etag) or last modified since timestamp matches the server's version then the server only needs to send back an empty response with a not modified status.</p><p>It is the server's (i.e. our) responsibility to look for a last modified timestamp and the if-none-match header and determine whether or not to send back the full response. With conditional-get support in Rails this is a pretty easy task:</p><div class="code_container">
<pre class="brush: ruby; gutter: false; toolbar: false">
class ProductsController < ApplicationController
def show
@product = Product.find(params[:id])
# If the request is stale according to the given timestamp and etag value
# (i.e. it needs to be processed again) then execute this block
if stale?(last_modified: @product.updated_at.utc, etag: @product.cache_key_with_version)
respond_to do |wants|
# ... normal response processing
end
end
# If the request is fresh (i.e. it's not modified) then you don't need to do
# anything. The default render checks for this using the parameters
# used in the previous call to stale? and will automatically send a
# :not_modified. So that's it, you're done.
end
end
</pre>
</div>
<p>Instead of an options hash, you can also simply pass in a model. Rails will use the <code>updated_at</code> and <code>cache_key_with_version</code> methods for setting <code>last_modified</code> and <code>etag</code>:</p><div class="code_container">
<pre class="brush: ruby; gutter: false; toolbar: false">
class ProductsController < ApplicationController
def show
@product = Product.find(params[:id])
if stale?(@product)
respond_to do |wants|
# ... normal response processing
end
end
end
end
</pre>
</div>
<p>If you don't have any special response processing and are using the default rendering mechanism (i.e. you're not using <code>respond_to</code> or calling render yourself) then you've got an easy helper in <code>fresh_when</code>:</p><div class="code_container">
<pre class="brush: ruby; gutter: false; toolbar: false">
class ProductsController < ApplicationController
# This will automatically send back a :not_modified if the request is fresh,
# and will render the default template (product.*) if it's stale.
def show
@product = Product.find(params[:id])
fresh_when last_modified: @product.published_at.utc, etag: @product
end
end
</pre>
</div>
<p>Sometimes we want to cache response, for example a static page, that never gets
expired. To achieve this, we can use <code>http_cache_forever</code> helper and by doing
so browser and proxies will cache it indefinitely.</p><p>By default cached responses will be private, cached only on the user's web
browser. To allow proxies to cache the response, set <code>public: true</code> to indicate
that they can serve the cached response to all users.</p><p>Using this helper, <code>last_modified</code> header is set to <code>Time.new(2011, 1, 1).utc</code>
and <code>expires</code> header is set to a 100 years.</p><div class="warning"><p>Use this method carefully as browser/proxy won't be able to invalidate
the cached response unless browser cache is forcefully cleared.</p></div><div class="code_container">
<pre class="brush: ruby; gutter: false; toolbar: false">
class HomeController < ApplicationController
def index
http_cache_forever(public: true) do
render
end
end
end
</pre>
</div>
<h4 id="strong-v-s-weak-etags"><a class="anchorlink" href="#strong-v-s-weak-etags">4.1 Strong v/s Weak ETags</a></h4><p>Rails generates weak ETags by default. Weak ETags allow semantically equivalent
responses to have the same ETags, even if their bodies do not match exactly.
This is useful when we don't want the page to be regenerated for minor changes in
response body.</p><p>Weak ETags have a leading <code>W/</code> to differentiate them from strong ETags.</p><div class="code_container">
<pre class="brush: plain; gutter: false; toolbar: false">
W/"618bbc92e2d35ea1945008b42799b0e7" → Weak ETag
"618bbc92e2d35ea1945008b42799b0e7" → Strong ETag
</pre>
</div>
<p>Unlike weak ETag, strong ETag implies that response should be exactly the same
and byte by byte identical. Useful when doing Range requests within a
large video or PDF file. Some CDNs support only strong ETags, like Akamai.
If you absolutely need to generate a strong ETag, it can be done as follows.</p><div class="code_container">
<pre class="brush: ruby; gutter: false; toolbar: false">
class ProductsController < ApplicationController
def show
@product = Product.find(params[:id])
fresh_when last_modified: @product.published_at.utc, strong_etag: @product
end
end
</pre>
</div>
<p>You can also set the strong ETag directly on the response.</p><div class="code_container">
<pre class="brush: ruby; gutter: false; toolbar: false">
response.strong_etag = response.body # => "618bbc92e2d35ea1945008b42799b0e7"
</pre>
</div>
<h3 id="caching-in-development"><a class="anchorlink" href="#caching-in-development">5 Caching in Development</a></h3><p>It's common to want to test the caching strategy of your application
in development mode. Rails provides the rails command <code>dev:cache</code> to
easily toggle caching on/off.</p><div class="code_container">
<pre class="brush: plain; gutter: false; toolbar: false">
$ rails dev:cache
Development mode is now being cached.
$ rails dev:cache
Development mode is no longer being cached.
</pre>
</div>
<h3 id="references"><a class="anchorlink" href="#references">6 References</a></h3>
<ul>
<li><a href="https://signalvnoise.com/posts/3113-how-key-based-cache-expiration-works">DHH's article on key-based expiration</a></li>
<li><a href="http://railscasts.com/episodes/387-cache-digests">Ryan Bates' Railscast on cache digests</a></li>
</ul>
<h3>Feedback</h3>
<p>
You're encouraged to help improve the quality of this guide.
</p>
<p>
Please contribute if you see any typos or factual errors.
To get started, you can read our <a href="https://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html#contributing-to-the-rails-documentation">documentation contributions</a> section.
</p>
<p>
You may also find incomplete content or stuff that is not up to date.
Please do add any missing documentation for master. Make sure to check
<a href="https://edgeguides.rubyonrails.org">Edge Guides</a> first to verify
if the issues are already fixed or not on the master branch.
Check the <a href="ruby_on_rails_guides_guidelines.html">Ruby on Rails Guides Guidelines</a>
for style and conventions.
</p>
<p>
If for whatever reason you spot something to fix but cannot patch it yourself, please
<a href="https://github.com/rails/rails/issues">open an issue</a>.
</p>
<p>And last but not least, any kind of discussion regarding Ruby on Rails
documentation is very welcome on the <a href="https://groups.google.com/forum/#!forum/rubyonrails-docs">rubyonrails-docs mailing list</a>.
</p>
</div>
</div>
</div>
<hr class="hide" />
<div id="footer">
<div class="wrapper">
<p>This work is licensed under a <a href="https://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International</a> License</p>
<p>"Rails", "Ruby on Rails", and the Rails logo are trademarks of David Heinemeier Hansson. All rights reserved.</p>
</div>
</div>
</body>
</html>