Is it possible to speed up yum.

[Patrick O'Callaghan]

On Thu, 2008-06-19 at 10:47 -0400, seth vidal wrote:
> On Thu, 2008-06-19 at 09:46 -0430, Patrick O'Callaghan wrote:
> > On Thu, 2008-06-19 at 09:21 -0400, seth vidal wrote:
> > > The plugin that I'd point to first as having an impact pre-sack-setup
> > > is fastestmirror. If you disable onlt that one do you see it?
> > 
> > Looks fairly conclusive I would say.
> > However /var/cache/yum/timedhosts.txt has only 126 entries, which
> > shouldn't take more than a jiffy to read and parse. May be worth a look.
> > 
> 
> okay - it looks like fastestmirror isn't doing a 'good enough' check on
> its mirror sorting. So on EVERY run it is rechecking those mirrors,
> which means connecting to those 126 mirrors and determining the response
> times.

What's the cache for then? The plugin seems to have no documentation (at
least in the package) so it's hard to interpret what's going on without
reading the code.

> So - on the original subject. With fastestmirror out of the list- how
> are your result times from yum?

# time yum update
Loaded plugins: protectbase, refresh-packagekit
0 packages excluded due to repository protections
Setting up Update Process
No Packages marked for Update

real    0m4.861s
user    0m3.731s
sys     0m0.291s
#

I also repeated the test on Ubuntu:

$ time sudo apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages have been kept back:
  linux-headers-generic linux-image-generic
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.

real    0m0.931s
user    0m0.444s
sys     0m0.056s
%

So yum is now only 5 times slower than apt-get (real time) rather than
10 times as before.

Of course without the fastestmirror plugin I risk downloading from a
slow mirror when I actually do a non-null update.

poc