From mboxrd@z Thu Jan 1 00:00:00 1970 From: Subject: bug#26201: No notification of cache misses when downloading substitutes Date: Mon, 20 Mar 2017 21:48:09 -0700 Message-ID: <20170320214809.466dc5fe@khaalida> References: <20170320184449.5ac06051@khaalida> <144e9ba8-af93-fb18-d2b9-f198ae7c11e9@tobias.gr> <20170320195247.05f72fc9@khaalida> <8e7e07d1-563f-666f-2c32-2a772757c86f@tobias.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56777) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cqBjG-0006gv-Hp for bug-guix@gnu.org; Tue, 21 Mar 2017 00:49:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cqBjC-0005zn-Fh for bug-guix@gnu.org; Tue, 21 Mar 2017 00:49:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:38917) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cqBjC-0005za-Ck for bug-guix@gnu.org; Tue, 21 Mar 2017 00:49:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cqBjC-0006UM-2p for bug-guix@gnu.org; Tue, 21 Mar 2017 00:49:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <8e7e07d1-563f-666f-2c32-2a772757c86f@tobias.gr> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Tobias Geerinckx-Rice Cc: 26201@debbugs.gnu.org On Tue, 21 Mar 2017 04:57:09 +0100 Tobias Geerinckx-Rice wrote: > Ahoy, >=20 > On 21/03/17 03:52, dian_cecht@zoho.com wrote: > > The URL displayed during the download was mirror.hydra.gnu.org. > > [...] It was a binary download, not source. =20 >=20 > Oh, OK. I'm not an expert on how Hydra's set up these days, but will > assume it's not too different from my own (a fast nginx proxy_cache, > mirror.hydra.gnu.org, in front of a slower build farm, hydra.gnu.org). >=20 > Whenever you're the first to request a substitute, > mirror.hydra.gnu.org transparently forwards the request to > hydra.gnu.org. >=20 > The latter has to compress the response on the fly, leading to much > slower transfer speeds. It slowly sends it back to the mirror, which > slowly sends it on to you while also saving it on disc so all > subsequent downloads will be fast =E2=80=94 by Hydra standards =E2=80=93 = and not > involve hydra.gnu.org. >=20 > Maybe you knew all this, but it's also the reason that... I'm not familiar with the implementation details, nor how hydra is currently setup. > > On 21/03/17 02:44, dian_cecht@zoho.com wrote: > > It would be nice if there was some notification that a cache miss > > happened and the download will likely be slow, otherwise a user > > might wonder what problem there is with their connection. =20 >=20 > ...I'm afraid this makes no sense from guix's point of view. >=20 > The term =E2=80=98cache miss=E2=80=99 here is an implementation detail of= our current > Hydra set-up, not something guix can or IMO should care about. There > are hundreds of reasons why your connection might be slow at any > given time. Guix should just tell you so (it does), not guess why. Or > worse: know. I'm not suggesting having Guix tell me why my network is slow, only if the download might be slow because it's having to pull from hydra.gnu.org. Having Guix automagically troubleshoot networking problems is well beyond the scope of a package manager, even one that goes as far beyond simple package management as Guix does. >=20 > (But if others disagree, we'll have to extend the Hydra API to somehow > relay this information to the client, in the spirit of the modern > Web.) AFAIK, Guix devs are working on a replacement for the current build system, so the sane option wouldn't be extending the current hydra system to handle a new API call, but to try and work this type of feature into the next system. Unless, of course, something like this could be done in hydra reasonably easily, in which case why not. Another option would be to have the mirrors automatically cache the files as soon as they are available to try. I'd hope this would be how things are handled already, but one never knows.