Re: [Apt-proxy-users] Performance problems on Debian/mips

[Jason B. <ja...@ed...>]

On Tuesday 05 March 2002 01:30 pm, you wrote:
<snip>
> I got hold of Jason today on IRC and we discussed the whole thing.  He's
> joined this list so we can discuss here.
>
> It turns out that there are some issues with aptcached that could cause
> problems:
>
>  - aptcached depends on POE.  It was so Jason could avoid having to do
>    events loops, but POE is still oficially alpha, is not in Potato and has
>    a large runtime overhead,  Jason reckoned around 2MB.  I'm not against
>    using libraries to help simplify coding and make it more maintainable,
>    but I think that POE is too big a price to pay.  Jason understands that
>    and is open to dropping POE, as long as someone else does the rewrite
> :-)

I talked to Chris again last Thursday or Friday on IRC and we started looking 
for POE alternatives, which I'm very much open to.  The usage of POE brings 
up memory requirements to somewhere around 6MB, which is quite large.

I've read through the docs of NetServer::Generic and it looks very promising. 
It supports multiple modes of operation, including select and fork, and a 
client mode which could replace my client side POE stuff that actually talks 
to the HTTP mirrors.

>  - It doesn't mirror the directory structure.  That certainly simplifies
> the code but has scalability problems and you don't end up with a partial
> mirror.

I can see the benefits to both a partial mirror and (of course) scalability.

What's the best way to go about maintaining a directory stucture?  Should the 
daemon handle it or could a script be fashioned to deal with reading the 
package lists and figuring out where things should go, freeing the daemon 
from having to deal with rather large package lists.

>  - HTTP 1.1 keep-alives aren't working (yet).
>
> So it looks like a fair amount must be rewritten anyway.  Jason said he's
> open to help with whatever we decide to do, which I'm very grateful for.

Yes.

> If you have the time to work on a rewrite that's great by me - I'd rather
> have several people involved than just me.  It helps keep bugs shallow and
> for the program to grow faster.  The only thing I would ask for is to make
> sure others can work with the code too.  In particular, documenting what
> code is supposed to do and helping to make sure it is production-ready.
>
<snip>
> Thanks,
> Chris (who's glad things are picking up)

Well, at least they were last week. :)