Thanks Deepak, setup thread group with b.3 is probably what I'm looking for, I'll give that a try.
This email has been sent from a virus-free computer protected by Avast. www.avast.com <https://www.avast.com/sig-email> <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Wed, Jun 1, 2016 at 9:05 PM, Deepak Shetty <[email protected]> wrote: > There is probably two parts to your answer > a. To execute something once for the entire test - this can be done with a > setup Thread group > > http://jmeter.apache.org/usermanual/component_reference.html#setUp_Thread_Group > b. Sharing data globally > The out of box constructs are > b.1 Properties (but that effectively means you need a String representation > of the the data - which is possible if you are willing to parse and reparse > data - effectively provide a string representation like a JSON/XML object - > not really nice) > b.2 BeanShell shared object - bsh.shared > http://jmeter.apache.org/usermanual/best-practices.html > b.3. - Just create a java object that can hold onto data and is accessed > statically so all callers get the same data (or whatever you desire) . The > setup thread group will "set" data into this object and the rest of the > test can get it > - you could write a custom function if you wanted to make it easy to get > the data. > > regards > deepak > > On Wed, Jun 1, 2016 at 5:16 PM, David Luu <[email protected]> wrote: > > > Is there any facility in JMeter already to define code/script based > > configuration once for threads or thread groups to then use later on? > > Meaning a single execution is done to dynamically generate the needed > test > > data (and utility methods) at test startup, then this whole config > "object" > > is referenced by threads in thread groups later on during the actual test > > run. > > > > Browsing over the JMeter docs, I'm not aware if that already exists, or > how > > best to implement this. Basically, in terms of JMeter extensions/plugins, > > I'm thinking of a config element that's like a static class or singleton, > > don't want each thread trying to instantiate their own instance. And/or > > something similar to user defined variables at the test plan root level, > > only the variable is a Java object/struct rather than simple string (that > > could be typecasted to int) - or that defining the Java object is a lot > of > > logic that can't simply be done with JMeter functions to then flatten > > object (serialized) to JSON string. > > > > If there already is such facility & best practice, that would be great > as I > > don't want to have to deal with instance checking, synchronization, and > > thread safety myself unless I have to, when instantiating the globally > > shared data across threads. Nor do I want each thread to have their own > > "copy" as that eats up memory/resources as we scale the load up. > > > > I'm currently using a Java-based config element based off the CSV Data > Set > > Config (from kafkameter project). Would placing the config element under > > test plan rather than under a thread group affect how it executes? E.g. > > execute once and result/output global to all threads, or would it also be > > executed X times for X threads, being globally used by them all, but not > > global in the sense of being already executed once with its output > readily > > accessible? > > > > This discussion would be with respect to things like config elements, or > > say pre-processors, in Java, Beanshell, javascript - but in the global > > execute once context rather than execute per thread, while providing its > > output (as JMeter variables, etc.) being global to all threads. > > >
