django-cachalot v2.3.2 Introduction Quick start Limits API Benchmark What could still be done Bug reports, questions, discussion, new features How django-cachalot works Legacy What’s new in django-cachalot? Docs » django-cachalot Edit on GitHub Note You are not reading the most recent version of this documentation. v2.4.1 is the latest version available. django-cachalot Caches your Django ORM queries and automatically invalidates them. Usage pip install django-cachalot Add 'cachalot', to your INSTALLED_APPS If you use multiple servers with a common cache server, :ref:`double check their clock synchronisation <https://django-cachalot.readthedocs.io/en/latest/limits.html#multiple-servers>`_ If you modify data outside Django – typically after restoring a SQL database –, use the :ref:`manage.py command <https://django-cachalot.readthedocs.io/en/latest/quickstart.html#command>`_ Be aware of :ref:`the few other limits <https://django-cachalot.readthedocs.io/en/latest/limits.html#limits>`_ If you use django-debug-toolbar, you can add 'cachalot.panels.CachalotPanel', to your DEBUG_TOOLBAR_PANELS Enjoy! Note: In settings, you can use CACHALOT_UNCACHABLE_TABLES as a frozenset of table names (e.g. “public_test” if public was the app name and test is a model name). Why use cachalot? Check out our comparison Below the tree is an in-depth opinion from the new maintainer: Introduction Should you use it? Features Comparison with similar tools Quick start Requirements Usage Settings manage.py command Template utils Signal Limits High rate of database modifications Redis Memcached Locmem Filebased MySQL Raw SQL queries Multiple servers clock synchronisation Replication server Multiple cache servers for the same database API Benchmark Introduction Conditions Database results Cache results Database detailed results Cache detailed results What could still be done Bug reports, questions, discussion, new features How django-cachalot works Reverse engineering Monkey patching Legacy What’s new in django-cachalot? 2.3.2 2.3.1 2.3.0 2.2.2 2.2.0 2.1.0 2.0.2 2.0.1 2.0.0 1.5.0 1.4.1 1.4.0 1.3.0 1.2.1 1.2.0 1.1.0 1.0.3 1.0.2 1.0.1 1.0.0 1.0.0rc 0.9.0 0.8.1 0.8.0 0.7.0 0.6.0 0.5.0 0.4.1 0.4.0 (install broken) 0.3.0 0.2.0 0.1.0 In-depth opinion (from new maintainer): There are three main third party caches: cachalot, cache-machine, and cache-ops. Which do you use? We suggest a mix: TL;DR Use cachalot for cold or modified <50 times per seconds (Most people should stick with only cachalot since you most likely won’t need to scale to the point of needing cache-machine added to the bowl). If you’re an enterprise that already has huge statistics, then mixing cold caches for cachalot and your hot caches with cache-machine is the best mix. However, when performing joins with select_related and prefetch_related, you can get a nearly 100x speed up for your initial deployment. Recall, cachalot caches THE ENTIRE TABLE. That’s where its inefficiency stems from: if you keep updating the records, then the cachalot constantly invalidates the table and re-caches. Luckily caching is very efficient, it’s just the cache invalidation part that kills all our systems. Look at Note 1 below to see how Reddit deals with it. Cachalot is more-or-less intended for cold caches or “just-right” conditions. If you find a partition library for Django (also authored but work-in-progress by Andrew Chen Wang), then the caching will work better since sharding the cold/accessed-the-least records aren’t invalidated as much. Cachalot is good when there are <50 modifications per second on a hot cached table. This is mostly due to cache invalidation. It’s the same with any cache, which is why we suggest you use cache-machine for hot caches. Cache-machine caches individual objects, taking up more in the memory store but invalidates those individual objects instead of the entire table like cachalot. Yes, the bane of our entire existence lies in cache invalidation and naming variables. Why does cachalot suck when stuck with a huge table that’s modified rapidly? Since you’ve mixed your cold (90% of) with your hot (10% of) records, you’re caching and invalidating an entire table. It’s like trying to boil 1 ton of noodles inside ONE pot instead of 100 pots boiling 1 ton of noodles. Which is more efficient? The splitting up of them. Note 1: My personal experience with caches stems from Reddit’s: https://redditblog.com/2017/01/17/caching-at-reddit/ Next Tilaa Black Friday deals on our independent European public cloud. Cloud VPS for €1 p/m. Join Tilaa Ad by EthicalAds · Monetize your site © Copyright 2014-2016, Bertrand Bordage Revision 72be2c07. Built with Sphinx using a theme provided by Read the Docs. Read the Docs v: v2.3.2