Low-level caching with Rails.cache - Performance & Optimization

Performance: Low-level caching with Rails.cache

HIGH IMPACT

Improves page load speed by storing and reusing expensive data or computations, reducing database queries and server processing time.

Caching expensive database query results to speed up page rendering

Ruby on Rails

def expensive_data
  Rails.cache.fetch('expensive_data_key', expires_in: 10.minutes) do
    Model.where(condition: true).to_a
  end
end

Caches the query result for 10 minutes, serving cached data instantly on repeated requests.

📈 Performance GainReduces database queries to zero during cache lifetime, cutting response time by 80-95%

Caching expensive database query results to speed up page rendering

Ruby on Rails

def expensive_data
  Model.where(condition: true).to_a
end

Runs the database query on every request, causing slow response and high server load.

📉 Performance CostBlocks rendering for 50-200ms per request depending on query complexity

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
No caching, query on every request	N/A (server-side)	N/A	N/A	[X] Bad
Using Rails.cache to store query results	N/A (server-side)	N/A	N/A	[OK] Good

Rendering Pipeline

Rails.cache stores data in memory or external stores, so when a request comes, the app can skip expensive data fetching and directly serve cached content, reducing server processing before HTML is sent to the browser.

→Server Processing

→Database Query

→HTML Generation

⚠️ BottleneckDatabase Query and Server Processing

Core Web Vital Affected

LCP

Improves page load speed by storing and reusing expensive data or computations, reducing database queries and server processing time.

Optimization Tips

1Cache expensive queries or computations to reduce server load.

2Use meaningful cache keys and set expiration times to keep data fresh.

3Monitor cache hit rates and response times to ensure caching is effective.

Performance Quiz - 3 Questions

What is the main performance benefit of using Rails.cache for expensive queries?

A Adds extra network requests

B Increases database query frequency

C Reduces server processing time by reusing stored data

D Slows down page rendering

DevTools: Network

How to check: Open DevTools, go to Network tab, reload the page and observe response times and number of requests to the server.

What to look for: Faster response times and fewer database query logs on server indicate effective caching.

Practice

1. What is the main purpose of using Rails.cache in a Rails application?

easy

A. To permanently save data to the database

B. To store data temporarily for faster repeated access

C. To send emails asynchronously

D. To handle user authentication

Solution

1. Step 1: Understand the role of caching

   Caching stores data temporarily to avoid repeating expensive operations.

2. Step 2: Identify what Rails.cache does

   Rails.cache provides a way to store and retrieve data quickly in memory or other stores.

3. Final Answer:

   To store data temporarily for faster repeated access -> Option B

4. Quick Check:

   Caching = Temporary storage for speed [OK]

Hint: Caching speeds up repeated data access by storing it temporarily [OK]

Common Mistakes:

• Confusing caching with permanent database storage
• Thinking caching handles user login
• Assuming caching sends emails

2. Which of the following is the correct syntax to fetch a cached value or compute and store it if missing using Rails.cache?

easy

A. Rails.cache.store(:key, expensive_method)

B. Rails.cache.get(:key) { expensive_method }

C. Rails.cache.fetch(:key) { expensive_method }

D. Rails.cache.read(:key) { expensive_method }

Solution

1. Step 1: Recall the fetch method usage

   Rails.cache.fetch(:key) { block } tries to read the key, or runs the block and stores the result if missing.

2. Step 2: Check other options for correctness

   get, store, and read do not accept a block to compute missing values automatically.

3. Final Answer:

   Rails.cache.fetch(:key) { expensive_method } -> Option C

4. Quick Check:

   Use fetch with block to cache missing data [OK]

Hint: Use fetch with a block to cache or compute missing data [OK]

Common Mistakes:

• Using read or get which don't accept blocks
• Trying to use store with a block
• Confusing fetch with read

3. Given the code below, what will be printed by the second Rails.cache.fetch('counter') call?

count = 0
Rails.cache.fetch('counter') do
  count += 1
end
puts Rails.cache.fetch('counter')

medium

A. nil

B. 0

C. 2

D. 1

Solution

1. Step 1: Understand the first fetch call

   The block runs because 'counter' key is missing, so count increments from 0 to 1 and stores 1.

2. Step 2: Understand the second fetch call

   The key 'counter' exists now, so fetch returns cached value 1 without running the block.

3. Final Answer:

   1 -> Option D

4. Quick Check:

   Cached value returned without block run = 1 [OK]

Hint: Cached value returns without running block again [OK]

Common Mistakes:

• Assuming block runs every time
• Thinking count resets to 0
• Expecting nil if key exists

4. Identify the error in this caching code snippet:

Rails.cache.fetch('user_1') do
  User.find(1)
end
Rails.cache.write('user_1')

medium

A. Calling write without a value argument causes an error

B. fetch block should not call User.find

C. The cache key must be a symbol, not a string

D. write should be called before fetch

Solution

1. Step 1: Analyze the write method usage

   Rails.cache.write requires a key and a value; here only the key is given, missing the value argument.

2. Step 2: Check other options for validity

   Using string keys is valid; fetch block can call User.find; write order is not mandatory here.

3. Final Answer:

   Calling write without a value argument causes an error -> Option A

4. Quick Check:

   write needs key and value [OK]

Hint: write needs both key and value arguments [OK]

Common Mistakes:

• Omitting value in write method
• Thinking keys must be symbols
• Misunderstanding fetch block usage

5. You want to cache a list of products but ensure the cache expires after 10 minutes. Which is the correct way to do this with Rails.cache.fetch?

hard

A. Rails.cache.fetch('products', expires_in: 10.minutes) { Product.all.to_a }

B. Rails.cache.fetch('products', expires: 10) { Product.all }

C. Rails.cache.write('products', Product.all, expires_in: 600)

D. Rails.cache.fetch('products', timeout: 600) { Product.all.to_a }

Solution

1. Step 1: Identify correct option for expiration

   expires_in: 10.minutes is the correct option to set cache expiration time in fetch.

2. Step 2: Check other options for correctness

   expires and timeout are not valid options; write can set expiration but fetch with block is preferred for caching computed data.

3. Final Answer:

   Rails.cache.fetch('products', expires_in: 10.minutes) { Product.all.to_a } -> Option A

4. Quick Check:

   Use expires_in with fetch for expiration [OK]

Hint: Use expires_in option with fetch to set cache lifetime [OK]

Common Mistakes:

• Using wrong option names like expires or timeout
• Not converting ActiveRecord relation to array
• Using write instead of fetch with block