Overview
The TeamConnect Performance Monitor silently captures data in the background on all TeamConnect requests. Any time a request exceeds a configurable threshold, the monitor log captures the data for that one request so that the information can be analyzed later by IT staff and/or Mitratech Support. Such analysis, and subsequent design changes, can improve application performance.
In contrast to general debug loggers in TeamConnect:
- Performance Monitor logs data for long-running requests only, so it doesn't create a strain on the system or on the person analyzing these logs.
- All data that is logged by Performance Monitor for a given request is guaranteed to be contiguous in the log file and does not overlap with any data from any other requests, which is another common difficulty when analyzing data from general debug loggers.
Resource requirements
The Performance Monitor is designed to be always on in production environments so that you can capture data related to performance issues whenever they happen. It has been load-tested and shown to incur less than 2% overhead on even highly loaded systems (using an 1800-user load test that drives an 8-core application server to 80% CPU utilization rates).
What information is captured?
For every long-running request, the Performance Monitor captures and logs HTTP request data, (limited) HTTP session data, JDBC call data and periodically gathered stack traces. The HTTP request and (limited) HTTP session data can be used to identify the user, the record, the search, the tool, etc. The JDBC call data, including timings, full SQL text and bind parameter values, can help isolate a variety of issues, including poorly performing queries, too many queries being executed, or too much data being returned. The periodically gathered stack traces can help identify performance issues in custom rules, custom Java blocks, or even core TeamConnect code.
You can configure a threshold, in milliseconds, for "stuck" requests. As soon as a request exceeds this stuck threshold, the monitor immediately logs all of the data it has gathered for this request so far to make sure this information is not lost (since normally long requests are only logged upon completion). Also, if any email addresses have been configured, the monitor will email an alert with the same data that it logged for the stuck request. If the request later completes, a second email is sent that the request has completed (become "unstuck").
The TeamConnect Performance Monitor doesn't capture any information related to hardware utilization. Hardware utilization data can be very valuable and can be captured by a variety of tools. However, often spikes in hardware utilization (e.g. CPU and memory) are caused by long-running requests and not vice versa. Of course, once CPU or memory reaches its limits, this can cause all requests to run slow, but often the key is to identify the initial long-running request(s) which triggered the CPU or memory spike in the first place.