From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Dominik Csapak <d.csapak@proxmox.com>
Subject: [pve-devel] applied: [PATCH http-server] fix #6230: increase allowed post size
Date: Thu, 3 Apr 2025 18:10:39 +0200 [thread overview]
Message-ID: <742a0bf6-2e62-4c64-8f16-1674be14ba01@proxmox.com> (raw)
In-Reply-To: <20250403082759.2506153-1-d.csapak@proxmox.com>
Am 03.04.25 um 10:27 schrieb Dominik Csapak:
> In some situations, e.g. having a large resource mapping, the UI can
> generate a request that is bigger than the current limit of 64KiB.
>
> Our files in pmxcfs can grow up to 1 MiB, so theoretically, a single
> mapping can grow to that size. In practice, a single entry will have
> much less. In #6230, a user has a mapping with about ~130KiB.
>
> Increase the limit to 512KiB so we have a bit of headroom left.
>
> We have to also increase the 'rbuf_max' size here, otherwise the request
> will fail (since the buffer is too small for the request). Since the
> post limit and the rbuf_max are tightly coupled, let it reflect that in
> the code. To do that sum the post size + max header size there.
>
> A short benchmark shows that it only slightly impacts performance for
> the same amount of data (but that could be runtime variance too):
>
> I used a 4 node virtualized cluster, benchmarked with oha[0] with these
> options:
>
> oha --insecure -H $COOKIE -H $CSRFTOKEN -D bodyfile -m "PUT" -T
> "application/x-www-form-urlencoded" -n 3000 -c 50 --disable-keepalive
> --latency-correction https://<IP>:8006/api2/json/cluster/mapping/pci/test
>
> So 3000 requests with 50 parallel. I also restarted pveproxy and daemon
> in between runs, and took the rss values around the 50% runtime of the
> benchmark.
>
> average time requests/s pvedaemon rss pveproxy rss
> old with 60k body 3.0067s 16.3487 140M-155M 141M-170M
> new with 60k body 3.0865s 15.7623 140M-155M 141M-171M
> new with 180k body 8.3834s 5.8934 140M-158M 141M-181M
>
> Using a bigger body size had a large impact on the time, but that's IMHO
> expected. Also, RSS is not that much impacted, only when using many
> requests with larger request size, but this should also be expected.
>
> 0: https://github.com/hatoo/oha
>
> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
> ---
> changes from rfc:
> * s/buffer/headroom
> * added benchmark data to the commit message
> * corrected rbuf_max calculation
>
> src/PVE/APIServer/AnyEvent.pm | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>
applied, thanks!
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
prev parent reply other threads:[~2025-04-03 16:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-03 8:27 [pve-devel] " Dominik Csapak
2025-04-03 16:10 ` Thomas Lamprecht [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=742a0bf6-2e62-4c64-8f16-1674be14ba01@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=d.csapak@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.