Pre-allocate the buffer based on the expected Content-Length with the Rust HTTP client

[MadLittleMods]

Pre-allocate the buffer based on the expected Content-Length with the Rust HTTP client

Spawning from looking at some traces and seeing the Synapse Rust HTTP client taking way longer than what the Synapse Pro Event Cache claims it was able to respond in (added some better tracing for that). I don't think this specific change will have a meaningful impact but just something I saw (pre-optimization).

Example Trace-845fb3-2026-02-27 16_32_24.json

Dev notes

This kind of delay also reminds me of TCP_NODELAY problems but we already define that on the Synapse Pro Event Cache side.

---

u64/usize

Pull Request Checklist

• Pull request is based on the develop branch
• Pull request includes a changelog file. The entry should:
  • Be a short description of your change which makes sense to users. "Fixed a bug that prevented receiving messages from other servers." instead of "Moved X method from EventStore to EventWorkerStore.".
  • Use markdown where necessary, mostly for code blocks.
  • End with either a period (.) or an exclamation mark (!).
  • Start with a capital letter.
  • Feel free to credit yourself, by adding a sentence "Contributed by @github_username." or "Contributed by [Your Name]." to the end of the entry.
• Code style is correct (run the linters)

[MadLittleMods]

For reference, response.content_length() does exist but

This value does not directly represents the value of the Content-Length header, but rather the size of the response’s body. To read the header’s value, please use the Response::headers method instead.

We want to avoid reading the entire body at this point as we stream it below to avoid allocating a giant object on the server as we want to reject anything above the response_limit.

[sandhose]

I think this is a good first step for making this more efficient.

[sandhose]

I am a bit sceptical of that manual chunk aggregation though.

Fine with making it better in another PR, but we could:

• extract the underlying body with axum::Body::from(response)
• wrap it with http_body_util::Limited::new(body, limit)
• collect it in a list of buffers like limited_body.collect().await
• convert it to a bytes::Bytes
• return that directly, making sure we have the right feature enabled for pyo3 to support its conversion

Each of those steps are supposedly quite efficient: collecting the body in a list of buffers is done by moving references, aggregating that to a contiguous buffer pre-allocates the right size, and the conversion from bytes::Bytes to PyBytes is also done without copy.

Another thing we could make better, is that if we know that we're consuming it as a string, we may want to do the bytes->str conversion in Rust-land? Even one step further, what if we did the JSON parsing on the Rust side with something like pythonize?

EDIT: I've done some benchmarking: https://gitlab.element.io/quenting/pyo3-json-benchmark

[MadLittleMods]

Previous discussion on using http_body_util::Limited #18357 (comment)

[MadLittleMods]

Sounds like a good improvement 👍 I've tackled the first part of this in #19510

Only weird thing I noticed in your description was:

and the conversion from bytes::Bytes to PyBytes is also done without copy.

As the docs actually say this:

When converting Bytes back into Python, this will do a copy, just like &[u8] and Vec<u8>.

-- https://docs.rs/pyo3/latest/pyo3/bytes/index.html

But that sounds just as equivalent to before ⏩

---

We can explore the JSON stuff further once we have some better traces to nail down whether that's the problem.

For example, if I recall correctly, that trace example in the PR description is from a single event (not big JSON parsing)

[MadLittleMods]

Let's still go for merging this PR even though #19510 supersedes it after

[MadLittleMods]

Thanks for the review and plan for a better future @sandhose 🐸