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

["Fabian Grünbichler" <f.gruenbichler@proxmox.com>]

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".

> 
> OTOH the heartbeat does not interfere much with the current request 
> logic, and is guarded behind the environment variable.
> 
> So this would be enabled under very specific conditions anyways? After 
> all it is mostly only a way out if one has no control over the proxy to 
> increase the timeout values there?
>