jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Schumacher <>
Subject Re: BUG 61748 / Request compression
Date Mon, 07 May 2018 19:42:21 GMT
Am 07.05.2018 um 21:32 schrieb Philippe Mouawad:
> 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
That is always a plus.

>     - 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 ?
I dare say, that this is not always (mostly not) the case and it is not 
clear, whether the original advanced users are still the ones that run 
(and debug) the tests.

> On the contrary, If users need to add those headers:
>     - It looks to me not very intuitive
That is right, but it is safe.

>     - 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
I think it would be best to remove the custom header after the part is 

> Anyway for all solutions we need to also modify Recorder to uncompress the
> request body as it is currently compressed (binary and unreadable).
If the body is compressed and the header stays intact, there is no need 
to compress it and no need for a custom header, if you want to send the 
compressed body, only.

If you want to display the content, it would probably better to 
uncompress it, but that would only be useful for text like content, 
wouldn't it?

All in all, a GUI change looks like good alternative to these problems. 
It could be intuitive, it can be selectively enabled and it is 
compatible with the old behaviour, if defaults are set correctly.


>>> 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
> solution.
>>> 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

View raw message