Re: SampleSender modes

[Emilian Bold]

These "modes" are actually "services". When you configure the mode in
some .properties file you basically pick which service gets used.

We should not have a SampleSenderFactory that does an `if` on modes,
we should have a more generic mechanism where any such sample sender
implementation might exist.

When looking at things like this, I don't see how a mode existing or
not bothers anybody. Why shouldn't I be able to use a RAMdisk and use
the 'DiskStore' "mode"? Did you know Google Cloud has instances with
hundreds of GB of RAM? Rather cheap too if you only needs if a few
hours!

> Any issue in network or injector will loose results.

Any reason JMeter server has to be so brittle?

Instead of dropping modes, I'd say we focus on doing a sample sender
infrastructure where bi-directional connections aren't mandatory (drop
Java RMI) and allow some network hiccups (have some buffered message
queues or something).

My 2c.


--emi


On Mon, Oct 23, 2017 at 9:19 PM, Philippe Mouawad
 wrote:
> Hi,
> Any feedback on this ?
>
> Regards
>
> On Thu, Oct 12, 2017 at 4:35 PM, Philippe Mouawad <
> p.moua...@ubik-ingenierie.com> wrote:
>
>> Hello,
>> We have currently 10 modes and I believe at least 3 of them are useless:
>>
>> - DiskStore : Probably overwhelms disks / IO and the fact that results are
>> sent at end will probably induce an important network traffic and time to
>> get the results. Any issue in network or injector will loose results.
>> - StrippedDiskStore : The fact that results are sent at end will probably
>> induce an important network traffic and time to get the results. Any issue
>> in network or injector will loose results.
>> - Hold : holds results in memory which makes it useless IMO
>>
>> I propose to drop them.
>> If anybody uses them, let him speak now or remain silent until the end of
>> times :-)
>>
>>
>> Regards
>> Philippe
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
> Ubik-Ingénierie
>
> UBIK LOAD PACK Web Site 
>
> UBIK LOAD PACK on TWITTER 

Re: SampleSender modes

[Philippe Mouawad]

On Mon, Oct 23, 2017 at 9:37 PM, Emilian Bold 
wrote:

> These "modes" are actually "services". When you configure the mode in
> some .properties file you basically pick which service gets used.
>
> We should not have a SampleSenderFactory that does an `if` on modes,
> we should have a more generic mechanism where any such sample sender
> implementation might exist.
>

Agree, feel free to provide a PR.

>
> When looking at things like this, I don't see how a mode existing or
> not bothers anybody. Why shouldn't I be able to use a RAMdisk and use
> the 'DiskStore' "mode"?


So this would justify keeping Disk modes although user wouldn't have any
feedback on test until finished...


> Did you know Google Cloud has instances with
> hundreds of GB of RAM? Rather cheap too if you only needs if a few
> hours!
>

If you're speaking about Hold mode, what about the required JVM Heap and GC
impact.
I am not convinced it should be kept and have dropped it meanwhile.
But if you think it should be kept , I am ready to reconsider.

Still, I think we have too many options here.


> > Any issue in network or injector will loose results.
>
> Any reason JMeter server has to be so brittle?
>
Lack of time and contributions,  not my priority until now



> Instead of dropping modes, I'd say we focus on doing a sample sender
> infrastructure where bi-directional connections aren't mandatory (drop
> Java RMI) and allow some network hiccups (have some buffered message
> queues or something).
>
Yes, it has been discussed in the past, but no progress made.
I'd be more than happy to consider a PR.

>
> My 2c.
>
Thanks

>
>
> --emi
>
>
> On Mon, Oct 23, 2017 at 9:19 PM, Philippe Mouawad
>  wrote:
> > Hi,
> > Any feedback on this ?
> >
> > Regards
> >
> > On Thu, Oct 12, 2017 at 4:35 PM, Philippe Mouawad <
> > p.moua...@ubik-ingenierie.com> wrote:
> >
> >> Hello,
> >> We have currently 10 modes and I believe at least 3 of them are useless:
> >>
> >> - DiskStore : Probably overwhelms disks / IO and the fact that results
> are
> >> sent at end will probably induce an important network traffic and time
> to
> >> get the results. Any issue in network or injector will loose results.
> >> - StrippedDiskStore : The fact that results are sent at end will
> probably
> >> induce an important network traffic and time to get the results. Any
> issue
> >> in network or injector will loose results.
> >> - Hold : holds results in memory which makes it useless IMO
> >>
> >> I propose to drop them.
> >> If anybody uses them, let him speak now or remain silent until the end
> of
> >> times :-)
> >>
> >>
> >> Regards
> >> Philippe
> >>
> >
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
> > Ubik-Ingénierie
> >
> > UBIK LOAD PACK Web Site 
> >
> > UBIK LOAD PACK on TWITTER 
>
> -
> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
> For additional commands, e-mail: user-h...@jmeter.apache.org
>
>


-- 
Cordialement.
Philippe Mouawad.

Re: SampleSender modes

[Philippe Mouawad]

Hi,
Any feedback on this ?

Regards

On Thu, Oct 12, 2017 at 4:35 PM, Philippe Mouawad <
p.moua...@ubik-ingenierie.com> wrote:

> Hello,
> We have currently 10 modes and I believe at least 3 of them are useless:
>
> - DiskStore : Probably overwhelms disks / IO and the fact that results are
> sent at end will probably induce an important network traffic and time to
> get the results. Any issue in network or injector will loose results.
> - StrippedDiskStore : The fact that results are sent at end will probably
> induce an important network traffic and time to get the results. Any issue
> in network or injector will loose results.
> - Hold : holds results in memory which makes it useless IMO
>
> I propose to drop them.
> If anybody uses them, let him speak now or remain silent until the end of
> times :-)
>
>
> Regards
> Philippe
>



-- 
Cordialement.
Philippe Mouawad.
Ubik-Ingénierie

UBIK LOAD PACK Web Site 

UBIK LOAD PACK on TWITTER 

SampleSender modes

[Philippe Mouawad]

Hello,
We have currently 10 modes and I believe at least 3 of them are useless:

- DiskStore : Probably overwhelms disks / IO and the fact that results are
sent at end will probably induce an important network traffic and time to
get the results. Any issue in network or injector will loose results.
- StrippedDiskStore : The fact that results are sent at end will probably
induce an important network traffic and time to get the results. Any issue
in network or injector will loose results.
- Hold : holds results in memory which makes it useless IMO

I propose to drop them.
If anybody uses them, let him speak now or remain silent until the end of
times :-)


Regards
Philippe