From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#33370: guix publish: at least one user will have to build a given substitute Date: Wed, 14 Nov 2018 15:49:14 +0100 Message-ID: <877ehfg1ed.fsf@gnu.org> References: <87ftw4wnc7.fsf@lassieur.org> <87in10km16.fsf@gnu.org> <87muqcezci.fsf@lassieur.org> 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]:43094) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gMwUY-0005OU-7d for bug-guix@gnu.org; Wed, 14 Nov 2018 09:50:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gMwUU-0004l2-CI for bug-guix@gnu.org; Wed, 14 Nov 2018 09:50:06 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:46871) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gMwUU-0004kb-7F for bug-guix@gnu.org; Wed, 14 Nov 2018 09:50:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gMwUT-0007vf-Sw for bug-guix@gnu.org; Wed, 14 Nov 2018 09:50:01 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87muqcezci.fsf@lassieur.org> ("=?UTF-8?Q?Cl=C3=A9ment?= Lassieur"'s message of "Wed, 14 Nov 2018 11:18:53 +0100") 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: =?UTF-8?Q?Cl=C3=A9ment?= Lassieur Cc: 33370@debbugs.gnu.org Hi, Cl=C3=A9ment Lassieur skribis: > Ludovic Court=C3=A8s writes: > >> Hello, >> >> Cl=C3=A9ment Lassieur skribis: >> >>> I've noticed that narinfo baking is triggered by user requests when the >>> '--cache' option of 'guix publish' is used. It means that the first >>> user who will want it will get the 404 response and will have to build >>> it manually. (See guix/scripts/publish.scm, make-request-handler.) >> >> Note that the first request (404) returns with an expiry of 5mn instead >> of the default (much longer) expiry for =E2=80=9Cnormal=E2=80=9D 404s. >> >> We discussed this behavior at length back then and that seemed to me >> like a reasonable behavior for a service with many users: the first one >> gets 404 (or has to wait for 5 more minutes), but when there are enough >> users, it doesn=E2=80=99t matter much. > > But at least one user will complain, and if it's a small laptop building > Icecat... The way we=E2=80=99re doing things, there=E2=80=99s necessarily a delay (th= e build time plus some additional latency) between the moment and commit is pushed and the moment the corresponding package is built. Baking only adds a very small latency. >> This would be useful in reducing latency; the downside is that we=E2=80= =99d bake >> lots of things, even possibly things that nobody ever needs. >> >> Thoughts? > > What about getting the first user to block until the baking is done? That=E2=80=99s generally not possible because HTTP is supposedly synchronou= s. Also, =E2=80=98guix publish=E2=80=99 has a bunch of worker threads that pic= k baking tasks from a queue. When the queue is empty and you asking for a substitute of sed, it will take seconds to bake it; but when the queue is already large and you=E2=80=99re asking for LibreOffice, it could take a= few minutes. For the intended use case, which is a build farm with many users, optimizing for the first user makes little sense IMO. Thanks, Ludo=E2=80=99.