Dante Ko wrote:
My question is: what are the possible causes of this unaccounted time? Does anyone know of methods or tools that I can use in order to analyze the time Tomcat is spending loading classes, assigning threads, etc?
By the way, the time was determined by comparing the total time spent in the application vs the TTFB reported by Chrome Dev Tools.
If the Google tools measures the full round trip, meaning from the call to Tomcat to the response, then the difference is the portion of the application that it doesn't measure. This means the time from the initial timestamp to the Tomcat call, and the return from the call to the final timestamp. And since this is measured in milliseconds, I would think that it is likely queuing. Regardless, the possible causes are...
1. Lots of work being done prior to the call and/or after the return of the call.
2. Queuing. For example, the response comes back from Tomcat, but the application is busy working on other responses. This means that the response has to wait its turn for processing, and for the end timestamp.
3. Out of sync clock. Please make sure that the same
thread that takes the start time also take the end time. Some OSes, don't keep the clocks in sync between threads, so, you are measuring the out of sync of the clocks.
And to answer your question... Unfortunately, you will need to know what your application is actually doing. This can probably be easiest done with a profiler.
Henry