Better repodata performance

[Alexandre Oliva]

On Jan 31, 2005, Konstantin Ryabitsev <mricon at gmail.com> wrote:

> On 30 Jan 2005 18:16:21 -0200, Alexandre Oliva <aoliva at redhat.com> wrote:
>> 278.7MiB) just in metadata over a period of 9 months, total

> That's about 1 megabyte per day.

Yeah.  Multiply that by a few thousand users, if you happen to run one
of the mirrors...

> I'm hard pressed to say that it makes
> much difference in overall end-user traffic, especially seeing as you
> are probably an exception: it's much less than that for a "generic
> user" who has base, updates-released, and maybe freshrpms or
> fedora.us+livna configured.

How can it be less if you're downloading stuff from more repos?

> Hell, I get about that much SPAM every day -- ~200 5k messages, that
> works up to about 1MiB.

I'm sure I get more than that.  But that's not the point.

The point is the new repodata format was proposed to improve on what
yum had, but I'm convinced it's a step backwards as it stands.  It
does offer one immediate advantage to the user, namely, the faster
download of information needed for an initial dependency resolution,
but, in the long run, you end up waiting longer for downloads, on
total.

> Now, I had to download and install 180MiB of OpenOffice updates
> yesterday. THAT sucked. The amount of YUM truffic compared to that is
> simply inconsequential.

Yeah, it's a pain.  It just doesn't *feel* that bad when you spread
this wait over 9 months, but it *is* that bad.

> Network bandwidth is getting cheaper by the day.

Yeah, sure, so let's just waste it to make up?  Doesn't sound very
clever to me.

> at some point the benefit of having an abstracted environment that's
> easy to maintain wins over the "but it's so much larger in size!".

What if it's smaller and easy to maintain?

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}