[Yum] Re: Yum support?

[Ville Skyttä]

[Moving discussion about yum details to the correct list and setting
reply-to, this is somewhat OT on freshrpms.net list]

> > Yep, that's partially true.  Unfortunately the current yum version
> > doesn't support HTTP Keep-Alive so downloading individual headers for
> > eg. the whole RH distro is dog slow (the author is aware of this and
> > working on it when he finds time).  FTP should work better.

> To be clear - all the headers for rhl 7.3 takes about 20s to download on
> my connections here w/o HTTP Keep-Alive. So "dog slow" might be a bit
> strong. :)

I'm sorry, it didn't come out exactly how I meant.  I admit I was
exaggerating, but there is a significant performance impact w/o
keep-alive.

Because pages under <http://www.dulug.duke.edu/yum/> and
<https://lists.dulug.duke.edu/mailman/listinfo/yum> load very snappily
here, I expected "yum update" to be a breeze also.

I ran some tests right now, did a full "yum update" with only
<http://mirror.dulug.duke.edu/pub/yum-repository/redhat/8.0/i386/> in my
/etc/yum.conf and a clean /var/cache/yum.  The result was that it took
29 minutes, 36 seconds.  I watched the network activity during the
update on GKrellM's net monitor, and a very inaccurate eye benchmark
left me with a feeling that most of the time there was no traffic at
all, just some bursts whenever a single .hdr was sucked.

To compare, I grabbed
<http://mirror.dulug.duke.edu/pub/yum-repository/redhat/8.0/i386/RedHat/RPMS/nautilus-2.0.6-6.i386.rpm>
with wget (it's about the same size as all the .hdr files together from
my previous test, 8.2M).  It took 10 minutes, 14 seconds (~13 K/s)
whereas the "yum update" throughput would be about 4.5 K/s.

So, to be fair, maybe it's not "dog slow", but not having keep-alive
seems to result in roughly about three-fold performance difference with
my connection to mirror.dulug.duke.edu.  It's likely that even with
keep-alive, the *.hdr files download wouldn't be as fast as just
downloading a single file of the same size, but it should be close.  I
also guess that when the connection to the server is better than in this
test, the significance of keep-alive is neglible (20 sec sounds good
enough to me :).

Yes, this isn't a scientific method, but it should give you a picture
what I meant, and it represents a real world scenario happening right
here, right now.

Oh.  Just noticed that I get a ~12% packet loss to mirror.duke.dulug.edu
with 245ms average reponse time, whereas for www.dulug.duke.edu it's 0%
and 180ms.  Hmm?

> >    rm -rf $REPODIR/headers
> >    yum-arch $REPODIR
> 
> Shouldn't have to do the rm -rf - yum-arch does the header removal for
> you. I can definitely add a option to quiet down yum-arch. I honestly
> didn't anticipate people running it out of cron.

Ah, good!  Sorry again, I thought I asked about the quiet option in a
previous post to yum-list, but memory didn't serve me well on this one. 
I'll try to behave :)  Will also try without 'rm -rf'ing and let you
know if it doesn't work it should.

Cheers,
-- 
\/ille Skyttä
ville.skytta at iki.fi