Am 07.05.2018 um 21:48 schrieb Philippe Mouawad:
On Mon, May 7, 2018 at 9:42 PM, Felix Schumacher <
[email protected]> wrote:
Am 07.05.2018 um 21:32 schrieb Philippe Mouawad:
On Mon, May 7, 2018 at 8:51 PM, Felix Schumacher <
[email protected]> 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
