[Django]-Attribute Cache in Django – What's the point?

by

4👍

✅

I don’t know why this is an IntegerField; it looks like it definitely should be a ForeignKey(User) field–you lose things like select_related() here and other things because of that, too.

As to the caching, many databases don’t cache results–they (or rather, the OS) will cache the data on disk needed to get the result, so looking it up a second time should be faster than the first, but it’ll still take work.

It also still takes a database round-trip to look it up. In my experience, with Django, doing an item lookup can take around 0.5 to 1ms, for an SQL command to a local Postgresql server plus sometimes nontrivial overhead of QuerySet. 1ms is a lot if you don’t need it–do that a few times and you can turn a 30ms request into a 35ms request.

If your SQL server isn’t local and you actually have network round-trips to deal with, the numbers get bigger.

Finally, people generally expect accessing a property to be fast; when they’re complex enough to cause SQL queries, caching the result is generally a good idea.

👤Glenn Maynard

3👍

Although databases do cache things internally, there’s still an overhead in going back to the db every time you want to check the value of a related field – setting up the query within Django, the network latency in connecting to the db and returning the data over the network, instantiating the object in Django, etc. If you know the data hasn’t changed in the meantime – and within the context of a single web request you probably don’t care if it has – it makes much more sense to get the data once and cache it, rather than querying it every single time.

One of the applications I work on has an extremely complex home page containing a huge amount of data. Previously it was carrying out over 400 db queries to render. I’ve refactored it now so it ‘only’ uses 80, using very similar techniques to the one you’ve posted, and you’d better believe that it gives a massive performance boost.

👤Daniel Roseman

Leave a comment