Hey Looks like it is reading the access log multiple times as it has enough time for the test..
197k +197k+ 25k = 418k Rotations completed by Jmeter is around 2.1 times... :) Deepak On 5/17/12, James Musselwhite <[email protected]> wrote: > I'm deleting the results file after every run. They are always fresh. > > On Thu, May 17, 2012 at 4:26 AM, sebb <[email protected]> wrote: > >> 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] >> >> > -- 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 Facebook: http://www.facebook.com/deicool "Contribute to the world, environment and more : http://www.gridrepublic.org " --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
