Re: Monitor Performance Graph analysis
sorry for the delay responding. the tomcat monitor basically looks at the JVM stats exposed by Tomcat manager webapp. It's not meant to used for profiling, just a quick health check. Here's the explanation of how it calculates the health http://jmeter.apache.org/usermanual/build-monitor-test-plan.html health uses the following calculation. I should state it's a rough estimate of health, to get a true measurement requires detailed metrics at the request level. load = ( (busythreads/max threads) x 50) + ( (used memory/max memory) x 50) On Fri, Feb 21, 2014 at 1:40 PM, Patricia Dousseau pdouss...@gmail.comwrote: Hi, Peter, Thank you for your reply. :) I'm using Tomcat 7, but it seems it's really getting data from tomcat. My server doesn't look dead, but I really don't understand why thread and health lines don't change. I'd like to understand better how to analyse this graph, I've searched on internet and I didn't find anything about it. I've found an example where the graph looks like mine: http://www.tutorialspoint.com/jmeter/pdf/jmeter_monitor_test_plan.pdf (the last graph in the last page). Thank you, Patricia 2014-02-21 12:53 GMT-03:00 Peter Lin wool...@gmail.com: the monitor performance is meant to talk to tomcat's JMX and get the basic stats it publishes. if the server looks dead, double check that it is actually getting data from tomcat. I wrote that a long time back and it worked with tomcat 5 and 6. I don't know if it still works with newer releases of tomcat. On Fri, Feb 21, 2014 at 10:47 AM, Patricia Dousseau pdouss...@gmail.com wrote: Hello :) I have some doubts concerning the monitor performance graph. I've performed some tests, and I come out with a graph like the one attached and I was wondering why my thread line stays always dead and the health line also doesn't change. And what's the meaning of the load line? Nearer to 100% means that it's overloaded? Any help is appreciated, Thank you, Patricia - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
Re: Monitor Performance Graph analysis
the monitor performance is meant to talk to tomcat's JMX and get the basic stats it publishes. if the server looks dead, double check that it is actually getting data from tomcat. I wrote that a long time back and it worked with tomcat 5 and 6. I don't know if it still works with newer releases of tomcat. On Fri, Feb 21, 2014 at 10:47 AM, Patricia Dousseau pdouss...@gmail.comwrote: Hello :) I have some doubts concerning the monitor performance graph. I've performed some tests, and I come out with a graph like the one attached and I was wondering why my thread line stays always dead and the health line also doesn't change. And what's the meaning of the load line? Nearer to 100% means that it's overloaded? Any help is appreciated, Thank you, Patricia - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
Re: SOAP 1.2
the old SOAP sampler uses Apache Axis 1, so that is correct. newer soap doesn't work well with apache axis. By today's standard, apache axis 1 sucks big time. When I wrote the sampler, axis was considered decent, but that's a long time ago. On Fri, Oct 5, 2012 at 4:14 PM, Rodrigo Ramos crackdu...@gmail.com wrote: Hi folks, Yesterday I tried test a web service with SOAP 1.2, but I could not. I found information about certain incompatibility between Jmeter 2.5 and SOAP 1.2. Is accurate? Greetings - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
Re: Performance OpenJDK compared with SunJDK
Here's a bit of info on difference between linux and windows with regard to JVM that might explain the performance difference. Getting currentTimeMillis and nano time has a higher overhead on linux versus windows. For things like stress testing and benchmark tools like JMeter, getting time is a significant part of the application. From first hand experience, it can be as little as 2% or as high as 10% depending on how often your code gets time from the system. The bigger difference is CPU usage. I have seen linux take considerably more CPU resources when I run benchmarks on apps using unit tests, jmeter or other stress testing tools that frequently get time. On Wed, Dec 14, 2011 at 7:41 AM, Deepak Goel deic...@gmail.com wrote: Hey Looking at your configuration, here is a possible theory... Sun Microsystem (Sun JDK) was eaten by Oracle which runs on WINTEL platforms so the performance of SUN JDK is optimized on INTEL platforms. OpenJDK is meant for Linux platforms a late entry for INTEL into this game and hence low performance and high CPU peaks... Deepak On 12/14/11, Toni Menendez Lopez tonime...@gmail.com wrote: My loadserver is running in this server, Hardware : Proliant BL460C G1 2xIntel Xeon @2,53Ghz (quad) 32 GB of memory O.S : RHEL5.4(Tikanga) I don´t have stats about that but I will collect in few days that I will have again the server available, but my impression is that JMeter is taking much more CPU with OpenJDK and is doing lots of big peaks, seems problems with GC. But I will analyze it later, when my actual testing finished. Toni. 2011/12/13, Deepak Goel deic...@gmail.com: Hey Looks like an evolution and quality problem..Sun JDK more evolved v/s OpenJDK What is the hardware? What is the performance difference? Stats please... Deepak On 12/13/11, Toni Menendez Lopez tonime...@gmail.com wrote: Hello all, I want to ask all of you on question ! I am normally working with SunJDK for Jmeter and running in non-gui mode, but now I want to migrate the openJDK ( OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode)). I have executed the same test in SunJDK and OpenJDK and I have experienced that Jmeter has worst performance sending the traffic with OPenJDK that with SunJDK. Any of you have got some similar experience ? My O.S is RHEL5.4 Best regards, Toni. - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org -- Namaskara~Nalama~Guten Tag~Bonjour -- Keigu Deepak +91-9765089593 deic...@gmail.com 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: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org -- Namaskara~Nalama~Guten Tag~Bonjour -- Keigu Deepak +91-9765089593 deic...@gmail.com 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: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
Re: Performance OpenJDK compared with SunJDK
Great discussion by the way. Before I talked to henrik, I had no clue how complex timers are in the JVM. It was too much info to fit in my brain and got GC-ed. I can only imagine what Azul is seeing with their hardware. On Wed, Dec 14, 2011 at 10:33 AM, Kirk kirk.pepperd...@gmail.com wrote: Well, I'm not sure why he's seeing a difference in performance. I've not spoken to Henrik about timers so I can't comment on what he's telling you. I can only say that there is currently an open CR w.r.t monotonic timers and there is some discussion on the subject in the CR. I've also spoken to Cliff Click about Azul timers and to point to the confusion here.. he was certain that the JDK was using the TSC, something that I was told by Charlie Hunt wasn't the case. So I went digging to find out which of these two was right. Turns out the answer is pretty complicated as it really depends on the OS and what the hardware has. RedHat was the last to touch the OpenJDK timer code and they did so only in the Linux build and only to have the high res timer used if it was available. Not a very clear picture.. and all of these timers come with their own set of faults.. which could be worked around if only we knew which one was being used ;-) And to add to the confusion is thread scheduler efficiency which comes into play and I'm very suspicious of hypervisor interference with thread scheduling.Azul has found some very very weird (almost harmonic) interference patterns that can adversely affect the ability to utilize cores. Without access to proper counters it's almost impossible to say for sure whats going on. Regards, Kirk On Dec 14, 2011, at 4:09 PM, Peter Lin wrote: thanks kirk for digging up those details. My memory is faulty, but that is basically what henrik told me back in 2006/2007. I had noticed a difference between System.currentTimeMillis and System.nanoTime on all JVM (sun, jrockit, ibm). Digging deeper, henrik explained to me that windows uses the high performance timer, which is considerably faster than linux timer. I agree that more threads results in more pressure on the thread scheduler. what got me curious is the user sees a difference between openJDK and sunJDK. perhaps there is some other process running on that linux system contributing to the extra CPU load. On Wed, Dec 14, 2011 at 10:00 AM, Kirk kirk.pepperd...@gmail.com wrote: Unfortunately it turns out that nanoTime drifts quite badly relative to currentTimeMillis, so currentTimeMillis has to be used to anchor that drift. Otherwise the times just don't add up properly. The JMeter property sampleresult.useNanoTime can be set to false to disable the use of nanoTime. Right, if nanoTime in Windows uses a TSC I would expect drift especially on newer processors. Not all cores receive all clocks and since the value in the TSC * CPu frequency is the current time, not having an accurate count of clocks would cause drift. currentTimeMillis relying on a RTC would have smaller amounts of drift which would only be noticed between machines (which would be correct with NTP). So your correction of drift would be consistent with this. On Solaris, the drift between the TOD clock and the TSC is correct after a 1ms drift 125us at a time. I think MS has attempted something similar (due to complaints from gamers) but I'm not aware of the details. Regards, Kirk - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
