We have recently implemented time tracking into TS. Not normal time tracking, but we are using TS to track all time tied to a project for billing purposes. So before we only had Dev and QA time in TS, now we have PM time, Release Time, etc, etc. In addition to this change, we have also make a TS project for general categories such as admin, staffing, etc, with the goal of having everyone enter their full business day into TS.
The system has become progressively slower over the past few weeks and is now nearly unusable. I am not sure if it is related to the time tracking, but it is the only change in the system that we have made.
We are running version 3.5.73 on Tomcat 6.0.24 and SUN JVM build 1.6.0_18. The app server is separate from the database server. Both systems are Windows servers and the DB is MS SQL. From both a base OS perspective and SQL, everything looks fine - no i/o latency, IOPs seem normal, no waits, etc.
Tomcat paints a different picture with requests backing up in queue. Within a few minutes of booting the TS server we see dozens of busy connections with wait times well into the 2,000,000ms range.
The only thing that looks a little off is that Tomcat is reporting threads that failed to stop upon service restart and we are getting random SEVERE: Servlet.service() for servlet action threw exception errors in the Tomcat logs in addition to many com.trackstudio.exception.GranException: Sourced file: inline evaluation of: ``import java.lang.StrictMath; import com.trackstudio.tools.formatter.DateFormatte . . . '' : Method Invocation Float.parseFloat errors.
What is the best way to tell where the latency is within the app?
