On 17 May 2012 01:43, James Musselwhite <[email protected]> wrote: > Let me give a concrete example of the problem I'm having. > > My thread group has only one sampler, and it is an Access Log Sampler. It > reads tomcat access logs. Every line in that log is a GET. It simply reads > those GETS and pipes them at a target server. My access log has 197K > entries. > > I used the Throughput Shaping Timer set at 22 RPS for 6 hours. I can
The Throughput Shaping Timer is not a standard JMeter test element. If it is causing problems, you will need to take that up with the provider using their support channel. > manually count in my results file my looking at the timestamps that jMeter > is delivering around 18-23 RPS, which is fine. > > So, given that RPS and the given time (21600 seconds), you would expect > that I would get anywhere from 388K-496K requests from jMeter. > > However, that is simply not the case. If I look at the last line in my > results log, line 418,166, it shows up at line 22902 in my access log. This > leads to many questions: > > 1. Why did I even get 418K lines in my results. I should have gotten 197K > results because there are only 197K lines in the access log. > 2. Why is the line at 22902 showing up at 418K, at the end of the log? All > of the lines towards the end of the results are showing up at the ~23K mark > which leads me to believe that is how far through the log it got. > > I'm at a loss for ideas. Please help :) Remember that JMeter appends results to the sample result file ... > > > On Wed, May 16, 2012 at 3:53 AM, Sergio Boso <[email protected]>wrote: > >> Hi, >> I'm not sure about your configuration, particularly about the log file >> that was read once.. >> It would be nice to have some more details about that. >> >> However, you should be aware that, if your system system under test cannot >> bear 15 TPS, the whole test will be slower thus returning less transaction >> in 6 hours. >> So, in this case, the Constant Throughput Timer, cannot make your system >> faster. >> >> You can check if this is the case, just by lowering the load (e.g to 5 >> tps) and adjust your math: you should discover that the numbers are ok. >> regards >> >> >> >> Il 15/05/2012 14:59, Deepak Goel ha scritto: >> >> Hey >>> >>> Is there a possibility that: >>> >>> Each transaction of yours in the access log contains more hits to the >>> server. >>> i.e: HTML page has gifs too.. >>> >>> :) >>> Deepak >>> >>> On 5/15/12, James >>> Musselwhite<james.musselwhite@**gmail.com<[email protected]>> >>> wrote: >>> >>>> When I say "was read once", I was assuming that the Access Log Sampler >>>> will >>>> only parse the access log one time, even if the throughput shaper has >>>> more >>>> requests than is available in the access log. My access log had 194k >>>> entries, but my shaper was set for 15dps for 6 hours, which is more than >>>> 194k requests. Would it start the log over again or would it just end at >>>> 194k? >>>> >>>> On Mon, May 14, 2012 at 1:25 PM, Deepak Goel<[email protected]> wrote: >>>> >>>> Hey >>>>> >>>>> Some possibilities >>>>> >>>>> 1. Network Issue rejecting connections resulting in errors also being >>>>> registered in the results log >>>>> 2. The hardware machine rejecting connection due to overload >>>>> >>>>> I am unsure what do you mean by : "194K entries because the >>>>> access log was only read once" >>>>> >>>>> :) >>>>> Deepak >>>>> >>>>> On 5/14/12, James >>>>> Musselwhite<james.musselwhite@**gmail.com<[email protected]>> >>>>> wrote: >>>>> >>>>>> Hi folks >>>>>> >>>>>> I've got an access log with 194K requests >>>>>> I ran a test with the throughput shaping timer at 15 RPS for 6 hours, >>>>>> >>>>> which >>>>> >>>>>> should be 324K requests >>>>>> My results log has 235K entries >>>>>> >>>>>> I would expect my results log to have either a.) 194K entries because >>>>>> the >>>>>> access log was only read once or b.) 324K entries because it just kept >>>>>> reading the same log over and over to fulfill the demands of the >>>>>> >>>>> throughput >>>>> >>>>>> shaping timer. >>>>>> >>>>>> However, my result log is 235K which doesn't mean anything to me. Can >>>>>> someone elucidate how this works? >>>>>> >>>>>> Thanks! >>>>>> James >>>>>> >>>>>> >>>>> -- >>>>> Namaskara~Nalama~Guten Tag~Bonjour >>>>> >>>>> >>>>> -- >>>>> Keigu >>>>> >>>>> Deepak >>>>> +91-9765089593 >>>>> [email protected] >>>>> http://www.simtree.net >>>>> >>>>> Skype: thumsupdeicool >>>>> Google talk: deicool >>>>> Blog: >>>>> http://loveandfearless.**wordpress.com<http://loveandfearless.wordpress.com> >>>>> Facebook: >>>>> http://www.facebook.com/**deicool<http://www.facebook.com/deicool> >>>>> >>>>> "Contribute to the world, environment and more : >>>>> http://www.gridrepublic.org >>>>> " >>>>> >>>>> ------------------------------**------------------------------** >>>>> --------- >>>>> To unsubscribe, e-mail: >>>>> user-unsubscribe@jmeter.**apache.org<[email protected]> >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>>> >>> >> >> -- >> >> Ing. Sergio Boso >> >> Mail: >> Web: >> PEC: >> Cell: >> Linkedin: >> Skype: >> >> >> >> [email protected] <mailto:[email protected]> >> www.bosoconsulting.it >> [email protected] <mailto:[email protected]> >> +39 335 7243 445 >> http://it.linkedin.com/in/**sergioboso<http://it.linkedin.com/in/sergioboso>< >> http://www.linkedin.com/pub/**sergio-boso/1/29b/255<http://www.linkedin.com/pub/sergio-boso/1/29b/255> >> > >> sbos61 >> >> In caso di erronea ricezione da parte di persona diversa, siete pregati di >> eliminare il messaggio e i suoi allegati in modo definitivo dai vostri >> archivi e di volercelo comunicare immediatamente restituendoci il messaggio >> via e-mail al seguente >> indirizzosergio@**bosoconsulting.it<[email protected]><mailto: >> [email protected]> >> L’interessato può, inoltre, esercitare tutti i diritti di accesso sui >> propri dati previsti dal decreto 196/2003, tra i quali i diritti di >> rettifica, aggiornamento e cancellazione, inviando un messaggio all’ >> indirizzo:sergio@**bosoconsulting.it<indirizzo%[email protected]><mailto: >> [email protected]> >> >> >> >> >> >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> user-unsubscribe@jmeter.**apache.org<[email protected]> >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
