From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id QEWKOmFTW2B8YQAA0tVLHw (envelope-from ) for ; Wed, 24 Mar 2021 14:57:37 +0000 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id ACfuNWFTW2BRCwAAB5/wlQ (envelope-from ) for ; Wed, 24 Mar 2021 14:57:37 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 5BF33162B0 for ; Wed, 24 Mar 2021 15:57:37 +0100 (CET) Received: from localhost ([::1]:38834 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lP4wy-0005gX-JD for larch@yhetil.org; Wed, 24 Mar 2021 10:57:36 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57188) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lP4ra-0007A9-Av for bug-guix@gnu.org; Wed, 24 Mar 2021 10:52:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:52469) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lP4ra-00027x-21 for bug-guix@gnu.org; Wed, 24 Mar 2021 10:52:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lP4rZ-0001XC-UF for bug-guix@gnu.org; Wed, 24 Mar 2021 10:52:01 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#47283: Performance regression in narinfo fetching Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Wed, 24 Mar 2021 14:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47283 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Christopher Baines Received: via spool by 47283-submit@debbugs.gnu.org id=B47283.16165975185886 (code B ref 47283); Wed, 24 Mar 2021 14:52:01 +0000 Received: (at 47283) by debbugs.gnu.org; 24 Mar 2021 14:51:58 +0000 Received: from localhost ([127.0.0.1]:35782 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lP4rV-0001Ws-VV for submit@debbugs.gnu.org; Wed, 24 Mar 2021 10:51:58 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35898) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lP4rT-0001We-Ks for 47283@debbugs.gnu.org; Wed, 24 Mar 2021 10:51:56 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57146) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lP4rN-00021C-U6; Wed, 24 Mar 2021 10:51:49 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=57324 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lP4rN-0001yD-AU; Wed, 24 Mar 2021 10:51:49 -0400 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <87ft0p67z4.fsf@inria.fr> <874kh5d0rg.fsf@cbaines.net> <87czvs19tp.fsf@gnu.org> <87k0pxbnsf.fsf@cbaines.net> Date: Wed, 24 Mar 2021 15:51:47 +0100 In-Reply-To: <87k0pxbnsf.fsf@cbaines.net> (Christopher Baines's message of "Tue, 23 Mar 2021 20:47:12 +0000") Message-ID: <87y2eceha4.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: 47283@debbugs.gnu.org Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1616597857; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=A6EtaWXYCPagqlLHKgx5GBrArmMONtUXuLeg8nPIlDM=; b=Mops9FZW2pl5Ox6pB20cl+UpLK/mD9QEObu1zVnWVn9/z4lRvvFyCbmFgdYN24MGX2TiPK zHEMjeQeTqqzNEdbXTjsSTUZR9+5C3xcDqMZu2z4p/X916k/tdkBIDhs7BY3HndmNVhzWX LUiGggeaASo8YmnRRfltTrYLsdyrij2GHDVGpAeCt5xXfgGDhbcb0PjETW78SsPqoM8tr9 GOnuYmFvDgzXURCVqzbQyGaFLtZWLXFPLAFJxNE2kMDGmajG888txxmWS/Hdl39zuggIS7 /h3WmSAuuRqkbxveH1ldDEpslLHTf2b3GYRnc9l4frcQ1sjrXVZ2+j5NzlDVBA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1616597857; a=rsa-sha256; cv=none; b=DqvJWp2EnK/jpKpkwGpW++VTP7V4O5ef3CxYgnQqSDxJ5+0qShd0ABqIqq532oLFxUow9R /TKuoTjcgIJ0FqUgfFZ+OoDK+NboKcCn/04Js60AoX512ZhBlGxr6PyxkThMstef1mms8x DgqD3WDlNinYSEoBP5/T4isXAri5XBdXAvoPelm7v4zIV7p/AEym+8DnKrEIsyoXQ7S+st d/jkxqr55E7pLyCLi/Msf5IIy7GM5C9RsfHJC0RbTLieBtAc8fb/vA4lQ2/bkpegP1dkMp h6lfrjXNSDM3mUDziMV4u7ItNhgx++G85eO1nPqlFmxNczD+lIjHkdnrsSKFNA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Spam-Score: -3.47 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Queue-Id: 5BF33162B0 X-Spam-Score: -3.47 X-Migadu-Scanner: scn0.migadu.com X-TUID: 6L8OkPyhq/iI Hi Chris, Christopher Baines skribis: > Ludovic Court=C3=A8s writes: [...] >> Earlier, commit be5a75ebb5988b87b2392e2113f6590f353dd6cd (=E2=80=9Csubst= itute: >> Reuse connections for '--query'.=E2=80=9D) did not add such a =E2=80=98c= atch=E2=80=99 block in >> =E2=80=98http-multiple-get=E2=80=99. Instead, it wrapped its call in = =E2=80=98do-fetch=E2=80=99 in >> =E2=80=98fetch-narinfos=E2=80=99: >> >> (define (do-fetch uri) >> (case (and=3D> uri uri-scheme) >> ((http https) >> - (let ((requests (map (cut narinfo-request url <>) paths))) >> - (match (open-connection-for-uri/maybe uri) >> - (#f >> - '()) >> - (port >> - (update-progress!) >> ;; Note: Do not check HTTPS server certificates to avoid dependi= ng >> ;; on the X.509 PKI. We can do it because we authenticate >> ;; narinfos, which provides a much stronger guarantee. >> - (let ((result (http-multiple-get uri >> + (let* ((requests (map (cut narinfo-request url <>) paths)) >> + (result (call-with-cached-connection uri >> + (lambda (port) >> + (if port >> + (begin >> + (update-progress!) >> + (http-multiple-get uri >> handle-narinfo-res= ponse '() >> requests >> + #:open-connection >> + open-connection-fo= r-uri/cached >> #:verify-certifica= te? #f >> - #:port port))) >> >> This bit is still there in current =E2=80=98master=E2=80=99, so I think = it=E2=80=99s not >> necessary to catch these exceptions in =E2=80=98http-multiple-get=E2=80= =99 itself, and I >> would just remove the =E2=80=98catch=E2=80=99 wrap altogether. >> >> WDYT? > > I'm not sure what you're referring to as still being there on the master > branch? On =E2=80=98master=E2=80=99, =E2=80=98do-fetch=E2=80=99 has its =E2=80=98ht= tp-multiple-get=E2=80=99 call wrapped in =E2=80=98call-with-connection-error-handling=E2=80=99, which is equivalent = to the change made in be5a75ebb5988b87b2392e2113f6590f353dd6cd and shown above. > Looking at the changes to this particular code path resulting from the > changes I've made recently, starting at lookup-narinfos, before: > > - lookup-narinfos calls fetch-narinfos, which calls do-fetch > > - call-with-cached-connection is used, which catches a number of > exceptions relating to requests, and will retry PROC once upon a > matching exception > > - open-connection-for-uri/maybe is also used, which is like > open-connection-for-uri/cached, except it includes error handling for > establishing connections to substitute servers > > - http-multiple-get doesn't include error handling > > After: > > - lookup-narinfos calls fetch-narinfos, which calls do-fetch > > - call-with-connection-error-handling is used, which performs the same > role as the error handling previously within > open-connection-for-uri/maybe, catching exceptions relating to > establishing connections to substitute servers > > - http-multiple-get now includes error handling similar to what was > previously done by call-with-cached-connection, although it's more > complicated since it's done with knowledge of what http-multiple-get > is doing > > I think that the error handling now in http-multiple-get isn't covered > elsewhere. Moving this error handling back in to fetch-narinfos is > possible, but then we'd be back to handling connection caching in that > code, and avoiding that led to this refactoring in the first place. The =E2=80=98http-multiple-get=E2=80=99 call in =E2=80=98fetch-narinfos=E2= =80=99 is already wrapped in =E2=80=98call-with-connection-error-handling=E2=80=99, so it seems we=E2=80= =99re good? > Also, apart from the implementation problems, I do think that the error > handling here is better than before. Previously, if you called > lookup-narinfos, and a connection problem occurred, processing all the > requests would start from scratch (as call-with-cached-connection calls > PROC a second time), if a second connection error was to happen, well, > call-with-cached-connection only handles one error, so that won't be > caught. Hmm true. However, can that second exception happen? Normally, if we get a first exception, we open a new connection and that one should not get another exception, unless something is wrong=E2=80=94in which case it= =E2=80=99s probably best to report it than to endlessly retry. WDYT? Even in tail call position, =E2=80=98catch=E2=80=99 calls introduce allocat= ions and extra work, so if we can avoid using one =E2=80=98catch=E2=80=99 per iterat= ion, that=E2=80=99s better. Thank you, Ludo=E2=80=99.