You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Janis Bruveris <jb...@evolutiongaming.com> on 2019/09/26 13:01:53 UTC
Disable sending sample data via command line prop
The problem is that i wan to first dry-run tests plans without sending data to influxDB before the full run because our application heavily relies on server-side caching. As a result initial response times after deployment are 3-4 times slower then normally and it skews statistics.
I couldn't find a way to control this via command line for use in jenkins pipeline (could be useful for other uses as well)
If nobody has better solution i propose adding a “listener.enabled” flag to BackendListener with corresponding checks in a couple of methods.
I have a working POC, if this feature is deemed necessary.
Re: Disable sending sample data via command line prop
Posted by Janis Bruveris <jb...@evolutiongaming.com>.
Not really since every thread group contains many tens of requests. I’m not even considering duplicating them
> On 26 Sep 2019, at 16:05, Philippe Mouawad <ph...@gmail.com> wrote:
>
> Hello,
> You could use Setup Thread Group to do the initial dry run,
> And put the BackendListener as a child of the Thread Group, it won't
> receive anything from Setup Thread Group
>
> Would this suit your need ?
>
> Regards
> Philippe M.
> @philmdot
>
> On Thu, Sep 26, 2019 at 3:02 PM Janis Bruveris <
> jbruveris@evolutiongaming.com> wrote:
>
>> The problem is that i wan to first dry-run tests plans without sending
>> data to influxDB before the full run because our application heavily relies
>> on server-side caching. As a result initial response times after deployment
>> are 3-4 times slower then normally and it skews statistics.
>> I couldn't find a way to control this via command line for use in jenkins
>> pipeline (could be useful for other uses as well)
>>
>> If nobody has better solution i propose adding a “listener.enabled” flag
>> to BackendListener with corresponding checks in a couple of methods.
>> I have a working POC, if this feature is deemed necessary.
>>
>>
>
> --
> Cordialement.
> Philippe Mouawad.
Re: Disable sending sample data via command line prop
Posted by Philippe Mouawad <ph...@gmail.com>.
Hello,
You could use Setup Thread Group to do the initial dry run,
And put the BackendListener as a child of the Thread Group, it won't
receive anything from Setup Thread Group
Would this suit your need ?
Regards
Philippe M.
@philmdot
On Thu, Sep 26, 2019 at 3:02 PM Janis Bruveris <
jbruveris@evolutiongaming.com> wrote:
> The problem is that i wan to first dry-run tests plans without sending
> data to influxDB before the full run because our application heavily relies
> on server-side caching. As a result initial response times after deployment
> are 3-4 times slower then normally and it skews statistics.
> I couldn't find a way to control this via command line for use in jenkins
> pipeline (could be useful for other uses as well)
>
> If nobody has better solution i propose adding a “listener.enabled” flag
> to BackendListener with corresponding checks in a couple of methods.
> I have a working POC, if this feature is deemed necessary.
>
>
--
Cordialement.
Philippe Mouawad.
Re: Disable sending sample data via command line prop
Posted by Jmeter Tea <jm...@gmail.com>.
There's a related enhancement for Add option to disable View Results
Tree/Listeners in non GUI:
https://bz.apache.org/bugzilla/show_bug.cgi?id=62495
FYI
On Thu, Sep 26, 2019 at 4:02 PM Janis Bruveris <
jbruveris@evolutiongaming.com> wrote:
> The problem is that i wan to first dry-run tests plans without sending
> data to influxDB before the full run because our application heavily relies
> on server-side caching. As a result initial response times after deployment
> are 3-4 times slower then normally and it skews statistics.
> I couldn't find a way to control this via command line for use in jenkins
> pipeline (could be useful for other uses as well)
>
> If nobody has better solution i propose adding a “listener.enabled” flag
> to BackendListener with corresponding checks in a couple of methods.
> I have a working POC, if this feature is deemed necessary.
>
>