jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: BUG 61748 / Request compression
Date Mon, 07 May 2018 19:48:46 GMT
On Mon, May 7, 2018 at 9:42 PM, Felix Schumacher <
felix.schumacher@internetallee.de> wrote:

> Am 07.05.2018 um 21:32 schrieb Philippe Mouawad:
>
>> 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
>>
> 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.
>
True

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

Yes that's why I liked it as "advanced user" , but disliked it trying to
figure out how newbie would do it :-)

>
>     - 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
> compressed.
>
I agree, but from your last answer below, it looks you finally favor a GUI
option ?

>
>
>> 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?
>

Can we guess that underlying compressed content is text ?


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

So we go for GUI , not particular header right ?
I agree with this, we should make it editable so that a variable or
property can be used.

>
> Regards,
>  Felix
>
>
>
>>
>> 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.

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