nodje wrote: > thanks again Brian. > > one last question about monitoring, have you bean able to use Hyperic HQ on > your production environment without significant performance reduction? > > We have identified Glassbox and LambdaProbe as potentially good tools but > never dared to put them on the production server.
I have run LambdaProbe on production without issue in the past but I doubt it (or jconsole) is going to help you very much. The quickest way to track down a performance bottleneck, assuming your application logging isn't giving you enough data, is to use a profiler. A good profiler, like YourKit (I use it because they give free copies to Tomcat developers) will tell you how much time is spent in what code. It will place a little more load on the server but a little more load for 5 minutes to tell you where the real problem is will be worth it. Other techniques (access logs, jmeter, etc) should point you in the right direction but you'll need to do soem more work to figure out exactly where the bottleneck(s) is(are). Mark > > -nodje > > > Brian Clark-10 wrote: >> Glad to be of help. >> >> First, I don't think that APR has anything to do with thread management. I >> think the two things it does really well is to serve up static content and >> provide native SSL processing. Tomcat 6 and/or Java 6 may help with though >> (I would assume so, but I don't know for sure). >> >> Second, Tomcat 6 and Java 6 will provide performance >> enhancements--particularly from the newer hotspot compiler in Java 6. If >> using on 32-bit Windows, be sure to select the "server" version of the >> JVM, and not the "client" JVM. By default, Tomcat will select the client >> version on 32-bit Windows. On 64-bit Windows, there is only one version >> available, the server version. >> >> Also, as your original question started off with asking about the NIO >> protocol, according to the benchmarking done by the authors of the >> O'Reilly Tomcat book, the JIO connector is sometimes faster than the >> NIO connector. I recommend getting this book and reviewing the sections >> on performance tuning. >> >> Finally, I suggest using a tool to monitor your JVM and applications over >> a period of time. We use the free Hyperic HQ monitoring tool. It uses JMX >> to remotely monitor Java 6/Tomcat 6, and I have found it to be very >> valuable. There is a free and a commercial version. WE use the free >> version and it works great. Check it out at http://www.hyperic.com We use >> this tool to monitor heap usage and thread usage over time, so that we can >> tell if we are hitting our upper limits on either of these constraints. >> >> Brian >> >> >> >> >> ________________________________ >> From: nodje <nodje...@gmail.com> >> To: users@tomcat.apache.org >> Sent: Monday, December 29, 2008 9:10:05 PM >> Subject: Re: Optimizing Tomcat with Http11NioProtocol? >> >> >> Hi, thanks all for your answers. >> >> I have jconsole in place. I can monitor Tomcat and general JVM >> information. >> The think is it's not easy to understand statistics. >> >> - How much I am using of Xmx is definitely something I want to know >> - how many thread are used in peak times is also something I need to know: >> if it reaches 150, the max, how much further can I push it? Would >> Http11NioProtocol help for this matter? >> - How can I detect if it's the application that takes time to process >> request or Tomcat that is at its max capacity? Number of threads and Heap >> memory usages are probably two good indicators right? >> >> More generally avout Http11NioProtocol, can it be less efficient than the >> std connector? Or is it suppose to be the next generation good-for-all >> connector? >> >> We are going to update to Tomcat 6 +APR anyways. Is the APR good only for >> static content? I thought it would help the thread management anyways. >> >> Thanks Brian for confirming memory usage! That's very good to know it's >> possible to use that much memory! >> >> cheers >> >> >> Brian Clark-10 wrote: >>> Try using jconsole.exe (it is part of the Sun JDK) to review memory and >>> thread usage of your JVM. That should help you narrow down where the >>> issue >>> is. One key thing to look at with Jconsole is the heap memory used >>> figure. >>> You are setting your -Xmx, but how much of it are you actually using? >>> Heap >>> memory used will tell you if you have a memory constraint or not. Also >>> look at how often you have garbage collections. You'll have more of them >>> if you have a memory constraint. One more thing, be sure your min and max >>> memory configurations are the same. It's more efficient that way. >>> >>> On 32-bit Windows, you should be able to use 1536MB as your -Xmx size. >>> That is what we are able to use, at least using JDK 1.6.x. Upgrading to >>> 64-bit Windows and a 64-bit JVM (and 64-bit Tomcat) will allow you to use >>> as much RAM as you have available. We have a 64-bit Windows system with >>> 18 >>> GB of RAM allocated to Tomcat/Java. >>> >>> >>> Good luck, >>> Brian >>> >>> >>> >>> >>> ________________________________ >>> From: nodje <nodje...@gmail.com> >>> To: users@tomcat.apache.org >>> Sent: Monday, December 29, 2008 2:57:14 AM >>> Subject: Optimizing Tomcat with Http11NioProtocol? >>> >>> >>> Hi, >>> >>> we are still using 5.5.12 in production and our users are facing >>> increasing >>> delays with their requests (like way too long by now already). >>> While we are not entirely sure about what's causing this (database vs >>> Java >>> application), we suppose it comes from the Java application (the database >>> server never seems to be under stress). >>> The CPU of the Tomcat machine doesn't seem too busy either. >>> >>> Providing it comes from the Java application side (by the way, any tips >>> on >>> how to precisely identify that is more than welcome), and providing that >>> the >>> problems come from too many requests, would Http11NioProtocol help Tomcat >>> speed up the execution? >>> It seems worth trying Http11NioProtocol before going for clustering+load >>> balancing. Any advice on the matter? >>> >>> Also we think that request that cannot b served in the reasonable time >>> should be refused. Taking into account the described behaviour with the >>> default maxThreads=150 and acceptCount =100 values, shouldn't we decrease >>> the acceptCount? >>> Moreover the CPU on the Tomcat machine doesn't seem too busy. Is it a >>> sign >>> that we can increase maxThreads? >>> >>> Tomcat is on a Windows 32bits machine, so even though the machine has 4Gb >>> of >>> RAM, the MAX -Xmx size that we can be used seems to be around 1200Mb. >>> Would >>> a 64bits OS automatically allows for more memory usage? >>> >>> A lot of questions I know, but facing big problems like we are now, we >>> want >>> to try anything possible to quickly relieve the pain from using the >>> application! >>> >>> thanks to anyone providing advice >>> -nodje >>> -- >>> View this message in context: >>> http://www.nabble.com/Optimizing-Tomcat-with-Http11NioProtocol--tp21200419p21200419.html >>> Sent from the Tomcat - User mailing list archive at Nabble.com. >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>> >>> >>> >> -- >> View this message in context: >> http://www.nabble.com/Optimizing-Tomcat-with-Http11NioProtocol--tp21200419p21212597.html >> Sent from the Tomcat - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
