Don't decompress responses by default

[jgaalen]

Use case

When an HTTP Response is received, it is always decompressed before storing it in the 'responseData'. This is a waste of cpu and memory resources in the majority of the cases when the responseData is never used. Especially for heavy javascript and stylesheets, it can be a waste when the response isn't used for an extractor or assertion.

Imagine how much memory can be saved if we store the compressed content and don't decompress by default, and only decompress when the responseData is accessed. We could even safe more memory if we never store the response headers and body if the result isn't used.

Possible solution

Best solution:
Check if a sampler has extractor or assertion, only then decompress and store response data (header and body)

Improved solution
In case it is hard to detect whether the result will be accessed by code (jsr223, preprocessor of subsequent sampler etc), we can store the response data as is without decompressing upfront. In case the response data is accessed, then it should be decompressed.

We can even consider not storing the response data by default and use a flag on the sampler if we need to store it because future code need to access the data.

Possible workarounds

No response

JMeter Version

5.6.3

Java Version

OS Version

[vlsi]

This is an interesting idea indeed.

[ra0077]

In some others tools, you need to add .saveAs("") at the end of the http request to save the response

[jgaalen]

The idea of not doing anything with the response data (not decompressing it, not storing it), is actually pretty tough to do. To detect an assertion or postprocessor is actually easy. It it a lot harder to detect if the next sampler needs the previous result. It is also hard to detect which attached listeners actually might need the responseData.

Easiest implementation would be to not decompress in the HTTPHC4Impl.java sampler, but return the raw body + content encoding, and do the decompression in getResponseData(). This will save a lot of bulk memory (heavy javascripts being added) and some cpu time for decompression.

[vlsi]

Easiest implementation would be to not decompress in the HTTPHC4Impl.java sampler, but return the raw body + content encoding, and do the decompression in getResponseData(). This will save a lot of bulk memory (heavy javascripts being added) and some cpu time for decompression.

Frankly, I thought it was the best way to go as well.

[ra0077]

My opinion:

• not decompress in the HTTPHC4Impl.java sampler, but return the raw body + content encoding, and do the decompression in getResponseData().
• Add a checkbox in http sampler to allow saving response (header + body) set to true by default (to don't change default behaviour)

It will allow advanced users don't waste memory + cpu if the user knows it will not be used (Gatling do this and Neoload don't save by default if I have well understood)