4

In the simplest terms, how do I set up redis for caching on my django project?

I've been trying to figure out caching for the last week now and the pieces are just not falling into place.

What do I need to do to get caching up and running. Just take care of headers and install redis??

The various tutorials and introductions all seem take for granted fundamental steps that are preventing me from understanding how to implement caching. Isn't this ubiquitous? How does someone learn about this?

Matt Parrilla
  • 3,171
  • 6
  • 35
  • 54
  • This has been asked before: http://stackoverflow.com/questions/3801379/how-can-i-use-redis-with-django – jdi Oct 05 '11 at 01:41
  • @jdi I've seen that post (and read the readme it refers to). And read countless articles on google. Like I said, I'm missing something. I need help. I am sorry to ask a question that has been asked, but the answer was not in simple enough terms for me :-/ I need to have this put in even simpler terms. – Matt Parrilla Oct 05 '11 at 02:07
  • for instance, in the readme that was linked (and selected as the answer) for the question you linked above, the word "cache" isn't used once. – Matt Parrilla Oct 05 '11 at 02:12
  • The reason they probably dont use the word "cache" in the redis-py readme is because its not really just a cache. Its an in memory database. One USE of it would be like a cache, and to do that you would make use of setting EXPIRE times on your keys. See my following answer. – jdi Oct 05 '11 at 02:52

1 Answers1

7

Ok, so maybe the connection you are missing is that once you have redis running, and you have the ability to set and get value to and from it using the python http://github.com/andymccurdy/redis-py you can start doing thing like this:

(pseudo-code to keep it simple)

client_request_for_data():
    check if redis has this data already under a specific "key"
       True:
          * GET value from redis using "key"
          * return it!
       False:
          * Do the normal process of building the data
          * SET it into redis with a unique "key", with maybe an EXPIRE time
          * return it!

The idea here being that you start to wrap your existing code in spots where you generate results for the client request, into something that first checks if a key exists and return it if it does.

jdi
  • 90,542
  • 19
  • 167
  • 203
  • aaand . Thanks @jdi, I've spent a few days banging my head against the wall and you just put it all together for me! I'm excited to dig in! – Matt Parrilla Oct 05 '11 at 03:35
  • 1
    No prob! I know how it is. Sometime concepts dont quite click for me as well until somone rephrases or gives me a clear example. – jdi Oct 05 '11 at 04:22
  • Does that mean that every client_request_for_data() function must create its own instance of Redis client? – Régis B. Apr 20 '12 at 22:09
  • @RégisB.: No this doesn't define at all how you actually manage your redis client connection. It could very well be a persistant connection that you keep reusing in a class, or it could be a new connection each time if requests are completely unrelated and you have no way to reuse a persistant connection. This only explains how you would use that connection within a request context to determine if the response is cached or not. – jdi Apr 20 '12 at 22:59
  • Just to state the obvious, actual code needs to be a little more sophisticated than the above pseudocode :) especially in terms of race conditions. There is a race condition between the "check" and the "set" steps in jdi's pseudocode above -- you would not perform separate `GET` and `SET` in the real world! You might do a `SETNX`, or `WATCH` with a `MULTI` transaction. Bottom line, do some Googling of Redis race conditions before you implement this. – Chris Johnson May 12 '14 at 22:24