Alex

> -----Original Message-----
> From: Alex Hatcher <ahatc...@peacsolutions.com>
> Sent: Monday, March 25, 2024 12:06 PM
> To: users@tomcat.apache.org
> Subject: Speeding up tomcat
> 
> 
> 
> Java version: 11.0.20
> 
> Tomcat version: 9.0.59
> 
> 
> OS Version: Windows Server 2022 Datacenter Azure Edition
> 
> Azure VM Type and Specs: D8s v3
> 
> 8 CPU 32 GiB Mem
> 
> VM Generation                 V2
> 
> VM Architecture               x64
> 
> Location                               East US Zone 1
> 
> 
> 
> We have a traditional client/server application from a third-party vendor that
> has a couple second delay when accessing certain items (tabs) in their Web UI.
> The delay has been traced down to the webserver, which runs Tomcat.  The
> application and database servers do not appear to have any significant delays.
> 
> 
> 
> When an item is clicked inside the web UI, a call from the web server is made
> to the app and DB server, which come back fairly quickly.  It's at the point
> where data is delivered from the app server to the web server that tomcat on
> the webserver CPU usage spikes.  In reviewing the web server with procmon
> running, we noticed that tomcat is reading a lot of class files during the 
> time
> we are waiting for the task to complete to render the page.   Approximately
> 55,000 (yes 55000) classes read each click.
> 
> 
> 
> The vendor has reviewed this and said it's nothing to worry about, but we
> cannot find any other significant task that tomcat is doing during this wait
> state that a web client experiences.
> 
> 
> 
> We have sql tracing showing microsecond response times.
> 
> 
> 
> Developer console in chrome shows it waiting for 1.9 (Avg) seconds per click.
> 
> 
> 
> We would like to get to the root cause of this slowness, whether it is the
> operating system, Azure VM, webserver or vendor application causing the
> issue.
> 
> 
> 
> 
> 
> 
> Notice: This e-mail message is confidential and is intended only for the use 
> of
> the individual and/or entity identified in the address line of this message. 
> If
> you have received this message in error, or are not the named recipient(s),
> please notify us immediately by telephone (888-479-9111) M_LEGAL_NOTICE

For this level of detail, I would use a profiler like the java flight recorder, 
JProfiler, etc.

Your description of classes being re-read sounds like the code is recreating 
one of the many factory classes that use the java service locator under the 
covers, like DocumentBuilderFactory, etc.  If you can confirm that, I can tell 
you (or the vendor) what to do about it.

Thanks


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to