Abstract: Metrics are calculated from information acquired during execution of transactions for transactions that cannot be identified during execution. In-flight or execution related metrics are grouped by transaction type and time period. The transaction name is associated with the metrics once the transaction has completed, and data is reported for the time period once all transactions executing in that time period have completed. When a transaction has completed execution, in-flight metrics may be determined for the transaction for each time period in which other transactions executing in that time period have completed. When all transactions executing during a particular time period are complete, the in-flight metrics for transactions executing during that time period are determined and stored. The in-flight metrics may include concurrency, stalls and other data.

Abstract: Capacity planning is performed based on expected transaction load and the resource utilization for each expected transaction. Resource usage is determined for one or more transactions or URLs based on transaction specific and non-transaction specific resource usage. Once the resource usage for each transaction is known, the expected resource usage may be determined for an expected quantity of each transaction. The actual resources needed to meet the expected resource usage are then determined. Resources may include hardware or software, such as a central processing unit, memory, hard disk bandwidth, network bandwidth, and other computing system components. The expected resource usage for a transaction may based on the usage directly related to the transaction and usage not directly related to the transaction but part of a process associated with the performed transactions.

Abstract: Anomalous transactions are identified and reported. Transactions are monitored from the server at which they are performed. A baseline is dynamically determined for transaction performance based on recent performance data for the transaction. The more recent performance data may be given a greater weight than less recent performance data. Anomalous transactions are then identified based on comparing the actual transaction performance to the baseline for the transaction. An agent installed on an application server performing the transaction receives monitoring data, determines baseline data, and identifies anomalous transactions. For each anomalous transaction, transaction performance data and other data is reported.

Abstract: Capacity planning based on resource utilization as a function of workload is disclosed. The workload may include different types of requests such as login requests, requests to visit web pages, requests to purchase an item on an online shopping site, etc. In one embodiment, data is determined for each of a plurality of workloads. The data includes characteristics of a workload and resource utilization due at least in part processing that workload. Based on the data, utilization of each of the resources as a function of workload characteristics is estimated. Further, based on the estimated resource utilization, workload characteristics that are expected to cause each respective resource to reach a certain level are predicted. That level could be 100 percent utilization, but could be another level. Capacity planning is performed based on the workload characteristics that are expected to cause each respective resource to reach a certain level.

Abstract: Messages which are provided to an application are monitored. Similarities between the messages are determined based on a distance algorithm, in one approach, and messages which are similar are assigned to a common group. For example, the messages may be HTTP messages which include a URL, HTTP header parameters and/or HTTP post parameters. The messages are parsed to derive a string which is used in the distance calculations. Additionally, application runtime data such as response times is obtained and aggregated for the group. Further, a representative message can be determined for each group for comparison to subsequent messages. Results can be reported which include a group identifier, representative message, count and aggregated runtime data.

Abstract: One embodiment disclosed relates to a method of finding lock contention in an application with concurrent threads. Status data is retrieved by periodically sampling status of said threads. The periodically-sampled status data is accumulated, and the lock contention is statistically found from the accumulated status data. The status data may include location information that is usable to pinpoint the lock contention.

Abstract: Embodiments of the present invention that pertain to methods and systems for the calculation of resource requirements for a composite application are described. In one embodiment, information describing what component applications are associated with the composite application is received. Information describing metrics that are to be measured for the component applications is received. Information describing interrelationships between the component applications associated with the composite application is received. Information describing rules for calculating the resource requirements for the component applications is received. The rules are based on the interrelationships between the component applications and the metrics that are to be measured.

Abstract: An application monitoring system monitors one or more applications to generate and report application performance data for transactions. Actual performance data for one or more metrics is compared with a baseline metric value(s) to detect anomalous transactions or components thereof. Automatic baselining for a selected metric is provided using variability based on a distribution range and arithmetic mean of actual performance data to determine an appropriate sensitivity for boundaries between comparison levels. A user-defined sensitivity parameter allows adjustment of baselines to increase or decrease comparison sensitivity for a selected metric. The system identifies anomalies in transactions, components of transaction based on a comparison of actual performance data with the automatically determined baseline for a corresponding metric. The system reports performance data and other transactional data for identified anomalies.

Abstract: An application is monitored to identify different execution paths, e.g., sequences of invoked components, which occur due to the receipt of messages by the application. Similarities between the execution paths are determined based on a distance algorithm, in one approach, and execution paths which are similar are assigned to a common group. Additionally, application runtime data such as response times is obtained for the execution paths and aggregated for the group. The messages can also be grouped based on the grouping of the execution paths. Further, a representative execution path can be determined for each execution path group for comparison to subsequent execution paths. A representative message can similarly be determined for each message group. Results can be reported which include a group identifier, representative message, representative execution path, count, and aggregated runtime data.

Abstract: Anomalous behavior in a distributed system is automatically detected. Metrics are gathered for transactions, subsystems and/or components of the subsystems. The metrics can identify response times, error counts and/or CPU loads, for instance. Baseline metrics and associated deviation ranges are automatically determined and can be periodically updated. Metrics from specific transactions are compared to the baseline metrics to determine if an anomaly has occurred. A drill down approach can be used so that metrics for a subsystem are not examined unless the metrics for an associated transaction indicate an anomaly. Further, metrics for a component, application which includes one or more components, or process which includes one or more applications, are not examined unless the metrics for an associated subsystem indicate an anomaly. Multiple subsystems can report the metrics to a central manager, which can correlate the metrics to transactions using transaction identifiers or other transaction context data.

