opened
captainsafia
username_0
This PR increases the amount of data buffered to memory before switching to buffering on disk from 30kb to 1mb. The table below highlights (requests per second, mean latency) across different combinations of input size and threshold size for this scenario.

|                 | 2kb input        | 60kb input       | 2mb input        |
|-----------------|------------------|------------------|------------------|
| 30kb threshold  | (7253.09, 37.08) | (538.29, 473.52) | (109.69, 1320.0) |
| 512kb threshold | (7424.88, 36.28) | (519.51, 486.47) | (107.7, 1350.0)  |
| 1mb threshold   | (52428.87, 7.92) | (518.21, 483.33) | (109.37, 1240.0) |
| 2mb threshold   | (51887.11, 7.95) | (521.88, 488.08) | (107.43, 1320.0) |
Increase memory buffering threshold for input formatter
issue
created
Tratcher
username_1
@davidfowl had proposed raising this to match the default request body size limit of 30mb.
comment
created
Tratcher
username_1
Any explanation why the 60kb input is the same or worse? Only the 2kb input seems to be showing improvements.
comment
created
halter73
username_2
If the numbers support this, it's an interesting idea. However, I'm hesitant to increase this limit all the way to 30 MB because today in this scenario we buffer up to 1030 KB raw bytes per HTTP/1.1 Connection (or HTTP/2 stream) AFAIK (up to 1 MB in Kestrel's input Pipe + up to 30 KB in FileBufferingReadStream's MemoryStream). Increasing this to 2 MB doesn't sound too scary. Increasing this to 31 MB seems like a huge jump.
comment
created
captainsafia
username_0
Closing this while we sort out the spookiness with the perf stats per our Teams chat.
comment