A fundamental trade-off in dynamic Web sites is, well, they\u2019re dynamic. Each time a user requests a page, the Web server makes all sorts of calculations, from database queries to template rendering to business logic to creating the page that your site\u2019s visitors see. This is a lot more expensive, from a processing-overhead perspective, than your standard read-a-file-off-the-filesystem server arrangement.<\/p>\n
For most Web applications, this overhead isn\u2019t a big deal. Most Web applications aren\u2019t washingtonpost.com or slashdot.org; they\u2019re simply small- to medium-sized sites with so-so traffic.<\/p>\n
But for medium- to high-traffic sites, it\u2019s essential to cut as much overhead as possible.<\/p>\n
That\u2019s where caching comes in. To cache something is to save the result of an expensive calculation so that you don\u2019t have to perform the calculation next time. Here\u2019s some pseudocode explaining how this would work for a dynamically generated Web page:<\/p>\n
given a URL, try finding that page in the cache if the page is in the<\/p>\n
cache:<\/p>\n
return the cached page<\/p>\n
else:<\/p>\n
generate the page<\/p>\n
save the generated page in the cache (for next time)<\/p>\n
return the generated page<\/p>\n
Django comes with a robust cache system that lets you save dynamic pages so they don\u2019t have to be calculated for each request. For convenience, Django offers different levels of cache granularity: You can cache the output of specific views, you can cache only the pieces that are difficult to produce, or you can cache your entire site.<\/p>\n
Django also works well with downstream caches, such as Squid and browser-based caches. These are the types of caches that you don\u2019t directly control, but to which you can provide hints (via HTTP headers) about which parts of your site should be cached, and how.<\/p>\n\n\n