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 - 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 ? On the contrary, If users need to add those headers: - It looks to me not very intuitive - 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 Anyway for all solutions we need to also modify Recorder to uncompress the request body as it is currently compressed (binary and unreadable). > >> 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. Ubik-Ingénierie UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/> UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>
