You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by PerfGuru <my...@yahoo.com.INVALID> on 2015/04/07 18:54:35 UTC
Performance question...
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"/>
Re: Performance question...
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Tony,
On 4/7/15 12:54 PM, PerfGuru 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.
What is the stack trace for TaskQuery.take()? I've never heard of
"TaskQuery"; is that some component you wrote yourselves?
> We are using some version of 7.x for tomcat and also for the jdk.
Specific versions, please.
> 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.
>
> <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"/>
You are using the default protocol ("HTTP/1.1") which will auto-select
the implementation based upon whether APR/native is available or not.
Can you tell us which connector is actually being used?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVJXn7AAoJEBzwKT+lPKRYZGIP/ibwVWj8LzprNBdcxVeHl64V
2U/4LClsA+SRdzxNomd18WLfavVKas9DVZHAVEDH7RIJguSi68QxH9Sv39usMSU8
MrVYvR76DD4vOR7rQNpqXcplfp+NP3bVgPWiOW3F9UqFBHTZiUmD8A6/4VvdXxPa
qRDMeQ8HXDWUbmG423dolachHHCwCAX8JLaIped3twuE+TKmvVbbRCLWvGgFA10q
UNLamqbZ8Z6i6NOPrDY709hSp6Cc06fBpIUldiu5gGIQHTPISmXRVeXEofbJ5wBL
T21N6HdU5RZetPaNtNUSOQbV1awR7l89LZBfFI/OAWHyIeVSqojogE9MvoieaJ9N
Urg1EqLp9FeqLbS3YiwiV7aZyIMCKaRlY4lwsNoqNOklk7RKqmwr9VKYgbtHsH7x
Gjx5ed5G7fVFwKH1x+Ny0d8Jsl2pzgqzoKjE8LG712maGG9DU2dcZuIF+ZDBsOvz
wUcQvmFlnpV8yG8uaYgoWSGiQL2XlFLOJfnh9xrRQvFVu+1Ya/MLMpjtuImDb55v
85w6TvWkcn4jgqoejufCb/GhG/20k8Xew7UdmIttyoFb4/vKEsGRWs94s7hAae3s
vBcdjDshf35CRHTIlna5QhKH8d6jXyYqP8BDyBxeB0F4Sh0Rwiz/B9vkIARX2syy
0Usx55k35IC09422/Wap
=Dm02
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Performance question...
Posted by PerfGuru <my...@yahoo.com.INVALID>.
Here is the bug reference I found:https://jira.spring.io/i#browse/SPR-11335
Regards,-Tony
From: "Balana, Vishal" <Vi...@fmr.com>
To: Tomcat Users List <us...@tomcat.apache.org>; PerfGuru <my...@yahoo.com>; Jeffrey Janner <Je...@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:myuniportal@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 <Je...@PolyDyne.com>
To: 'Tomcat Users List' <us...@tomcat.apache.org>; 'PerfGuru' <my...@yahoo.com>
Sent: Friday, April 10, 2015 1:03 PM
Subject: RE: Performance question...
> -----Original Message-----
> From: PerfGuru [mailto:myuniportal@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 <li...@viskan.se>
> To: PerfGuru <my...@yahoo.com>; users <us...@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" <my...@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"/>
> >
> >
>
>
>
RE: Performance question...
Posted by "Balana, Vishal" <Vi...@fmr.com.INVALID>.
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:myuniportal@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 <Je...@PolyDyne.com>
To: 'Tomcat Users List' <us...@tomcat.apache.org>; 'PerfGuru' <my...@yahoo.com>
Sent: Friday, April 10, 2015 1:03 PM
Subject: RE: Performance question...
> -----Original Message-----
> From: PerfGuru [mailto:myuniportal@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 <li...@viskan.se>
> To: PerfGuru <my...@yahoo.com>; users <us...@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" <my...@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"/>
> >
> >
>
>
>
Re: Performance question...
Posted by PerfGuru <my...@yahoo.com.INVALID>.
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 <Je...@PolyDyne.com>
To: 'Tomcat Users List' <us...@tomcat.apache.org>; 'PerfGuru' <my...@yahoo.com>
Sent: Friday, April 10, 2015 1:03 PM
Subject: RE: Performance question...
> -----Original Message-----
> From: PerfGuru [mailto:myuniportal@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 <li...@viskan.se>
> To: PerfGuru <my...@yahoo.com>; users <us...@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" <my...@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"/>
> >
> >
>
>
>
RE: Performance question...
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----Original Message-----
> From: PerfGuru [mailto:myuniportal@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 <li...@viskan.se>
> To: PerfGuru <my...@yahoo.com>; users <us...@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" <my...@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"/>
> >
> >
>
>
>
Re: Performance question...
Posted by PerfGuru <my...@yahoo.com.INVALID>.
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
From: Linus Brimstedt <li...@viskan.se>
To: PerfGuru <my...@yahoo.com>; users <us...@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" <my...@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"/>
>
>
Re: Performance question...
Posted by Linus Brimstedt <li...@viskan.se>.
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" <my...@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"/>
>
>