

Cache Them If You Can - enobrev
http://www.stevesouders.com/blog/2012/03/22/cache-them-if-you-can/

======
Destroyer661
One of the largest improvements I've noticed in between caching and optimizing
in PHP has been turning on APC. I'm not aware of any drawbacks, if you have
any let me know. I didn't do any bench marking, but it did make a significant
impact on page loads to my eye, as well as the stats on the page.

~~~
driverdan
While backend caching isn't what the article is about, you're absolutely right
that an opcode cache such as APC _significantly_ improves backend performance.
It's one of the first things I check for when I'm optimizing a client's PHP
site.

------
HerraBRE
To celebrate this article, I just set my cache size in Firefox to zero. Why?
Aside from being a bit contrary by nature, I present the following...

Fact: My netbook is memory constrained and the network is often faster than my
local disk.

Hunch: Caching content locally does nothing but thrash my disk, trash my FS
cache and slow my entire computer down.

We'll see how it pans out. :-)

~~~
ww520
Cached HTTP resources are usually small in 10K's to 100K's. You meant your
netbook is so memory constrained that it can't afford some megabytes of cache
memory?

~~~
HerraBRE
I am talking about on-disk cache, not in-memory cache.

Being memory constrained means I do not have a large filesystem cache and
cannot afford to have it smashed by lots of cache reads/writes.

It also means the odds that a cached (on disk) resource is actually in RAM is
low, so a cache hit involves multiple disk seeks which very quickly adds up to
more latency than fetching over the network - especially when you consider
that I have one disk which cannot run multiple seeks in parallel, whereas the
network round trips can overlap.

Performance on modern computers very often boils down to avoiding disk seeks.

~~~
ww520
That's why I said http resources are typically small. They won't take up too
much cache memory when brought in from disk. Filesystem caching is so good
these days that if a file is used more than once, its disk seek time is
negligible when amortized over its many read.

I'm pretty sure jquery.xx.min.js will be downloaded over and over again for
every page if you don't cache it.

~~~
HerraBRE
Seems I've been downvoted for an unhelpful answer. :-P

The problem isn't the size of each individual resource, it is the total volume
of resources. In fact, the small size of web resources makes the problem
worse, not better - a local disk beats the network when reading large volumes
of sequential data (say, a movie). Small assets on the other hand, which you
correctly assert are the majority, will result in lots of sequential disk
seeks, whereas the network which can initiate many transfers in parallel can
do much better.

Regarding the effect of the FS cache, I provide one unscientific data point:
My Firefox cache had grown to 650MB in size - on a machine with 1GB of RAM. It
is pretty obvious that the vast majority of those resources will not fit in
the FS cache and will require some disk seeks to load and display. Reducing
the size of the cache to something that more-or-less fits in RAM might make
sense... but why bother with an on-disk cache at all then?

Constantly writing to the disk as I browse the web is also a major source of
system load (cache churn, seeks, write traffic), and this effect is relative
not to the size of the cache, but to the activity of my browser - turning the
cache off eliminated this completely which may (or may not) offset any
benefits provided by the occasional cache hit.

Finally, my testing implies that your worries about jquery and other shared
elements within a website are needless, the browser also has a RAM cache and
all the active things on a page live there. Clicking from page to page within
a site does not trigger a reload of shared elements, even if the disk cache
has been switched off.

I am still trying to come up with a way to accurately measure and benchmark
the effects of local disk cache on the browsing experience. Once I have, I
will run some tests and post the results.

Note that all of this is relevant to the OP, because the "call to action" of
the OP was that browsers should increase the size of their disk caches. I
suspect this would be, in many cases, a bad idea. I went and did the opposite,
and so far my laptop - and the web - both feel snappier.

------
ars
> The HTTP Archive doesn’t save response bodies so the determination of
> “identical” is based on the resource having the exact same URL, Last-
> Modified, ETag, and Content-Length.

I don't like this. Dynamic pages don't usually send _any_ of those headers, so
the page will appear identical in his analysis, despite not actually being
identical.

~~~
inkel
Dymanic pages properly programmed could and should send this headers. Also
some frameworks and/or proxies manage this for you.

------
ww520
YSlow is a great tool in finding out whether caching is turned on for a
resource.

