[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 01/01: nginx: berlin: Disable narinfo caching altogether.
From: |
Mark H Weaver |
Subject: |
Re: 01/01: nginx: berlin: Disable narinfo caching altogether. |
Date: |
Fri, 22 Jun 2018 17:14:42 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Hi Ludovic,
address@hidden (Ludovic Courtès) writes:
> Mark H Weaver <address@hidden> skribis:
>
>> address@hidden (Ludovic Courtès) writes:
>>
>>> civodul pushed a commit to branch master
>>> in repository maintenance.
>>>
>>> commit 8379ba4119e51151d93589a6ef57cb159d94e9f2
>>> Author: Ludovic Courtès <address@hidden>
>>> Date: Thu Jun 21 11:41:06 2018 +0200
>>>
>>> nginx: berlin: Disable narinfo caching altogether.
>>>
>>> This is a followup to ebbe4c7f402b6d9cf9c6c2ecf120f49697ab2c49.
>>>
>>> * 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?
>
> From commit ebbe4c7f402b6d9cf9c6c2ecf120f49697ab2c49:
>
> Somehow nginx appeared to be caching narinfos for longer than needed,
> which defeated the atime-based cache eviction strategy of 'guix
> publish'.
>
> In this case, I noticed on berlin that nginx was caching 404s for
> narinfos longer than expected, for reasons I could not elucidate. Plus
> there’s this atime story.
Although you didn't mention it here, I now remember one reason why it's
a problem for narinfos to be in the cache longer than expected: because
if a narinfo is available but the corresponding NAR isn't, it causes
problems on the client side. If that's still the case, then it
certainly justifies this change.
Thanks,
Mark