time execution not decreased

[chenbeh]

I have a question about the execution time.
Of course , the raw json input file will be larger than the gzipped one.
What I am expecting to have, is to decrease the time execution and to increase RPS.
Decreasing the input file size will automatically decrease the transfer time between client <==> server, which will automatically enhance the time performance on the server.
When I tried flask-inflate, everything was working as expecting and we are getting the correct response with and wihtout compression.
The only problem that make me confused, is that the execution time is not decreasd at all.
Any idea why this is happening ?

[ronlut]

Hi @chenbeh, thanks for using flask-inflate.
There may be a number of reasons for that behavior, and I will ask some questions that may guide you to understand the reason for that:

1. Are you working with text? If not, compressing and decompressing usually just adds unnecessary overhead and costs you CPU time. Avoid compressing images, audio, video and so on.
2. What is the average size of the payload you are sending? If it's small, It's possible that the compress/decompress overhead is bigger than sending a small amount of additional bytes.
3. Is your CPU limited (cgroups) or overcommitted on the sender's or receiver's side? This may cause the de/compression be slow.
4. On what network are you running? This as well may cause de/compress to add overhead that is bigger than sending the raw data over the wire.
5. Are you sure you enabled/disabled compression when you were testing?
6. How did you run your tests?

[chenbeh]

hi @ronlut, thanks for your quick reply:
we have already verified the points that you have mentionned and this is a clarification for each question, maybe you will have further ideas to solve the problem:
1-2- we are not working with text, we are working with JSON(if it is not considered as text), we are sending our requests using postman and we are passing the JSON as binary. The compressed JSON size is quite smaller than the raw JSON. we are going from 700KB to only 10KB.
3- in our test we are using the same server resource that we were using with another compression approach and the RPS is enhanced with the last approach. We checked also the decompression time and it is negligible.
4- the same here, we are using the same network resources and we are comparing with another compression approach
5- yes we are sure. We checked how when and how the compression is disabled and enabled.
6- using POSTMAN
So far, I would say that your solution is quite good and your idea to use the before_request decorator was the best solution that we found.
I was talking about another compression approach that we were using. To explain more, before we were sending a compressed file instead of a compressed binary JSON, and we are decompressing the file at our API endpoint level. This solution is not good for us, since we wanna that our endpoint to always expect a JSON (compressed or not) always.

[ronlut]

@chenbeh Do you have some test to help me check the scenario you are describing?
If not, I hope I'll have time on Friday to check it up.

[ronlut]

Hi @chenbeh, please take a look on some benchmarks I added and their source code.
You can run them yourself if you want.
Regarding your question, I don't know your exact inputs and network conditions, but I don't think flask-inflate causes you to lose the benefits of de/compression.

There is a small degradation in performance (about 1-2%) when using the library compared to doing the decompression in the function itself. I couldn't figure it out in the limited time I had. If you have any idea or want to help investigate you are more than welcome.
This line: gzip.decompress(request.stream.read()).decode() runs faster than this: gzip.GzipFile(fileobj=request.stream).read().decode(). This is what causes the minor performance hit from what I understand.

[boesing]

@ronlut oh, @chenbeh is a colleague 😄
but anyways, thanks for investigating here 👌🏻

I've already thought about the fact, that flask executes flask-inflate in the main thread and then passes the decompressed request to a new thread to process requests asynchronously. But tbh, I am not that familiar with flask or Python but that was a guess I took when I realized that the exact same code was executed faster when using gunzip in the endpoint rather than a decorator.

Is flask using multithreading to process http requests?