Skip to content

Speed up your app by caching expensive code in Redis or in the Ruby process itself

License

Notifications You must be signed in to change notification settings

gizm0duck/lawnchair

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Lawnchair

Fully featured caching mechanism for arbitrary pieces of resource expensive ruby code using Redis while being able to optionally store data in the Ruby process itself for maximum efficiency.

Lawnchair includes a Rails view helper that can be used to cache the rendered view code, but other than that everything should work fine in a Merb, Sinatra, or plain old Ruby app.

Installation

sudo gem install lawnchair

Usage Examples

All you really need to do is wrap some expensive piece of Ruby code in the Lawnchair.cache method as a block and it will be evaluated and the return value will cached in the given cache key.

MAKE SURE REDIS SERVER IS RUNNING PRIOR TO TRYING ANYTHING BELOW!!!

First, connect to the Redis database. This would most likely go into an environment.rb.

Lawnchair.connectdb

This will connect to a default database on localhost, if you want to connect to a particular database you can do:

Lawnchair.connectdb(Redis.new(:database => 11, :host => "127.0.0.1", :port => 6379))

Obligatory example:

Lawnchair.cache("cache_key2") do
  # ideally this would be something a little more computationally expensive, but sleep will have to do
  (1..3).inject([]) do
    |set, i| set << Time.now.strftime("%H:%M:%S")
    sleep 1
    set
  end
end

The return value is exactly what you think it should be

["12:26:08", "12:26:09", "12:26:10"]

Now, since it is cached, any time this block method is called (for the next 60 minutes) it will return those values. also, you will note it comes back instantly, instead of waiting on those sleeps.

If an hour is too long, or short for the cache key expiration you can set that to anything you want using the :expires_in hash key and entering a time in seconds

Lawnchair.cache("cache_key", :expires_in => 1.day) do
  # expensive code to be cached for 24 hours
end

Available options:

  • :expires_in - takes a time in seconds and will be set as the ttl on the key (only works for Redis store)

  • :raw - tells the cache not to marshall the data, if you are storing a string value, this is the way to go

  • :in_process - stores the value in memory for as long as the ruby process is running as well as in redis

  • :interpolate - allows you to cache large pieces of data but override sections of it with dynamic content

Interpolating Data

Caching large pieces of the page can prove to be difficult in a highly dynamic environment. Content interpolation makes this easier to deal with common things such as user names, timestamps, flash messages and more.

cached_result = Lawnchair.cache("cached_time") { "current time: __TIME__" }
=> "current time: __TIME__"

Now let’s interpolate this data with dynamic content.

cached_result = Lawnchair.cache("cached_time", :interpolate => {"__TIME__" => Time.now.to_s}) { "current time: __TIME__" }
=> "current time: Tue Aug 24 16:13:40 -0700 2010"
cached_result = Lawnchair.cache("cached_time", :interpolate => {"__TIME__" => Time.now.to_s}) { "current time: __TIME__" }
=> "current time: Tue Aug 24 16:13:42 -0700 2010"

Notice that the timestamp is different for each call, even though the data is coming out of the cache.

In Process Caching

If you want to get really fancy you can cache the values in process as well as in Redis. This can be a fairly significant win if you are running the Redis server on a different physical machine as all network latency is taken out of the equation, especially if you are hitting a cache key many times on the same request. Also, it’s probably best not to store TONS of keys in there, as your ruby process can bloat fairly quickly if you put everything in there. Also, these will persist as long as the process is running, unless you manually expire it.

Lawnchair.cache("cache_key3", :in_process => true) do
  # expensive code to be cached in process AND in redis
end

This code will get cached in redis as well, so each different process that runs the expensive code in the block will get the value from redis, instead of having to run it to get the value.

Accessing DataStores Directly

There are currently two different storage engines (Redis and InProcess) that you can use either together or independently, depending on your needs. If you want to just store something in process for example you can do

Lawnchair::StorageEngine::InProcess.fetch("cache_key4", :raw => true) do
  # expensive code to be cached in process
end

Also, you can expire a key for a given storage engine directly by calling

Lawnchair::StorageEngine::InProcess.expire!("cache_key3") # For memory store

or

Lawnchair::StorageEngine::Redis.expire!("cache_key3") # For redis store

You can also access any of the methods for a given datastore directly, and choose to expire a key in whatever store you want.

Available methods are:

  • get - get a value for a key

  • set - set a value for a key regardless of whether or not it exists

  • fetch - get a value if it exists for a given key, otherwise set it

  • expire! - forcefully expire a key

  • exists? - check if a given key exists

  • data_store - access the datastore’s values directly like a hash

If you need to flush all the values in the Redis database

Lawnchair.flushdb

Note on Patches/Pull Requests

  • Fork the project.

  • Make your feature addition or bug fix.

  • I will promply ignore anything that is not a refactor that does not have associated specs :)

  • Have fun

Copyright © 2010 Shane Wolf. See LICENSE for details.

Thanks to Tyler Kovacs for the inspiration for content interpolation.

About

Speed up your app by caching expensive code in Redis or in the Ruby process itself

Resources

License

Stars

Watchers

Forks

Packages

No packages published

Languages