Mark Hindley:
OK, I accept that this is not working properly on faster systems (than I
have). Actually the impact on response time and throughput is not as
great as I had previously thought either. This is my proposed solution
-- I would be grateful if you could test that it fixes it for you.
On Thu, May 17, 2012 at 01:47:58PM +0200, Alfredo Finelli wrote:
Mark Hindley:
OK, I accept that this is not working properly on faster systems (than I
have). Actually the impact on response time and throughput is not as
great as I had previously thought either. This is my proposed solution
Mark Hindley:
Thanks. I will make the default 10.
Is the patched version always that much slower or is that just related
to what else was going on at the time?
It is hard to estimate exactly because I cannot measure/influence the
network congestion between the proxy and the Debian mirror.
package apt-cacher
tag 672871 pending
thanks
On Thu, May 17, 2012 at 04:20:55PM +0200, Alfredo Finelli wrote:
Mark Hindley:
Thanks. I will make the default 10.
Is the patched version always that much slower or is that just related
to what else was going on at the time?
It is hard to
On Tue, May 15, 2012 at 11:15:29PM +0200, Alfredo Finelli wrote:
Mark Hindley:
Thanks.
From a purely selfish apt-cacher point of view we don't call select()
directly, it is only through IO::Select. Although I am reluctant to
deflect the blame, I think this maybe a perl-base bug.
On Mon, May 14, 2012 at 03:52:32PM +0100, Mark Hindley wrote:
The select-can_read() timeout of 0.1 was the result of lots of
testing in bug #533830. Reducing the timeout may reduce your throughput
(which may not bother you ;)!) I am not sure why you see such high CPU
usage with 0.1.
Mark Hindley:
Thanks for this.
The select-can_read() timeout of 0.1 was the result of lots of
testing in bug #533830. Reducing the timeout may reduce your throughput
(which may not bother you ;)!) I am not sure why you see such high CPU
usage with 0.1. What hardware is it running on?
On Tue, May 15, 2012 at 01:04:36PM +0200, Alfredo Finelli wrote:
- Wonderful emacs org-mode table :-) for a summary of average values:
| Program | time (s) | speed (Mbit/s) | cpu % |
|---+--++---|
| Curl binary, no proxy |
Mark Hindley:
Thanks.
From a purely selfish apt-cacher point of view we don't call select()
directly, it is only through IO::Select. Although I am reluctant to
deflect the blame, I think this maybe a perl-base bug.
Could you try this script and play with the timeout value in
Package: apt-cacher
Version: 1.7.4
Severity: normal
Tags: patch
The 'libcurl' thread spawned by apt-cacher to manage downloads is using too
much CPU time on my machine. I noticed just by chance that it easily
reaches 80-90% of sustained (not peak) usage during downloads.
This is the process in
On Mon, May 14, 2012 at 12:20:11PM +0200, Alfredo Finelli wrote:
Package: apt-cacher
Version: 1.7.4
Severity: normal
Tags: patch
The 'libcurl' thread spawned by apt-cacher to manage downloads is using too
much CPU time on my machine. I noticed just by chance that it easily
reaches 80-90%
11 matches
Mail list logo
