| Summary: | Limit amount of data sent by distributed Node | ||
|---|---|---|---|
| Product: | JMeter - Now in Github | Reporter: | gaspardzebear <gaspardzebear> |
| Component: | HTTP | Assignee: | 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
(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 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 (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 This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/4577 |