Add Gzip middleware to fastapi, and score set search parameter to optionally skip experiment score set URNs and count

[davereinhart]

Improves overall performance by adding gzip middleware to fastapi to compress large responses.

Adds new optional boolean parameter to ScoreSetsSearch and updates score set search endpoint to make retrieval of parent experiment score set URNs and count optional.

[bencap]

Thanks for this, should be a big improvement.

I was thinking about the settings and realizing that we don't really have a good way to decide what is appropriate for our application. I think the 1000 minimum size and compression level 5 are reasonable and there's a good chance we won't ever have to change them, but I think it might also be worthwhile to add a log entry to the log_request logging function that can give us some better insight into the sizes of the responses we are dealing with. It would've been nice to have been able to pull up the last few months of traffic and seen how large responses actually were in practive. There is probably a way to do this in the elastic load balancer logs too, but a snippet like the below might be easier and more centralized in the existing logging than doing that.

async def log_request(request: Request, response: Response, end: int) -> None:
...

        size = None
        content_length = response.headers.get("content-length")
        if content_length:
            try:
                size = int(content_length)
            except ValueError:
                size = None
        if size is None:
            body = getattr(response, "body", None)
            if isinstance(body, (bytes, bytearray)):
                size = len(body)
        if size is None:
            size = 0  # streaming or unknown
        save_to_logging_context({"response_size_bytes": size})

...

I can open a new issue for this if you'd rather just merge the existing code, it looks good to me.

[davereinhart]

@bencap Once this change is deployed, wouldn't the content-length header just show the size of the compressed response? If that's the case, this type of logging may not be as informative as if were put in place beforehand.

[bencap]

@bencap Once this change is deployed, wouldn't the content-length header just show the size of the compressed response? If that's the case, this type of logging may not be as informative as if were put in place beforehand.

Hmm yeah that's true, I guess for it to work properly with these changes we'd need to inject a pre-compressed content length into the logging context via a middleware that runs prior to the gzip compression.