jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Schumacher <felix.schumac...@internetallee.de>
Subject Re: BUG 61748 / Request compression
Date Mon, 07 May 2018 19:57:21 GMT
Am 07.05.2018 um 21:48 schrieb Philippe Mouawad:
> 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.
It depends on who your audience is.

For advanced users the custom header would be an easy starter, that will 
not break anything (famous last words).

For a normal user, the GUI would probably be better, as it has no side 
effects apart from the more complex GUI.

At the moment I have a slight tendency for the GUI option, but as you 
want to implement it, I am OK with any of those.

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


Mime
View raw message