From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: 01/01: nginx: berlin: Disable narinfo caching altogether. Date: Thu, 21 Jun 2018 16:06:19 -0400 Message-ID: <87sh5f9a6c.fsf@netris.org> References: <20180621094438.32617.70405@vcs0.savannah.gnu.org> <20180621094439.636F520498@vcs0.savannah.gnu.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]:57540) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fW5rz-0007Rj-LO for guix-devel@gnu.org; Thu, 21 Jun 2018 16:07:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fW5rv-0005kf-KF for guix-devel@gnu.org; Thu, 21 Jun 2018 16:07:51 -0400 In-Reply-To: <20180621094439.636F520498@vcs0.savannah.gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22's\?\= message of "Thu, 21 Jun 2018 05:44:39 -0400 (EDT)") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org Hi Ludovic, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > civodul pushed a commit to branch master > in repository maintenance. > > commit 8379ba4119e51151d93589a6ef57cb159d94e9f2 > Author: Ludovic Court=C3=A8s > Date: Thu Jun 21 11:41:06 2018 +0200 > > nginx: berlin: Disable narinfo caching altogether. >=20=20=20=20=20 > This is a followup to ebbe4c7f402b6d9cf9c6c2ecf120f49697ab2c49. >=20=20=20=20=20 > * hydra/nginx/berlin-locations.conf (.narinfo): Disable caching. > * hydra/nginx/berlin.conf: Remove 'proxy_cache_path' directive > for narinfos. What's the rationale for this change? Although 'guix publish' does its own caching, I would expect 'nginx' to handle cache hits far more efficiently than guix publish. Therefore, I expect this change to result in higher CPU usage for a given amount of traffic. I also expect that cache hits on narinfos are an important common case for our substitute servers. Does this change bring advantages that outweigh the loss of efficiency? Mark