Mirror
/
zulip
mirror of https://github.com/zulip/zulip.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

caching docs: Tweak a few things. 

Some claims seemed a little exaggerated or overly
precise.
This commit is contained in:
Steve Howell 2023-07-17 13:50:06 +00:00 committed by Tim Abbott
parent 0a181bca86
commit 031e3ae3f0
1 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
docs/subsystems/caching.md
View File

@ -10,9 +10,9 @@ caching).
On the backend, Zulip uses `memcached`, a popular key-value store, for On the backend, Zulip uses `memcached`, a popular key-value store, for
caching. Our `memcached` caching helps let us optimize Zulip's caching. Our `memcached` caching helps let us optimize Zulip's
performance and scalability, since most requests don't need to talk to performance and scalability, since we often avoid overhead related
the database (which, even for a trivial query with everything on the to database requests. With Django a typical trivial query can
same machine, usually takes 3-10x as long as a memcached fetch). often take 3-10x as long as a memcached fetch.
We use Django's built-in caching integration to manage talking to We use Django's built-in caching integration to manage talking to
memcached, and then a small application-layer library memcached, and then a small application-layer library
@ -32,10 +32,10 @@ amount of Zulip's core caching code correctly, then the code most developers
naturally write will both benefit from caching and not create any cache naturally write will both benefit from caching and not create any cache
consistency problems. consistency problems.
The overall result of this design is that in the vast majority of The overall result of this design is that for many places in the
Zulip's Django codebase, all one needs to do is call the standard Zulip's Django codebase, all one needs to do is call the standard
accessor functions for data (like `get_user` or `get_stream` to fetch accessor functions for data (like `get_user` to fetch
user and stream objects, or for view code, functions like user objects, or, for view code, functions like
`access_stream_by_id`, which checks permissions), and everything will `access_stream_by_id`, which checks permissions), and everything will
work great. The data fetches automatically benefit from `memcached` work great. The data fetches automatically benefit from `memcached`
caching, since those accessor methods have already been written to caching, since those accessor methods have already been written to
@ -96,7 +96,7 @@ This decorator implements a pretty classic caching paradigm:
`KEY_PREFIX` is rotated every time we deploy to production; see `KEY_PREFIX` is rotated every time we deploy to production; see
below for details. below for details.
We use this decorator in more than 30 places in Zulip, and it saves a We use this decorator in about 30 places in Zulip, and it saves a
huge amount of otherwise very self-similar caching code. huge amount of otherwise very self-similar caching code.
### Cautions ### Cautions