jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <p.moua...@ubik-ingenierie.com>
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 <
felix.schumacher@internetallee.de> 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
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
>>
>>
>


-- 
Cordialement.
Philippe Mouawad.
Ubik-Ingénierie

UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/>

UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>

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