Abstract: A near out-of-memory condition in a memory space is detected by creating softly reachable objects which are garbage collected when the memory space is becoming full. The softly reachable objects are objects that can be cleared at the discretion of the garbage collector when heap memory is running low. An agent process of an application can create soft reference objects which reference the softly reachable objects, and periodically poll the soft reference objects to determine if the softly reachable objects have been cleared. If they have been cleared, the agent reports to the application so that a graceful shutdown of the application can be initiated. A report can also be sent to a user interface or other output device. Additional information regarding the memory space can be gained by using softly reachable objects of different sizes and/or ages. Further, a wait period for the polling can be set adaptively.

Abstract: Messages which are provided to an application are monitored. Similarities between the messages are determined based on a distance algorithm, in one approach, and messages which are similar are assigned to a common group. For example, the messages may be HTTP messages which include a URL, HTTP header parameters and/or HTTP post parameters. The messages are parsed to derive a string which is used in the distance calculations. Additionally, application runtime data such as response times is obtained and aggregated for the group. Further, a representative message can be determined for each group for comparison to subsequent messages. Results can be reported which include a group identifier, representative message, count and aggregated runtime data.

Abstract: Embodiments of the invention distribute profiling responsibilities for a clustered application to various instances of the application that generally run on different computer hosts. In an embodiment, the profiling responsibility is measured in terms of metrics wherein each profiling agent of an instance collects metrics about that instance. The metrics are prioritized and assigned to instances such that the highest priority metrics are assigned if possible. Each metric is associated with an expected performance overhead, and the assignment of metrics to an instance is done such that the performance overhead on that instance and/or host does not exceed a threshold. Other embodiments are also disclosed.

Abstract: Messages which are provided to an application are monitored. Similarities between the messages are determined based on a distance algorithm, in one approach, and messages which are similar are assigned to a common group. For example, the messages may be HTTP messages which include a URL, HTTP header parameters and/or HTTP post parameters. The messages are parsed to derive a string which is used in the distance calculations. Additionally, application runtime data such as response times is obtained and aggregated for the group. Further, a representative message can be determined for each group for comparison to subsequent messages. Results can be reported which include a group identifier, representative message, count and aggregated runtime data.

Abstract: Deviation of expected response times is used to characterize the health of one or more backend machines invoked by an application to process a request. Performance data generated in response to monitoring application execution is processed to select backend response time data. The selected data is processed to predict future values of a time series associated with backend response time. The predicted response time values are compared to actual response time values in the time series to determine a deviation from the predicted value. Deviation information for the time series data of response times is then reported to a user through an interface in a simple manner.

Abstract: Anomalous transactions are identified and reported. Transactions are monitored from the server at which they are performed. A baseline is dynamically determined for transaction performance based on recent performance data for the transaction. The more recent performance data may be given a greater weight than less recent performace data. Anomalous transactions are then identified based on comparing the actual transaction performance to the baseline for the transaction. An agent installed on an application server performing the transaction receives monitoring data, determines baseline data, and identifies anomalous transactions. For each anomalous transaction, transaction performance data and other data is reported.

Abstract: Deviation of an expected error rate for a backend server invoked by an application to process a request is used to characterize the backend server health. Performance data generated in response to monitoring application execution is processed to select backend error rate data. The selected data is processed to predict future values of a time series associated with backend error rates. The predicted error rate values are compared to actual error rate values in the time series to determine a deviation from the predicted value. Deviation information for the time series data of error rates is then reported to a user through an interface in a simplified manner.

Abstract: Capacity planning based on resource utilization as a function of workload is disclosed. The workload may include different types of requests such as login requests, requests to visit web pages, requests to purchase an item on an online shopping site, etc. In one embodiment, data is determined for each of a plurality of workloads. The data includes characteristics of a workload and resource utilization due at least in part processing that workload. Based on the data, utilization of each of the resources as a function of workload characteristics is estimated. Further, based on the estimated resource utilization, workload characteristics that are expected to cause each respective resource to reach a certain level are predicted. That level could be 100 percent utilization, but could be another level. Capacity planning is performed based on the workload characteristics that are expected to cause each respective resource to reach a certain level.

Abstract: Metrics are calculated from information acquired during execution of transactions for transactions that cannot be identified during execution. In-flight or execution related metrics are grouped by transaction type and time period. The transaction name is associated with the metrics once the transaction has completed, and data is reported for the time period once all transactions executing in that time period have completed. When a transaction has completed execution, in-flight metrics may be determined for the transaction for each time period in which other transactions executing in that time period have completed. When all transactions executing during a particular time period are complete, the in-flight metrics for transactions executing during that time period are determined and stored. The in-flight metrics may include concurrency, stalls and other data.

Abstract: Capacity planning is performed based on expected transaction load and the resource utilization for each expected transaction. Resource usage is determined for one or more transactions or URLs based on transaction specific and non-transaction specific resource usage. Once the resource usage for each transaction is known, the expected resource usage may be determined for an expected quantity of each transaction. The actual resources needed to meet the expected resource usage are then determined. Resources may include hardware or software, such as a central processing unit, memory, hard disk bandwidth, network bandwidth, and other computing system components. The expected resource usage for a transaction may based on the usage directly related to the transaction and usage not directly related to the transaction but part of a process associated with the performed transactions.