AS far as i understand, if you want to define some variable that can be shared among thread groups, use USER DEFINED VARIABLE component. The variables defined in it have global scope.
Best Regards, Hemant 9810752184 / 9013982184 On 02-Jun-2016 5:47 AM, "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. >
