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 18:51:05 GMT
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
>
> 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.

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