feat: add gzip middleware enabled by default for >1000 bytes#400
feat: add gzip middleware enabled by default for >1000 bytes#400recalcitrantsupplant wants to merge 1 commit intomainfrom
Conversation
|
I've thought about using the gzip plugin a few times, but never tired it. I expect the Fastapi GzipMiddleware only compresses if the request has "Accept-Encoding: gzip" in the headers. I'm not sure how many clients would support that, but it could be more than I think. I always thought the overhead of compressing the output and decompressing it on receiving, would add more latency than its saving. But I'm happy to experiment with this. Also, does this work on FastAPI StreamingResponse types? How does it compress the http body if the http body is being produced by an async generator in a StreamingResponse? And a StreamingResponse often does not have a known body size when it is sent, so the middleware doesn't know if its greater than min size. |
|
I'll be testing this with arc map SDK which does add the accept encoding header by default - we're seeing 20-50 MB responses so should give a good indication as to whether it helps at that size.
Not sure, perhaps it doesn't, will need to look into this. |
|
I'll leave this as a draft until we're able to answer Ashley's question above + would also like to get some benchmarks |
Adds the default GZipMiddleware available in FastAPI.
Opt out feature.
Min size before compression is used is set with new config setting:
gzip_min_size. Default value is 1000 bytes for no particular reason; 500 or 1000 values are common.To disable compression altogether set
gzip_min_size=-1i.e. the behaviour prior to this PR.Didn't see much performance difference in local testing i.e. API and browser on same machine - I imagine it will help in non local settings particularly with larger responses. Would be good to get some rough numbers to back this up.