[webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching

[Adam Barth]

On Tue, Oct 9, 2012 at 7:52 AM, Antti Koivisto <koivisto at iki.fi> wrote:
> On Tue, Oct 9, 2012 at 4:21 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>> One preliminary finding of ours is that different web pages fairly often
>> load identical resource bodies from different URLs. We expect possible
>> benefits from sharing the body data of resources in memory even if we cannot
>> share the URL or response headers.
>
> I did some preliminary profiling of this earlier. The data is not
> necessarily very representative of the web as whole, I simply browsed
> through a number of popular sites with an instrumented build
> (https://bug-98539-attachments.webkit.org/attachment.cgi?id=167753). Here is
> what I had in the WebCore memory cache in the end:
>
> TOTAL duplicates count=443 size=852791 decodedSize=3426638
> all cached resources count=2636 size=116463712
>
> 17% of cache entries are exact copies of previous entries. They use 4.3MB
> out of total 116MB cache size (4%). The average size of duplicate entries is
> much smaller than the average entry size (not surprisingly, transparent 1x1
> images etc).
>
> Some examples:
>
> HTTP vs. HTTPS:
>
> hash=5d90af size=91556 decodedSize=34834
> https://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js
> hash=5d90af size=91556 decodedSize=32
> http://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js
>
> (decodedSize for js resources is the size of the function offset cache which
> can differ depending which functions have been parsed).
>
> Ad scripts with deliberately unique URLs:
>
> hash=6f6494 size=3111 decodedSize=32
> http://ad.doubleclick.net/adj/teg.fmsq/j2ek;subs=n;wsub=n;sdn=n;dcopt=ist;pos=ldr_top;sz=728x90,970x90;tile=1;ord=76273718?
> hash=6f6494 size=3111 decodedSize=648
> http://ad.doubleclick.net/adj/teg.fmsq/j2ek;subs=n;wsub=n;sdn=n;dcopt=ist;pos=ldr_top;sz=728x90,970x90;tile=1;ord=711567314?
> hash=6f6494 size=3111 decodedSize=32
> http://ad.doubleclick.net/adj/teg.fmsq/j2ek;subs=n;wsub=n;sdn=n;dcopt=ist;pos=ldr_top;sz=728x90,970x90;tile=1;ord=908690779?
> hash=6f6494 size=3111 decodedSize=32
> http://ad.doubleclick.net/adj/teg.fmsq/j2ek;subs=n;wsub=n;sdn=n;dcopt=ist;pos=ldr_top;sz=728x90,970x90;tile=1;ord=876087584?
>
> Same framework loaded by multiple unrelated sites:
>
> hash=230c7d size=1958 decodedSize=0
> http://static.iltalehti.fi/js/measure/spring.js
> hash=230c7d size=1958 decodedSize=1536 http://yle.fi/global/spring/spring.js
>
> (didn't see as many of these as expected though i'm sure there are sites
> that run into this)
>
> Copy-paste resources:
>
> hash=8fb3e size=3965 decodedSize=13088
> http://store.storeimages.cdn-apple.com/2149/store.apple.com/rs/source/store/base/nav/globalnav/css/bg/globalsearch_spinner.gif
> hash=8fb3e size=3965 decodedSize=13088
> http://store.storeimages.cdn-apple.com/2150/store.apple.com/rs/source/store/features/search/css/bg/spinner.gif
> hash=8fb3e size=3965 decodedSize=13088
> http://store.storeimages.cdn-apple.com/2150/store.apple.com/rs/source/store/base/nav/globalnav/css/bg/globalsearch_spinner.gif
> hash=8fb3e size=3965 decodedSize=13088
> http://images.apple.com/global/nav/images/globalsearch_spinner.gif
>
> Versioning:
>
> hash=cecbad size=184899 decodedSize=0
> http://store.storeimages.cdn-apple.com/2150/store.apple.com/rs/applestore-rs-2.css
> hash=cecbad size=184899 decodedSize=0
> http://store.storeimages.cdn-apple.com/2149/store.apple.com/rs/applestore-rs-2.css
>
> hash=47a8de size=20041 decodedSize=7870
> http://js.t.sinajs.cn/open/analytics/js/suda.js?version=b4d67909ad6b5b7d
> hash=47a8de size=20041 decodedSize=7870
> http://tjs.sjs.sinajs.cn/open/analytics/js/suda.js
>
> Multiple content servers:
>
> hash=8e976b size=808 decodedSize=13088
> http://i0.sinaimg.cn/home/deco/2008/0329/sinahome_0803_ws_003_new.gif
> hash=8e976b size=808 decodedSize=71700
> http://i3.sinaimg.cn/home/deco/2008/0329/sinahome_0803_ws_003_new.gif
>
> Based on this I think this is definitely worth at least looking further.

This is interesting data, but it seems to be related to whether we
should make the MemoryCache content addressable rather than whether we
should use shared memory to back the MemoryCache when there are
multiple WebProcesses.

Adam


>> You can also expect that we won't push forward blindly on this effort if
>> data ultimately shows it to be a bad idea, or in general not worth the
>> complexity.
>>
>> Regards,
>> Maciej
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>