G'day The first thing I would try would be to get an independent measure of the rate at which transactions are being discharged by the DNS server.
The most likely explanation is that either the C program and/or JMeter is not sending transactions at the rate you think they are and/or the transactions are not actually getting discharged by the DNS server. (This is only the most likely explanation, but by no means the only one.) For instance (and I doubt you are doing this) but in a distributed JMeter test if you have a test plan of 100 threads and 6 JMeter servers running you will get 6 x 100 concurrent threads all up. Ideally you should get stats from the DNS server about the number of queries processed during each of a C run and a JMeter run. (Note that doing these run back to back is potentially misleading as the DNS server may cache look up results from the first run and use them in the second run. ) I would also make sure that if you have a think time in the C program that this has been implemented in the JMeter test plan too. Ian Blavins Contract Performance Engineer Temenos -----Original Message----- From: sebb [mailto:[EMAIL PROTECTED] Sent: 22 May 2007 12:49 To: JMeter Users List Subject: Re: JMeter performance testing - heavy CPU utilization There could perhaps be a problem... What throughput did you get? What was the average sampler response time? Are you using any functions or variables? Which version of Java, and which OS? S. On 22/05/07, Stefano Gambetta <[EMAIL PROTECTED]> wrote: > Hello, > I'm evaluating JMeter as a load testing framework for my performance > analysis. > > I'm going to load test a DNS server. To do so, I've written my own Java > Request sampler, which issues DNS requests using the package dnsjava. > > My test configuration is very simple: one thread-group (one therad > configured for example), one java request sampler, one simple data writer as > listener. > > The problem basically is that with that configuration JMeter can reach a > very low throughput (query sent / sec), since during tests CPU get > saturated. > > The known bind queryperf tool can generate a load about six times higher > while using less than 30 % CPU. Since this tool is a simple C program, I > expected a greater performance, but that results seems to be exaggerated. > > I assumed that my sampler class was not well optimized, so I did a quick > profiling of JMeter, during the test, in order to discover some areas of > improvement. > > I think I saw an interesting result: most of the thread sampler time is > spent in one method of one particular class of JMeter, and a minor part is > spent inside the Java Request sampler. The mentioned method is: > > SamplePackage.setRunningVersion() > > > Giving that results, I have some questions: > > - what does that method do? > - is it possible to reduce its overhead? > > Thanks for any replies > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This email (and any attachments) contains confidential information, and is intended only for the named recipient. Distribution or copying of this email by anyone other than the named recipient is prohibited. If you are not the named or intended recipient, please notify TEMENOS or the sender immediately and permanently destroy this email (and any attachments) and all copies of it. No member of TEMENOS Group AG or any of its associated or affiliated companies is liable for any errors or omissions in the content or transmission of this email. Any opinions contained in this email are solely those of the author and, unless clearly indicated otherwise in writing, are not endorsed by any member of TEMENOS Group AG or any of its associated and affiliated companies. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
