Bug 61743

Summary: Limit amount of data sent by distributed Node
Product: JMeter Reporter: gaspardzebear <gaspardzebear>
Component: HTTPAssignee: JMeter issues mailing list <issues>
Status: NEEDINFO ---    
Severity: enhancement CC: p.mouawad
Priority: P2    
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   

Description gaspardzebear 2017-11-10 14:39:23 UTC
When doing remote testing, remote nodes may send lot of datas to master. 
When remote node are in different geographical location, the bandwidth consumption is high.

None of the current mode is satisfying : 
- The statistical mode is not really usefull as it gives too few informations.
- Stripped mode truncate datas.
- Diskstore just postpones the sending of datas : the whole file is still sent as-is at the end of test.

In order to reduce the amount of data, compress the flow would limit the requested bandwith could be a good approach (for example, Diskstore mode + compression) : as most of the flow is text, it could save 70-80% bandwitdh.
Comment 1 Philippe Mouawad 2017-11-10 15:28:09 UTC
(In reply to gaspardzebear from comment #0)
> When doing remote testing, remote nodes may send lot of datas to master. 
> When remote node are in different geographical location, the bandwidth
> consumption is high.
> 
> None of the current mode is satisfying : 
> - The statistical mode is not really usefull as it gives too few
> informations.
> - Stripped mode truncate datas.
> - Diskstore just postpones the sending of datas : the whole file is still
> sent as-is at the end of test.
> 
> In order to reduce the amount of data, compress the flow would limit the
> requested bandwith could be a good approach (for example, Diskstore mode +
> compression) : as most of the flow is text, it could save 70-80% bandwitdh.

Hello,
For me stripped mode + Batch or Async does a correct job and would be better if we also stripped request content.
I don't share the thinking that Strip truncates datas, it does but not useful data  during a load test.


Zipping has some drawbacks:
- It is very costly in terms of CPU on servers
- It will not make things better as we use RMI

But if you have a working patch that shows I'm wrong, I'll be more than happy :-)

Regards
Comment 2 gaspardzebear 2017-11-10 18:24:48 UTC
Hi,

Nice to read from you (I got your book)

Sorry but I don't have a patch ;).

We have noticed this problem when trying to use Jmeter instead of the commercial product we use in my company. The generated traffic was the root cause of a network incident with impact on production. Bad news as I'm try to promote a Jmeter strategy !

We tested and at the same time monitored the traffic in various cases, and could not find a relevant solution with the different native modes in Jmeter.
 
Zip a file at the end of the test would not be a probleme in terms of CPU as the test would be over.

We'll go on exploring what we can do (maybe write a specific sample sender)

Regards
Comment 3 Philippe Mouawad 2017-11-10 19:32:43 UTC
(In reply to gaspardzebear from comment #2)
> Hi,
> 
> Nice to read from you (I got your book)

Thanks for the kind words, I'm sure the other authors will be happy to hear that !
> 
> Sorry but I don't have a patch ;).
> 
> We have noticed this problem when trying to use Jmeter instead of the
> commercial product we use in my company. The generated traffic was the root
> cause of a network incident with impact on production. Bad news as I'm try
> to promote a Jmeter strategy !
> 
> We tested and at the same time monitored the traffic in various cases, and
> could not find a relevant solution with the different native modes in Jmeter.
>  
> Zip a file at the end of the test would not be a probleme in terms of CPU as
> the test would be over.

That would be an option.
> 
> We'll go on exploring what we can do (maybe write a specific sample sender)

You can also have a look at Bug 61087
> 
> Regards