On Wednesday 07 January 2009 09:12, Daniel Cheng wrote: > On Wed, Jan 7, 2009 at 3:48 PM, Colin Davis <Colin at sq7.org> wrote: > >>> > >> > >> We are prefetching them already. And we have a config option for that. > >> It's just too slow. > > > > I know I'm being terrible dense, but I don't see how this makes sense. > > > > Matthew had mentioned that the concern stemmed from the fact that the > > browser had a lmited number of connections to each host, in this case, > > to fproxy. This causes the browser to request two images, say A.jpg > > and B.jpg, and wait for them to download from the network before it > > requests C.jpg and D.jpg > > > > This problem is exacerbated with a great many pictures. If there are > > 27 pictures on a page, and the node requests them 2 at a time, it will > > take a very long time for the entire site to load. (Assuming it is > > larger than allowed in one container) > > > > If instead, fproxy were to parse the html, and start downloading every > > image file as soon as the html is finished, the browser-connection > > limit becomes almost irrelevant to the discussion; The node isn't > > downloading the pictures 2 at a time anymore, it's downloading as as > > it can, and then sending them to the browser (quickly/locally) 2 at a > > time, which takes immeasurably short time, compared to the pull from > > the network. > > It _IS_ doing this already. > See http://www.google.com/codesearch/p?hl=en#KYLvKSOdAFc/trunk/freenet/src/freenet/clients/http/FProxyToadlet.java&q=prefetch\%28%20package:http://freenet\.googlecode\.com&l=136
IIRC I disabled this because it didn't seem to improve performance on new nodes. Maybe it needs to be reconsidered - with a bit of javascript we could ensure that we only prefetch inlines when the user actually has the page open, and maybe we could boost the priority a bit... > > But this don't solve the problem. > Suppose there is a page with lots of large, rare image on top and > small image on bottom. > The node can (and will) prefetch the small images immediately. But the browser, > due to connection limits, will only try to fetch the large images from node. > > > > > Where I get confused is trying to reconcile your statement that you > > are prefetching, with Matthew's argument that a custom XUL runner is > > needed because of the connection limits. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090107/7bb2da0a/attachment.pgp>
