I have a java application launched via java web start.
I'm using fiddler to debug some web service calls, but when the calls are running through fiddler, the application runs much slower.
There doesn't seem to be any CPU bottleneck, and the I don't think the messages are huge.
Any idea what could be slowing it down?
thanks,
Mark
Related
My spring boot application becomes slow after 1-2 days when I deploy it on production server. I'm using AWS EC2 instance. In start the speed is fine, but after a couple of days I have to restart my instance to get back the desired performance. Any hint what might be wrong here?
Have you check for memory leakage in application as it is nothing to do with EC2 instance. As you mention it was working fine after restart.
It is not best practice to use embed server on production.
I would suggest you should use AWS Elastic Beanstalk service for deploying spring boot application, there is no additional charge on it.
Okay so after some analysis (Thread dumping of my tomcat server on production) I found out that there were some processes (code-smells) which were taking all of my CPU space, and hence my instance was becoming slow, and effecting the performance of my application overall.
We are creating a test automation framework for web application. For Test scenarios including the Scheduled jobs, we need to advance the time to let the jobs triggered, But this is making the server (TOMCAT) very slow. What could be the reason and solution?
Currently I am working on a Large Scale Application which uses GWT with Hibenate. We are facing some performance issues with existing Jetty / Tomcat server. And we want a another server that handles hibernate queries and GWT both perfectly.
Problem with tomcat is it sometimes stops responding GWT requests, and client hangs up on some points.
There are certain servers that comes in my mind like :
GlassFish
Jboss
IBM WebSphere AS
etc.
Please suggest some high scale server that handles GWT RPC request well and can run in multi-client environment well. We are expecting 100 concurrent users, Hardware is not an issue.
Thanking You,
Regards,
I think that your problem is not related to Tomcat or Hibernate. Your application should have scalebility problem. I do suggest you to investigate your application before investing to a fancy application server.
So we have a busy legacy web service that needs to be replaced by a new one. The legacy web service was deployed using a WAR file on an apache tomcat server. That is it was copied over into the web apps folder under tomcat and all went well. I have been delegated with the task to replace it and would like to do it ensuring
I have a back up of the old service
the service gets replaced by another WAR file with no down time
Again I know I am being overly cautious however it is production level and I would like everything to go smooth. Step by step instructions would help.
Make a test server
Read tutorials and play around with the test server until it goes smoothly
Replicate what you did on the test server on the prod server.
If this really is a "busy prod server" with "no down time", then you will have some kind of test server that you can get the configuration right on.
... with no down time
If you literally mean zero downtime, then you will need to replicate your webserver and implement some kind of front-end that can transparently switch request streams to different servers. You will also need to deal with session migration.
If you mean with minimal downtime, then most web containers support hot redeployment of webapps. However, this typically entails an automatic shutdown and restart of the webapp, which may take seconds or minutes, depending on the webapp. Furthermore there is a risk of significant memory leakage; e.g. of permgen space.
The fallback is a complete shutdown / restart of the web container.
And it goes without saying that you need:
A test server that replicates your production environment.
A rigorous procedure for checking that deployments to your test environment result in a fully functioning system.
A preplanned, tested and hopefully bomb-proof procedure for rolling back your production system in the event of a failed deployment.
All of this (especially rollback) gets a lot more complicated when you system includes other stuff apart from the webapp; e.g. databases.
We have a java-based web application that makes a couple bursts of asynchronous http calls to web services & api's. Using a default Jetty configuration, the application takes roughly 4 seconds to complete. The same operation in Tomcat is taking over a minute.
A slew of configuration changes for Tomcat have been attempted, but nothing seems to help. Any pointers?
Use a profiler to investigate where the time is spent. A good initial choice is jvisualvm in the JDK.
My initial guess would be a DNS issue.
It's not logical that tomcat needs 60 seconds for processing something that Jetty solves in 4. They are both executing Java code.
Is there thread congestion on tomcat? How many threads can the http connectors of tomcat and jetty handle at the same time? What is your configuration?
One suggesting i have to get to the bottom of your problem is to download the Tomcat source and step through the code. Although as mentioned... profiling would save you allot of time. Odd are that its a DNS issue.