Re: [PATCH proxmox-backup 1/2] fix #6373: HTTP level reader heartbeat for proxy connection keepalive

[Christian Ebner <c.ebner@proxmox.com>]

On 4/15/26 1:47 PM, Fabian Grünbichler wrote:
> On April 15, 2026 1:22 pm, Christian Ebner wrote:
>> On 4/15/26 12:59 PM, Fabian Grünbichler wrote:
>>> On April 15, 2026 10:45 am, Christian Ebner wrote:
>>>> On 4/15/26 10:32 AM, Fabian Grünbichler wrote:
>>>>> On January 29, 2026 1:26 pm, Christian Ebner wrote:
>>>>>> Backup readers can have long periods of idle connections, e.g. if a
>>>>>> backup snapshot has been mounted and all relevant chunks are locally
>>>>>> cached or a backup session with previous metadata archive not needing
>>>>>> to fetch new contents while the backup is ongoing.
>>>>>>
>>>>>> Proxies like e.g. HAProxy might however close idle connections for
>>>>>> better resource handling [0,1], even multiplexed HTTP/2 connections as
>>>>>> are being used for the Proxmox Backup Sever backup/reader protocol.
>>>>>>
>>>>>> This mainly affects the backup reader, while the backup writer will
>>>>>> do indexing and chunk uploads anyways.
>>>>>
>>>>> but if the storage is slow, there might not be chunk traffic for a few
>>>>> seconds as well?
>>>> So you suggest to implement the same for the backup writer as well?
>>>
>>> I am wondering whether it wouldn't make sense (though I guess 5s is
>>> quite agressive anyway, and higher idle timeouts make it unlikely to
>>> trigger in practice?)
>>
>>
>> Yes, I think for the writer this is way less relevant.
>> Only the super slow storage case where the chunk is uploaded quickly,
>> but then the storage takes ages to write it.
> 
> I was more worried about the *reading* being slow client-side, and thus
> the chunk stream having big pauses between chunks, in particular when a
> lot/most/all chunks are read, but not uploaded.
> 
> e.g., if I ratelimit the input side to 10MB/s for an incremental backup,
> there's long breaks between traffic from proxmox-backup-client to
> proxmox-backup-proxy, roughly every 2m there's some sort of lower-level
> keep-alive mechanism, and otherwise there is only traffic whenever the
> client has read 128 re-used chunks (with 2.5 chunks/second that takes a
> while in this example ;)) or some non-incremental data comes along and
> forces a "flush".

Yeah, so we can conclude it makes sense to have it for the writer as 
well. So if agreed, I would add this controlled by 
PBS_WRITER_HEARTBEAT_TIMEOUT then.