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