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=2 acceptCount=100 redirectPort=8443
enableLookups=false minSpareThreads=25 maxThreads=512
maxHttpHeaderSize=8192/
