[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 01/01: nginx: berlin: Disable narinfo caching altogether.
From: |
Ludovic Courtès |
Subject: |
Re: 01/01: nginx: berlin: Disable narinfo caching altogether. |
Date: |
Sun, 24 Jun 2018 00:20:59 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Hello,
Mark H Weaver <address@hidden> skribis:
> 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.
Yes, that too.
We’ll see how it goes and if it performs badly let’s revert or adjust.
Ludo’.