On 14/05/2008, Ian Blavins <[EMAIL PROTECTED]> wrote: > G'day > > If you have the skills to write a Java sampler you may be able to use one to > give you the behavior you require. > > I have set my tests up so that I have one include module that does the bulk > of the work of every test plan with just minimal, test-specific, information > in the calling test plan. (This was done to reduce test plan maintenance). > > But to get this to work properly I had to have thread specific variables and > in the end I defined a Java sampler that doesn't call any servers - it is > effectively a new type of user written control element. > > This sampler does simple functions like incrementing variables and so on - > you pass it the name of (its internally defined) function that you wish to > execute (such as increment) and the input data. The input data can include > the thread number so you can keep thread specific variables, probably in > static memory. You use a regular expression parser to get the value back out > of the response (which contains nothing but the output data value). > > One of its other virtues is that being a sampler it is easier to understand > when it is called and so the scope of updates to variables. > > The overhead of the extra sampler is very small. > > This sounds a like a pain to do but once you have cracked cutting your own > Java sampler you open up a lot of new possibilities at only marginal further > cost. There is a template Java sampler to copy in the JMeter materials. > >
You can use the Beanshell Sampler for prototyping this. Or using the BSF Sampler, but there is a bug which causes problems when using javascript (now fixed in SVN). This bug does not affect beanshell (but the BSH sampler is better for that); I don't know if it affects any other languages as I've not tried any (they need to be downloaded). A sampler can return null; this avoids generating spurious samples - c.f. Test Action sampler. > > > Ian Blavins > Software performance specialist > . > TEMENOS > The Banking Software Company > . > PeopleBuilding 2, Maylands Av > Hemel Hempstead UK HP2 4NW > . > T: +44 (0) 1442 431 106 > E: [EMAIL PROTECTED] > . > www.temenos.com > . > Consider the environment. Please don't print this e-mail unless you really > need to. > > > -----Original Message----- > From: Steve Kapinos [mailto:[EMAIL PROTECTED] > Sent: Tuesday, 13 May 2008 11:50 PM > To: JMeter Users List > > Subject: RE: Variable problems when using include controllers > > I'm sorry, but that flat out makes no sense to havee UDV's be common > across the entire testplan while Variable's themselves are only local to > a singular thread. If I want the variable in another threadgroup, I'll > define it there - since I know its only going to be used locally - it > makes sense to define it locally. > > This makes it harder and harder to script jmeter effectivly. I'm > already passing in almost a dozen properties to execute the testing and > to have to multiply that purely because I can't define a variable per > threadgroup is getting tiresome. > > Can I hack around it by defining the variable in each threadgroup in a > User Parameter Element rather then using UDV? > > -----Original Message----- > From: sebb [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 13, 2008 5:44 PM > To: JMeter Users List > Subject: Re: Variable problems when using include controllers > > UDVs are configuration elements, and they are processed as the test plan > is started. > > They should only be used for variables that don't change during a run. > > They are also shared between all threads in all groups - see the note at > the end of the section: > > http://jakarta.apache.org/jmeter/usermanual/component_reference.html#Use > r_Defined_Variables > > > On 12/05/2008, Steve Kapinos <[EMAIL PROTECTED]> wrote: > > Parent test plan is setup as > > > > Testplan > > + threadgroupPTP > > + + include controller > > + threadgroupMPS > > + + include controller > > + threadgroupVCS > > + + include controller > > + threadgroupmonitor > > + (bunch of stuff) > > > > Each include controller inserts a free-standing testplan, that each > > work independantly and test out fine on their own. > > > > Each testplan as a UDV where a variable logdir is defined as > > ${__P(p_logs-out,ptp-out)} where 'ptp-out' changes for each > testplan: > > mps-out, vcs-out, etc. ${logdir} is then used to define the > > listener's output directory for each test. Currently no p_logs-out > > property is defined, so each test should use its default assigned > > value, and this works fine when each test is ran on its own. > > > > However, when the tests are included as shown above, each included > > test executes using the same value for ${logdir} so all log files go > > into the same directory. Since variables are thread-specific this > > should not happen. They all manage to use 'vcs-out' as their value, > > so the last read in UDV for some reason is overwriting the variable > > definition for all threads, not just its own. > > > > Steve Kapinos > > Solution Developer - R&D > > TANDBERG > > > > Phone: +1 703 7094272 > > Video: [EMAIL PROTECTED] > > E-mail: [EMAIL PROTECTED] > > > > 1860 Michael Faraday Dr > > Reston, VA 20190, USA > > > > www.tandberg.com > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
