On Tuesday 05 June 2001 23:44, you wrote:
> > I have noticed with recent CVS that FProxy is slow to return pages, and
> sometimes it hangs for ages without returning an error message. Now it
> may be something todo with my HTL 100, combined with QueryRestarted
> messages coming from somewhere. I am getting suspicious that
> QueryRestarted messages may not be such a hot idea.
>
> Ian.
Hi Ian,
I found two problems.
Problem 1: Coarse grained lock in MapHandler.lookup()
In the current implementation every request that goes through an MSK has
to acquire the lock for the synchronized static function MapHandler.lookup().
This means that concurrent requests for MSK URI's are serialized.
Back when default htl's were low (15!) this wasn't a very big issue. With
an htl of 100 it looks pretty bad.
Problem 2-- fproxy doesn't cancel freenet requests associated with aborted
http requests.
This compounds problem 1.
e.g.
I click on an MSK site. It doesn't load so I give up and click on another
site. The problem is, the second site won't even start to load until the
freenet request for the mapfile used by the first site finishes. If you click
on several MSK sites in succession, fproxy can stall for several minutes
or longer.
I fixed Problem 1 in my local tree by implementing a slightly more
complicated cache strategy with finer grained locking. Diffs are attached.
If no one screams I will check this change into the head branch later today.
My fix makes the stalls go away.
Problem 2 is ugly because of unnecessary resource use, but it doesn't
affect usability once Problem 1 is fixed. I will leave Problem 2 to someone
else...
-- gj
--
Web page inside Freenet:
freenet:MSK at SSK@enI8YFo3gj8UVh-Au0HpKMftf6QQAgE/homepage//
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mhdiffs.txt
Type: text/english
Size: 3156 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20010606/56ee9a38/attachment.bin>
