On Sat, 2009-11-28 at 11:34 +0000, Mark Hindley wrote:
> Actually, I have had another thought.
>
> Try this:
>
> diff --git a/apt-cacher2 b/apt-cacher2
> index ed53849..f04cadf 100755
> --- a/apt-cacher2
> +++ b/apt-cacher2
> @@ -1211,7 +1211,7 @@ sub connect_curlm {
> }
> }
> # Check for pending new request
> - if ($active_handles &&
> $select->can_read(0)) {
> + if ($active_handles &&
> $select->can_read(0.00001)) {
> debug_message('Pending connection');
> next LIBCURL_REQUEST;
> }
>
>
Isn't this patch in place of the previous one? I first tried commenting
out the whole block of code, which I think was the first patch. That
didn't help; the load average went up to 3.5, worse than before.
> Does that help?
YES (that is, changing to 0.00001). apt-cacher CPU use is basically
undetectable; 1% was the highest I saw.
> Does it hit your throughput?
The update seemed to take about as long as before, but that's pretty
crude.
If you can give me a wget line (mostly I'm not sure of the path), I can
check throughput. I tried lftp localhost:3142, but ls just hangs there
with
`ls' at 0 [FEAT negotiation...]
Ross
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
