jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <>
Subject Re: BUG 61748 / Request compression
Date Mon, 07 May 2018 19:32:24 GMT
On Mon, May 7, 2018 at 8:51 PM, Felix Schumacher <> wrote:

> Am 07.05.2018 um 18:59 schrieb Vladimir Sitnikov:
>> Antonio>Do you have an idea of the performance impact?
>> I'm afraid, it is inevitable. One of the further enhancements is might be
>> sending pre-compressed *.gz files
>> Option 1 seems better for me
>> It looks so. As far as I know, request body compression is not specified
>> in
>> the standard, so using JMeter-specific "header" to trigger the compression
>> might be the right thing to do.
>> For instance:
>> X-JMeter-Content-Compression: gzip
>> Later it could be improved to:
>> X-JMeter-Content-Compression: gzip; compression_level=1   vs
>> X-JMeter-Content-Compression: gzip; compression_level=9
> Is there a chance that compression is different per request ? Can't it be
a global settings ?

Although I agree with proposition benefits, I don't find it very intuitive
for users.
If it's automatic:

   - New users or newbies don't have anything to do, it works OOTB
   - Users who have implemented the compression will indeed be impacted,
   but they are more advanced and we can suppose they'll read release notes
   and will rapidly find the issue no ?

On the contrary, If users need to add those headers:

   - It looks to me not very intuitive
   - it means we modify requests for JMeter only behaviour, it is correct ?
   Or shall we also remove headers once we compress ? which means more
   complexity in code

Anyway for all solutions we need to also modify Recorder to uncompress the
request body as it is currently compressed (binary and unreadable).

>> If we use just `Content-Encoding` to trigger the behavior, then it would
>> be
>> hard to evolve.
> +1
> If we use Content-Encoding, we could break other scripts, that have
> already compressed their payload.

I agree, but maybe a property to disable automatic compression is a

>> That means "body compression" might deserve its own set of UI checkboxes,
>> however it looks like the case is rare (neither HTTP/1 nor HTTP2 specify
>> body compression), so we might be fine to keep that behind "trigger
>> header"
>> to avoid UI clutter.
There are major ERP like Oracle that use it for example.
And I have seen the question on Stackoverflow a bunch of times. So I think
it is a real requirement.

> Right, nothing stops us from adding the ui or preprocessor or other
> mechanism after we introduce the header trigger.

> Regards,
>  Felix
>> Vladimir

Philippe Mouawad.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message