On 3/7/2012 9:16 AM, Patrick McManus wrote:
As I mentioned in another thread, David Baron and I attended a
Velocity-Conference related event where a bunch of heavyweights from the
devops community get together with a bunch of browser people to talk
about the state of web performance . It was a pretty refreshing event -
smart and experienced folks talking openly in an unconf sort of setting
about making the web perform better. I learned a lot.
I want to report back on some interesting things on two of the sessions:
the browser session, and the ssl session.
======
The "browser" session. Devops folks were invited to bring ideas and
report on bottlenecks in their designs to the browser folks in the room.
David dealt with a bunch of things in the content space, but as far as
networking:
As mentioned in a previous thread - the HTTP cache was a big topic.
There was a general feeling, undocumented by specific cases, that
browser's were not delivering cache rates that they expected. These
folks definitely knew how to set cache-control headers - but the concern
was not limited to a particular browser.
If you haven't seen Will Chan's (of Chrome) recent post on cache metrics
of Chrome please check that out:
https://plus.google.com/103382935642834907366/posts/XRekvZgdnBb (The
bits attributed to me are not a correct attribution, but it really isn't
the impt part). He talks about how it takes ~2 days for 75% of users to
fill up a cache in the 200-300MB range (a rate that definitely won't be
linear), and how 25%+ of users will clear their cache at least once a
week (either manually or due to error recovery).. leading to an overally
generalized hit rate of about 1/3.
Do we have a plan/ETA to keep our cache from not corrupting self?
Taras
PS. I'm amused to see that chrome decided to re-implement our cache
backend along with self-destruct handicap.
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
