加速Plone之降龙十八掌——之二
加速Plone之降龙十八掌——之二
http://www.315ok.org/blogfolder/4
http://www.315ok.org/logo.png
加速Plone之降龙十八掌——之二
加速Plone之降龙十八掌——之二
More techniques
Will touch on a few more approaches, but not in depth
● Tune the ZODB/ZEO object caches
– speeds up Zserver
● Load balancing
– reduces page rendering times under load
● Optimize your code
– reduces page rendering time
● Cache intermediate code results
– reduces page rendering time
Strategy 1: Cache static content in browser
● When user visits site, content stored in their browser's cache
– HTTP headers tell how long to cache
● Subsequent requests pulled from local cache rather than server
● Most useful for static content that is viewed frequently
– Images, CSS, JS
HTTP headers
● Understand HTTP headers to do caching right
● Good tutorial at
http://www.web-caching.com/mnot_tutorial/
HTTP header basics
● Will use both HTTP 1.0 and 1.1 headers in case ancient clients visit
● HTTP 1.0 headers
– Expires: [date and time]
● Browser will cache if date is in the future
– Last-Modified: [date and time]
● Complicated heuristics for image caching based on Last-Modified header absent more explicit info
● The longer your image has been unchanged, the longer the browser will cache it
– Headache: both require correct client clock
HTTP header basics
● HTTP 1.1: much more fine-grained control
– Cache-Control: [tons of options]
● Most important for our purposes:
– max-age=N
● browser will cache your content for N seconds
● preferable to Expires because makes no assumptions about client clock
– public
● tells browser OK to cache even when it might not otherwise
● Cache-Control options not to include (for now):
– no-cache, no-store, must-revalidate, private
Setting HTTP headers
● AcceleratedHTTPCacheManager
– Part of CMF - sets cache headers for skin elements
– Used by Plone OOTB to set headers for static stuff
– HTTPCache
– Associate template / image / file with HTTPCache
using metadata
– cache=HTTPCache
● One of the 10 places that headers get tweaked
CacheFu and headers
● CacheFu consolidates header-setting
– Most headers set in CachingPolicyManager
– Allows for much finer-grained control
● We will need it!
● CacheFu replaces HTTPCache with a PolicyHTTPCacheManager
– Farms HTTPCache's old job out to
CachingPolicyManager
● Sets better default cache timeout
– 24 hours instead of 1 hour
CachingPolicyManager
● Take a look in ZMI: caching_policy_manager
– Details: Definitive Guide to Plone, Chapter 14
– http://docs.neuroinf.de/PloneBook/ch14.rst
● Container full of header setting policies
– Each policy has a predicate
– Pages to be rendered walk through policies until they hit a true predicate, then headers are set
● You will not need to look in here much
– Most of policy-choosing logic is elsewhere
Caching Policy
● CacheFu assigns the cache_in_browser policy to items associated with HTTPCache
● cache_in_browser policy:
– key items:
● last-modified = python:object.modified()
● max-age = 86400
– 86400 secs = 24 hours
● s-max-age = 86400
– instructions to squid
● public
– Use cached items even in situations when maybe not OK (e.g. when authorized, possibly with https connections, etc)
Caching in Browser
● cache_in_browser policy gives us the least control
– Once something is in the browser, it is stuck there
– Browser won't check for anything newer for 24 hours
● Takes a big load off server, though
– Safe to use this policy for things that rarely change
– If you plan to change stuff, consider:
● lower max-age time limit the day before
● increase again when you are done
Testing the headers
● LiveHTTPHeaders plug-in for FireFox
– Your new best friend
● Invaluable for testing caching
● Shows all request and response headers
● Tip: clear your browser cache manually before starting a session
● Let's take a look
ResourceRegistries
● Most of the content associated with HTTPCache is images
● JS and CSS used to be, but no more
● ResourceRegistries are the new way to go
– In the ZMI:
● portal_css
● portal_javascripts
– Let's take a look
ResourceRegistries
● Look at portal_css
● Lots of CSS files registered
● Line in main_template pulls in all registered CSS in the page <head> section
● Options:
– Enabled: lets you turn on/off file inclusion
– TAL condition: lets you conditionally include
– Merging allowed: can file be merged?
– Caching allowed: used for RR's internal caching (which we bypass)
ResourceRegistries
● RR serves up a set of merged CSS files with URLs
like this:
– portal_css/Default%20Skin/ploneStyles1234.css
– Skin name is in the URL so that different skins have distinct URLS
● Avoids user retrieving cached css file for one skin when
viewing a different skin
– Number in filename is version number
● every time you hit Save button, version number changes
ResourceRegistries
● Version number is VERY IMPORTANT
– Means you can cache stuff forever in browser
– When you change your CSS, hit Save
● Merged filename changes
● Pages now point to new CSS file; user won't see the old one
● CSS and JS are ~1/2 of bandwidth on a typical site
– If you have repeat visitors, long-time caching is great
ResourceRegistries
● Added bonus:
– RR 1.3 does safe CSS and JS compression
– (Plone 2.1.2 ships with RR 1.2)
● Ideal solution: serve gzipped CSS / JS
– Buggy in many browsers, unfortunately
– RR instead strips whitespace, other tricks
● “Safe” compression cuts CSS and JS by about 25% each
● More aggressive compression cuts JS by ~50%
– RR does this on the fly each request
● CacheFu caches the results so RR only compresses once
ResourceRegistries
● CacheFu bypasses RR's caching machinery
– Routes JS and CSS through caching_policy_manager
● Policy used is cache_file_forever
– CSS and JS can live on the browser for a year
– Really important to remember to Save!
ResourceRegistries
● Tips:
– Files have to be mergeable for renaming to work
– Use debug mode for development and debugging
● Files don't get merged or cached
– Pages cached in squid may refer to the old CSS / JS files
● If you make big CSS/JS changes and want them to appear immediately, you will also have to purge squid
● purging script (purgesquid) is supplied
Will touch on a few more approaches, but not in depth
● Tune the ZODB/ZEO object caches
– speeds up Zserver
● Load balancing
– reduces page rendering times under load
● Optimize your code
– reduces page rendering time
● Cache intermediate code results
– reduces page rendering time
Strategy 1: Cache static content in browser
● When user visits site, content stored in their browser's cache
– HTTP headers tell how long to cache
● Subsequent requests pulled from local cache rather than server
● Most useful for static content that is viewed frequently
– Images, CSS, JS
HTTP headers
● Understand HTTP headers to do caching right
● Good tutorial at
http://www.web-caching.com/mnot_tutorial/
HTTP header basics
● Will use both HTTP 1.0 and 1.1 headers in case ancient clients visit
● HTTP 1.0 headers
– Expires: [date and time]
● Browser will cache if date is in the future
– Last-Modified: [date and time]
● Complicated heuristics for image caching based on Last-Modified header absent more explicit info
● The longer your image has been unchanged, the longer the browser will cache it
– Headache: both require correct client clock
HTTP header basics
● HTTP 1.1: much more fine-grained control
– Cache-Control: [tons of options]
● Most important for our purposes:
– max-age=N
● browser will cache your content for N seconds
● preferable to Expires because makes no assumptions about client clock
– public
● tells browser OK to cache even when it might not otherwise
● Cache-Control options not to include (for now):
– no-cache, no-store, must-revalidate, private
Setting HTTP headers
● AcceleratedHTTPCacheManager
– Part of CMF - sets cache headers for skin elements
– Used by Plone OOTB to set headers for static stuff
– HTTPCache
– Associate template / image / file with HTTPCache
using metadata
– cache=HTTPCache
● One of the 10 places that headers get tweaked
CacheFu and headers
● CacheFu consolidates header-setting
– Most headers set in CachingPolicyManager
– Allows for much finer-grained control
● We will need it!
● CacheFu replaces HTTPCache with a PolicyHTTPCacheManager
– Farms HTTPCache's old job out to
CachingPolicyManager
● Sets better default cache timeout
– 24 hours instead of 1 hour
CachingPolicyManager
● Take a look in ZMI: caching_policy_manager
– Details: Definitive Guide to Plone, Chapter 14
– http://docs.neuroinf.de/PloneBook/ch14.rst
● Container full of header setting policies
– Each policy has a predicate
– Pages to be rendered walk through policies until they hit a true predicate, then headers are set
● You will not need to look in here much
– Most of policy-choosing logic is elsewhere
Caching Policy
● CacheFu assigns the cache_in_browser policy to items associated with HTTPCache
● cache_in_browser policy:
– key items:
● last-modified = python:object.modified()
● max-age = 86400
– 86400 secs = 24 hours
● s-max-age = 86400
– instructions to squid
● public
– Use cached items even in situations when maybe not OK (e.g. when authorized, possibly with https connections, etc)
Caching in Browser
● cache_in_browser policy gives us the least control
– Once something is in the browser, it is stuck there
– Browser won't check for anything newer for 24 hours
● Takes a big load off server, though
– Safe to use this policy for things that rarely change
– If you plan to change stuff, consider:
● lower max-age time limit the day before
● increase again when you are done
Testing the headers
● LiveHTTPHeaders plug-in for FireFox
– Your new best friend
● Invaluable for testing caching
● Shows all request and response headers
● Tip: clear your browser cache manually before starting a session
● Let's take a look
ResourceRegistries
● Most of the content associated with HTTPCache is images
● JS and CSS used to be, but no more
● ResourceRegistries are the new way to go
– In the ZMI:
● portal_css
● portal_javascripts
– Let's take a look
ResourceRegistries
● Look at portal_css
● Lots of CSS files registered
● Line in main_template pulls in all registered CSS in the page <head> section
● Options:
– Enabled: lets you turn on/off file inclusion
– TAL condition: lets you conditionally include
– Merging allowed: can file be merged?
– Caching allowed: used for RR's internal caching (which we bypass)
ResourceRegistries
● RR serves up a set of merged CSS files with URLs
like this:
– portal_css/Default%20Skin/ploneStyles1234.css
– Skin name is in the URL so that different skins have distinct URLS
● Avoids user retrieving cached css file for one skin when
viewing a different skin
– Number in filename is version number
● every time you hit Save button, version number changes
ResourceRegistries
● Version number is VERY IMPORTANT
– Means you can cache stuff forever in browser
– When you change your CSS, hit Save
● Merged filename changes
● Pages now point to new CSS file; user won't see the old one
● CSS and JS are ~1/2 of bandwidth on a typical site
– If you have repeat visitors, long-time caching is great
ResourceRegistries
● Added bonus:
– RR 1.3 does safe CSS and JS compression
– (Plone 2.1.2 ships with RR 1.2)
● Ideal solution: serve gzipped CSS / JS
– Buggy in many browsers, unfortunately
– RR instead strips whitespace, other tricks
● “Safe” compression cuts CSS and JS by about 25% each
● More aggressive compression cuts JS by ~50%
– RR does this on the fly each request
● CacheFu caches the results so RR only compresses once
ResourceRegistries
● CacheFu bypasses RR's caching machinery
– Routes JS and CSS through caching_policy_manager
● Policy used is cache_file_forever
– CSS and JS can live on the browser for a year
– Really important to remember to Save!
ResourceRegistries
● Tips:
– Files have to be mergeable for renaming to work
– Use debug mode for development and debugging
● Files don't get merged or cached
– Pages cached in squid may refer to the old CSS / JS files
● If you make big CSS/JS changes and want them to appear immediately, you will also have to purge squid
● purging script (purgesquid) is supplied