RE: Speeding up tomcat
To follow up with my request for help. we made 3 adjustments. added in org.apache.jasper.servlet.JspServlet checkInterval 300 development false server.xml context.xml added Response times on the website went from average of 3seconds per click to average of 1.5seconds per click to complete the page load. -Original Message- From: Christopher Schultz Sent: Monday, March 25, 2024 6:37 PM To: users@tomcat.apache.org Subject: Re: Speeding up tomcat [You don't often get email from ch...@christopherschultz.net. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] [EXTERNAL] Alex, On 3/25/24 13:06, Alex Hatcher wrote: > Java version: 11.0.20 > Tomcat version: 9.0.59 Are you able to upgrade these? Your Tomcat is nearly 2 years old and your Java is ... I'm not sure how old. This will have nothing to do with performance. Just security and general stability. > 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. Ouch. > 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. Are you able to see the duration of that 55000 class file read? How have you observed that Tomcat is reading all those files? Once an application is started and humming-along, Tomcat shouldn't be reading too many class files at all. Reasons I can think of for reading lots of class files: 1. Auto-reload is enabled, and your class files have timestamps in the future. This would basically restart your application completely every few seconds. I think you'd notice. 2. You have disabled caching of your and, for some reason, you are constantly searching through them for something. 3. You have an application-level scan for classes which is not using Tomcat's (usually cached) loader to locate classes. In this case, I would say that your application should (a) be loading though Tomcat and (b) probably not scanning classes all the time :) > 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. Well, if your application is triggering a 55000-file scan with every request, that's obviously the place to start. That simply should not be happening. Even a fast VM, OS, web server, etc. wasting that much time won't be "fast". So start there. If you are able to observe the files being read, you can probably arrange to have one of them refuse to be read which should produce a FileNotFoundException or similar in a log. Then you can see what component is actually triggering that file-read and try to find out what it's being read with every request. I would make the vendor do this. It's what you pay them for. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: org.apache.catalina.valves.RemoteAddrValve
Thanks Christopher! Sent from my iPhone > On Apr 4, 2024, at 10:20 PM, Christopher Schultz > wrote: > > Eric, > >> On 4/4/24 13:43, Eric Fetzer wrote: >> Hi All, >> When I originally set up my tomcat instance, I added the following to allow >> manager access under /opt/tomcat/webapps/manager/META-INF/context.xml: >> > allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|1.3.5.*" /> >> That worked wonderfully. Now I'm trying to add another IP range by >> changing it to: >> > allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|1.3.5.*|2.4.6.*" /> >> This is not working. I tried to use 2\.4\.6\.\d+ as well but that didn't >> work either. I've verified I can get to port 8080 from the IP locations. >> Any idea what I'm doing wrong or do you have a means to troubleshoot this? > > I'm glad you are reporting that the issue is elsewhere and not a problem with > your use of RemoteAddrValve. > > But I'd like to point out that since these are regular expressions, your > specific use of them can lead to unintended consequences. For example: > > 1.3.5.* > > This will allow anyone from 1.3.5.1 or 1.3.5.99 or 1.3.5.254. That's probably > fine. But it will also allow anybody from 103.50.99.24 as well. That probably > wasn't intended. > > Changing it to the properly-escaped 1\.3\.5 but also trailing \..* (note > there are two periods there) really means 1.3.5.whatever. > > Using \d isn't strictly necessary but it does make it clear that you aren't > expecting non-digits e.g. hostnames. > > As you mentioned elsewhere in this thread, you thought it was "tomcat > language". When it comes to security controls, /please read the > documentation/ because knowing that it is a regular expression and not a > "tomcat language" can mean the difference between configuring a security > control properly or improperly. > > -chris > > - > 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
RE: Migrating from Tomcat 9.0.x to 10.1.x
Thank you, Chris, for the feedback.
The changes are needed in the Spring WebSocket library to ensure Tomcat 10.1
compatibility.
https://github.com/spring-projects/spring-framework/pull/29434
As I understand, this means I should be updating the Spring libraries used in
the applications to be deployed with Tomcat 10.1.
I was exploring the possibility of performing Tomcat 10 upgrade independent of
the upgrades of TPIPs used the application (mainly Spring 5 to 6). And using
migration tool seemed a very promising approach.
Now looking at issue like this, seems like it's ideal to have both Tomcat
upgrade and the application TPIPs upgrade go together.
Thanks,
Amit
-Original Message-
From: Christopher Schultz
Sent: Thursday, April 4, 2024 9:37 PM
To: users@tomcat.apache.org
Subject: Re: Migrating from Tomcat 9.0.x to 10.1.x
CAUTION: This email originated from outside the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe. If you believe this is a phishing email, use the Report to
Cybersecurity icon in Outlook.
Amit,
On 4/4/24 22:21, Amit Pande wrote:
> I am in the process of migrating from Tomcat 9 (9.0.87) to Tomcat 10.1
> (10.1.20).
>
> https://tomcat.apache.org/migration-10.1.html Using the migration tool, I
> have migrated the applications (which use Spring libraries 5.x).
>
> While testing the migrated apps( which use web socket), ran into:
>
>
> org.springframework.web.util.NestedServletException: Handler dispatch
> failed; nested exception is java.lang.NoSuchMethodError: 'void
> org.apache.tomcat.websocket.server.WsServerContainer.doUpgrade(jakarta
> .servlet.http.HttpServletRequest,
> jakarta.servlet.http.HttpServletResponse,
> jakarta.websocket.server.ServerEndpointConfig, java.util.Map)
>
>
> https://gith/
> ub.com%2Fapache%2Ftomcat%2Fblob%2F9.0.x%2Fjava%2Forg%2Fapache%2Ftomcat
> %2Fwebsocket%2Fserver%2FWsServerContainer.java=05%7C02%7CAmit.Pan
> de%40veritas.com%7C2650bfb140d94911624408dc55195c23%7Cfc8e13c0422c4c55
> b3eaca318e6cac32%7C0%7C0%7C638478814607427868%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0
> %7C%7C%7C=w69RggozFPZcifxDJOHnII9jtZJJ29qZQSkDNNFYTzE%3D
> d=0
>
> * @deprecated This method will be removed in Apache Tomcat 10.1 onwards.
> It has been replaced by
> * {@link #upgradeHttpToWebSocket(Object, Object,
> ServerEndpointConfig, Map)}
> */
> @Deprecated
> public void doUpgrade(HttpServletRequest request, HttpServletResponse
> response, ServerEndpointConfig sec,
> Map pathParams) throws ServletException,
> IOException {
> UpgradeUtil.doUpgrade(this, request, response, sec, pathParams);
> }
>
> Is this an issue with the migration tool to appropriately replace the removed
> methods?
>
> Or the applications using web sockets with Tomcat 9.x are required to be
> updated before moving to Tomcat 10.1, instead of using the migration tool as
> an intermediate step to upgrade to Tomcat 10.1 without having to update the
> applications at the same time?
> FWIW, Spring 5 to Spring 6 is a major upgrade and Tomcat 10 is a requirement.
The Migration Tool doesn't rewrite your code, it only rewrites the class names
referenced by your class files. (Okay, it also re-writes strings in your files
which match those class names as well.) But it will not change method calls. It
is not a Deprecation Cleanup Tool.
You should change your Java EE-compatible application to use
upgradeHttpToWebSocket(Object, Object, ServerEndpointConfig, Map) first, then
run the Migration Tool on your application.
-chris
-
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
R: PKCS#8 encryption algorithm unrecognized
> I got the Object ID and version straight out of the Certificate using > Keystore Explorer. I'm not sure why there is a difference. Keystore Explorer uses Bouncy Castle (https://www.bouncycastle.org/) as provider for JCE. If your JRE/JDK does not provide some algorithm you could use Bouncy Castle as well. Regards, Roberto - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
