[arch-general] [arch-dev-public] [RFC] Mirror load distribution

[Eli Schwartz]

On 01/30/2017 02:39 PM, Florian Pritz via arch-dev-public wrote:
> I've just received a report from a mirror admin about some very heavy
> traffic. After some investigation it appears that the traffic towards
> his mirror started to rise around the beginning of the new year when we
> disabled the mirror checker on gerolde. Since we now only have a mirror
> checker running in Germany and his server is actually in the same data
> centre as ours, the mirror checks completed very quickly.
> 
> Archweb uses this data to calculate a "mirror score" which can be seen
> here[1]. This score can also be used to sort the mirror list that can be
> generate by archweb list this[2].
> 
> [1] https://www.archlinux.org/mirrors/status/
> [2]
> https://www.archlinux.org/mirrorlist/?use_mirror_status=on&protocol=https
> 
> Apparently there is a script in AUR[3] which uses [2] to fetch a
> mirrorlist. That script runs once a day.
> 
> [3] https://aur.archlinux.org/packages/update-pacman-mirrorlist/

It seems to me that this AUR package is *generally* in bad taste,
although granted, depending on people to do smart things is probably not
a good idea either.

No one needs to update their mirrors daily, but either way, rather than
using horrendously inaccurate metrics I would suggest using rankmirrors
or even reflector's "--fastest" option.

From looking at the package, it seems to be its own source as well,
which is actually against the rules.

> I'm thinking about removing the mirror score from archweb's output and
> more importantly, not sorting mirrors based on this score but rather
> randomizing the list returned in [2]. It could still take the score into
> account by limiting the returned set to mirror that are not totally out
> of date, but I'd remove the sorting. The score doesn't really have a lot
> a meaning anyways since it's just from our point of view.
> 
> Does anyone have hard feeling about this? If not I'll prepare a patch in
> the next few days.

Sounds like it fits the intended use-case anyway.

-- 
Eli Schwartz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20170130/bf7a85a4/attachment-0001.asc>