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 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 :) 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] > >
