Author(s):	sarah Novotny
Location	Caro
Date	jan Tue 17	Days Raw Files
Start	16:40	First Raw Start	error-in-template
Duration	0:50:00	Offset	None
End	17:30	Last Raw End
Chapters
Total cuts_time	None min.

http://lca2012.linux.org.au/schedule/70/view_talk
raw-playlist raw-mp4-playlist encoded-files-playlist mp4 svg png

assets release.pdf where_is_your_data_cached_and_where_should_it_be_cached.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:	--------- borked edit encode push to queue post richard review 1 email review 2 make public tweet to-miror conf done
Locked:	clear this to unlock
Locked by:	user/process that locked.
Start:	initially scheduled time from master, adjusted to match reality
Duration:	length in hh:mm:ss
Name:	Video Title (shows in video search results)
Emails:	email(s) of the presenter(s)
Released:	Unknown Yes No has someone authorised pubication
Normalise:
Channelcopy:	m=mono, 01=copy left to right, 10=right to left, 00=ignore.
Thumbnail:	filename.png
Description:	Taking a look at the many layers of caching in the modern webstack can lead to some interesting optimizations. We know that raid card caches, disk caches and CPU caches all exist at the hardware level, but how do they interact with database caching, application code caching and rendered page caching. Where are the redundancies and where is the most optimal location for your services to cache? Are you risking data integrity by using both disk and raid card caching? Is there a similar risk in using both filesystem and database caching? These are hard won lessons if you have to learn them during an outage. they can be avoided with some forethought and benchmarking. I’ll call out the many layers where data is cached and talk about some of the risks and potential performance gains that we’ve found by selectively disabling and adding particular caching layers. markdown
Comment:	production notes