On Thu, Jan 7, 2010 at 12:52 PM, Joe Mason <jma...@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-boun...@lists.webkit.org [mailto: > webkit-dev-boun...@lists.webkit.org] *On Behalf Of *Mike Belshe > *Sent:* Thursday, January 07, 2010 3:09 PM > *To:* webkit-dev@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. > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev