I changed the previous test plan for case 4, i forgot to change one little detail.
On Thu, Aug 27, 2009 at 8:17 PM, Adrian Speteanu<asp.ad...@gmail.com> wrote: > case 3: > - random controller directly in disabled thread group (module > controller referencing it) : number of results is twice as much as > expected (for 5 loops, 10 results). this time the samples aren't > randomised any more (just like they are in a simple controller) > > case 4: > - random controller directly in the thread group with the loop > Thread Group 1 (1 thread 1 loop) > +loop controller (5 times) > \- module controller that refferences to the random controller bellow > +random controller > Expected 5+2, results tree shows 11 samples - this is the weirdest and > it happens the same each time I try it. > > well at least the numbers are predictable, this way one can anticipate > the loops number really required in order to get the expected results > :). > > On Thu, Aug 27, 2009 at 7:58 PM, Deepak Shetty<shet...@gmail.com> wrote: >> One last thing , move the recording controller to its own disabled Thread >> Group >> Thread Group 1 (1 thread 1 loop) >>> +loop controller (5 times) >>> \- module controller that refferences to the group2/simple controller >> bellow >> >> Thread Group 2 (Disabled) >>> +recording controller >>> simple Controller >>> \- random controller (under which samples are recorded with the proxy >>> server) >>> \- http sampler 1 >>> \- http sampler 2 >> >> regards >> deepak >> >> On Thu, Aug 27, 2009 at 9:52 AM, Adrian Speteanu <asp.ad...@gmail.com>wrote: >> >>> Still not working right, however I got it a little wrong about the >>> number of results: >>> >>> case 1: >>> - random controller is directly in the recording controller: for 5 >>> loops, I get 15 results (not 10 as mentioned in previous mail). >>> >>> case 2 >>> - deepak's recommendation, random controller in simple controller: the >>> number of results is higher with one than expected, but still not >>> right. >>> >>> weird, isn't it? >>> >>> [test environment] >>> xp pro >>> jre 6 update 7 >>> jmeter 2.3.4 >>> >>> >>> On Thu, Aug 27, 2009 at 7:33 PM, Deepak Shetty<shet...@gmail.com> wrote: >>> > Can you retest with ading a simple controller as the parent of the random >>> > and point your module controller to it? im not sure if the module >>> controller >>> > includes all the children under it or includes the parent as well.. >>> > >>> > +loop controller (5 times) >>> > \- module controller that refferences to the simple controller bellow >>> > +recording controller >>> > simple Controller >>> > \- random controller (under which samples are recorded with the proxy >>> > server) >>> > \- http sampler 1 >>> > \- http sampler 2 >>> > >>> > On Thu, Aug 27, 2009 at 9:26 AM, Adrian Speteanu <asp.ad...@gmail.com >>> >wrote: >>> > >>> >> Hi guys, I was experimenting with an idea that doesn't require coding >>> >> and found a little bug: >>> >> >>> >> Make a test plan like this >>> >> thread group (threads = 1, ramp = 1, loops = 1) >>> >> +loop controller (5 times) >>> >> \- module controller that refferences to the random controller bellow >>> >> +recording controller >>> >> \- random controller (under which samples are recorded with the proxy >>> >> server) >>> >> \- http sampler 1 >>> >> \- http sampler 2 >>> >> +results tree >>> >> >>> >> the actual results of this running with one thread was 10 samples in >>> >> the results tree. it looks like the random controller acted like a >>> >> random order controller in this case. >>> >> >>> >> the same issue occurs if the module controller is directly in the >>> >> thread group and the loops = 5. >>> >> >>> >> same happens to you? (couldn't found a known bug in bugzilla searching >>> >> for random controller) >>> >> >>> >> On Thu, Aug 27, 2009 at 6:55 PM, Deepak Shetty<shet...@gmail.com> >>> wrote: >>> >> > Hi >>> >> > you could do this with BSH, You'd have to write some java code that >>> can >>> >> get >>> >> > 6 strings from 250 randomly from a file and set those as variables >>> that >>> >> can >>> >> > be iterated over(using forEach , your variables would have the names >>> like >>> >> > url_1 , url_2 and the foreach would iterate over url , you'd just need >>> >> one >>> >> > sampler). You can tweak the BSH to do whatever you want (i.e. vary the >>> >> total >>> >> > number or read a single value randomly) >>> >> > regards >>> >> > deepak >>> >> > >>> >> > On Thu, Aug 27, 2009 at 8:49 AM, E. Doherty <dohert...@gmail.com> >>> wrote: >>> >> > >>> >> >> Greetings! I'm new to JMeter, and I'm trying to replicate something >>> >> >> that was easy to do back in my LoadRunner days. >>> >> >> >>> >> >> For "background" activity when testing specific things, I would >>> create >>> >> >> a LoadRunner script in which a Vuser viewed, say, six different >>> pages. >>> >> >> I would then parameterize the six URLs, and on each occurrence a URL >>> >> >> would be chosen randomly from a file that contained the 250 most >>> >> >> popular URLs on the site. >>> >> >> >>> >> >> In JMeter, I could use a ramdom controller with 250 samplers (one for >>> >> >> each URL) under it, and loop through ten times, but the 250 samplers >>> >> >> seems too unwieldy. Better, I could have six samplers, and (I think) >>> >> >> use the StringFromFile function to grab a URL on each occurrence - >>> >> >> however, StringFromFile reads lines from a file sequentially. >>> >> >> >>> >> >> Is there a relatively efficient way to perform the URL ramdomization >>> >> >> I'd like, without having huge numbers of samplers or multiple data >>> >> >> files? >>> >> >> >>> >> >> Thank you for any suggestions! >>> >> >> >>> >> >> --------------------------------------------------------------------- >>> >> >> To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org >>> >> >> For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org >>> >> >> >>> >> >> >>> >> > >>> >> >>> >> --------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org >>> >> For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org >>> >> >>> >> >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org >>> For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org >>> >>> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org