Here is the bug reference I found:https://jira.spring.io/i#browse/SPR-11335 Regards,-Tony From: "Balana, Vishal" <vishal.bal...@fmr.com> To: Tomcat Users List <users@tomcat.apache.org>; PerfGuru <myunipor...@yahoo.com>; Jeffrey Janner <jeffrey.jan...@polydyne.com> Sent: Tuesday, April 14, 2015 8:19 AM Subject: RE: Performance question... Could you please share the reference/link to spring framework fix as only code cache increase didn't help?
Regards, Vishal -----Original Message----- From: PerfGuru [mailto:myunipor...@yahoo.com.INVALID] Sent: Monday, April 13, 2015 5:23 PM To: Jeffrey Janner; 'Tomcat Users List' Subject: Re: Performance question... Sorry Jeff my Tocat emails are bouncing from the email address use so using another one that works. Last Friday the development team tried the spring framework fix sugested and it fixed the problem of higher than normal cpu and performance. We did try the other idea of increasing the code cache but as expected it did not make a difference. Again thanks for all the suggestions.-Tony From: Jeffrey Janner <jeffrey.jan...@polydyne.com> To: 'Tomcat Users List' <users@tomcat.apache.org>; 'PerfGuru' <myunipor...@yahoo.com> Sent: Friday, April 10, 2015 1:03 PM Subject: RE: Performance question... > -----Original Message----- > From: PerfGuru [mailto:myunipor...@yahoo.com.INVALID] > Sent: Thursday, April 09, 2015 10:17 AM > To: Tomcat Users List > Subject: Re: Performance question... > > Looks like we have two potential root causes. 1. Spring Framework 4.0.0 > and jdk 1.7.0_51 are used which might be one of the root causes > according to a Spring Framework bug.. The fix is to upgrade the Spring > Framework version.2. The codecache is too small in 1.7.0_51 and leads to > performance/cpu utilization issues. The fix is to try increasing to 4x > the default size, setup printing out codecashe size when app server > stopped. Also in 1.7.0_80 this was fixed and in 1.8 the default > codecache size was increased by 4x. Regards,-Tony [Jeffrey Janner] Tony, Last public update of Java is 1.7.0_75/76. Are you sure that _80 is the one we want? Also, do you know if updating the Java would help with the Spring bug? Can you send me a link to the bug? Thanks, Jeff > From: Linus Brimstedt <linus.brimst...@viskan.se> > To: PerfGuru <myunipor...@yahoo.com>; users <users@tomcat.apache.org> > Sent: Tuesday, April 7, 2015 5:55 PM > Subject: Re: Performance question... > > Hello > Try to do a java thread dump and check the stuck threads (possibly by > comparing with the output of the tomcat server status page). Hopefully > this > will give you a clue about what the threads are doing at that time. > If the application uses a database, you may see that they are stuck > waiting > for the dB reply. It could also be that it's waiting for disk (perhaps > you > have too much logging enabled) etc. > > How do you simulate your users and do you have proper timing between > requests of each users? > If a real user on average take 10 seconds between requests and you have > a > timing of 1 second between requests in your load test, you are > simulating > 10x the load you think.. > > Br > L > > > On 7 Apr 2015 18:56, "PerfGuru" <myunipor...@yahoo.com.invalid> wrote: > > > Hi All,We are noticing when running a simple load test of 25 virtual > users > > that our Tomcat server is running at 40% CPU and transactions are > taking > > over 40 seconds. We setup a test where we focused (in a loop) one of > the > > longer response time requests. The access logs show the log response > time > > and the developers have monitoring via their own logs where they > record > > response times for queries and other things but do not show the > response > > times as being nearly as long as the access logs indicate.We connected > up > > visualvm 1.3.7 remotely and using the sampler the only method response > time > > above 2 seconds on average was the TaskQuery.take() which was over 100 > > seconds for some reason.We are using some version of 7.x for tomcat > and > > also for the jdk. The tomcat config file is shown below. We are in the > > process of setting up visualvm on the unix server where Tomcat is > running > > so we can use local mode for visualvm instead of remote. > > Any ideas/thoughts appreciated.-Tony > > > > > > <Connector port="25500" secure="true" > > compressableMimeType="text/html,text/xml" > noCompressionUserAgents="gozilla, > > traviata" compression="on" disableUploadTimeout="true" > > connectionTimeout="20000" acceptCount="100" redirectPort="8443" > > enableLookups="false" minSpareThreads="25" maxThreads="512" > > maxHttpHeaderSize="8192"/> > > > > > > >