[webkit-dev] PreloadScanner aggressiveness

[Mike Belshe]

On Thu, Jan 7, 2010 at 12:52 PM, Joe Mason <jmason at rim.com> wrote:

>  I don’t think every port should be required to implement prioritization
> and throttling itself – that’s just duplication of effort.
>
I agree.  I wasn't thinking of turning this on globally; rather thinking
about how to turn it on selectively for ports that want it.

Mike



> Maybe there’s a good middle-ground, where PreloadScanner is run more often
> but still does the priority sorting?
>
>
>
> Joe
>
>
>
> *From:* webkit-dev-bounces at lists.webkit.org [mailto:
> webkit-dev-bounces at lists.webkit.org] *On Behalf Of *Mike Belshe
> *Sent:* Thursday, January 07, 2010 3:09 PM
> *To:* webkit-dev at lists.webkit.org
> *Subject:* [webkit-dev] PreloadScanner aggressiveness
>
>
>
> Hi -
>
>
> I've been working on SPDY, but I think I may have found a good performance
> win for HTTP.  Specifically, if the PreloadScanner, which is responsible for
> scanning ahead within an HTML document to find subresources, is throttled
> today.  The throttling is intentional and probably sometimes necessary.
>  Nonetheless, un-throttling it may lead to a 5-10% performance boost in some
> configurations.  I believe Antti is no longer working on this?  Is there
> anyone else working in this area that might have data on how aggressive the
> PreloadScanner should be?  Below I'll describe some of my tests.
>
>
>
> The PreloadScanner throttling happens in a couple of ways.  First, the
> PreloadScanner only runs when we're blocked on JavaScript (see
> HTMLTokenizer.cpp).  But further, as it discovers resources to be fetched,
> it may delay or reject loading the subresource at all due to throttling in
> loader.cpp and DocLoader.cpp.  The throttling is very important, depending
> on the implementation of the HTTP networking stack, because throwing too
> many resources (or the low-priority ones) into the network stack could
> adversely affect HTTP load performance.  This latter problem does not impact
> my Chromium tests, because the Chromium network stack does its own
> prioritization and throttling (not too dissimilar from the work done by
> loader.cpp).
>
>
>
> *Theory*:
>
> The theory I'm working under is that when the RTT of the network is
> sufficiently high, the *best* thing the browser can do is to discover
> resources as quickly as possible and pass them to the network layer so that
> we can get started with fetching.  This is not speculative - these are
> resources which will be required to render the full page.   The SPDY
> protocol is designed around this concept - allowing the browser to schedule
> all resources it needs to the network (rather than being throttled by
> connection limits).  However, even with SPDY enabled, WebKit itself prevents
> resource requests from fully flowing to the network layer in 3 ways:
>
>    a) loader.cpp orders requests and defers requests based on the state of
> the page load and a number of criteria.
>
>    b) HTMLTokenizer.cpp only looks for resources further in the body when
> we're blocked on JS
>
>    c) "preload" requests are treated specially (docloader.cpp); if they are
> discovered too early by the tokenizer, then they are either queued or
> discarded.
>
>
>
> *Test Case*
>
> Can aggressive preloadscanning (e.g. always preload scan before parsing an
> HTML Document) improve page load time?
>
>
>
> To test this, I'm calling the PreloadScanner basically as the first part of
> HTMLTokenizer::write().  I've then removed all throttling from loader.cpp
> and DocLoader.cpp.  I've also instrumented the PreloadScanner to measure its
> effectiveness.
>
>
>
> *Benchmark Setup*
>
> Windows client (chromium).
>
> Simulated network with 4Mbps download, 1Mbps upload, 100ms RTT, 0% packet
> loss.
>
> I run through a set of 25 URLs, loading each 30 times; not recycling any
> connections and clearing the cache between each page.
>
> These are running over HTTP; there is no SPDY involved here.
>
>
>
> *Results:*
>
> *Baseline
> (without my changes)*
>
> *Unthrottled*
>
> *Notes*
>
> Average PLT
>
> 2377ms
>
> 2239ms
>
> +5.8% latency redux.
>
> Time spent in the PreloadScanner
>
> 1160ms
>
> 4540ms
>
> As expected, we spend about 4x more time in the PreloadScanner. In this
> test, we loaded 750 pages, so it is about 6ms per page. My machine is fast,
> though.
>
> Preload Scripts discovered
>
> 2621
>
> 9440
>
> 4x more scripts discovered
>
> Preload CSS discovered
>
> 348
>
> 1022
>
> 3x more CSS discovered
>
> Preload Images discovered
>
> 11952
>
> 39144
>
> 3x more images discovered
>
> Preload items throttled
>
> 9983
>
> 0
>
> Preload Complete hits
>
> 3803
>
> 6950
>
> This is the count of items which were completely preloaded before WebKit
> even tried to look them up in the cache. This is pure goodness.
>
> Preload Partial hits
>
> 1708
>
> 7230
>
> These are partial hits, where the item had already started loading, but not
> finished, before WebKit tried to look them up.
>
> Preload Unreferenced
>
> 42
>
> 130
>
> These are bad and the count should be zero. I'll try to find them and see
> if there isn't a fix - the PreloadScanner is just sometimes finding
> resources that are never used. It is likely due to clever JS which changes
> the DOM.
>
>
>
>
>
>
>
> *Conclusions:*
>
> For this network speed/client processor, more aggressive PreloadScanning
> clearly is a win.   More testing is needed for slower machines and other
> network types.  I've tested many network types; the aggressive preload
> scanning seems to always be either a win or a wash; for very slow network
> connections, where we're already at capacity, the extra CPU burning is
> basically free.  For super fast networks, with very low RTT, it also appears
> to be a wash.  The networks in the middle (including mobile simulations) see
> nice gains.
>
>
>
> *Next Steps and Questions:*
>
> I'd like to land my changes so that we can continue to gather data.  I can
> enable these via macro definitions or I can enable these via dynamic
> settings.  I can then try to do more A/B testing.
>
>
>
> Are there any existing web pages which the WebKit team would like tested
> under these configurations?  I don't see a lot of testing that I can
> leverage from the initial great work Antti did for verifying that I'm not
> breaking anything.
>
>
>
> Is there any other information or data from the original PreloadScanner
> work which I should read?
>
>
>
>
>
> Thanks!
> Mike
>
>
>
>
>
>
>   ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from your
> system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100107/d3e9928a/attachment.html>