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: 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: Monitoring asynchronous transactions in a computing environment is disclosed. A first unique identifier is determined when a first method executes. The identifier is associated with an asynchronous transaction. A second unique identifier is determined when a second method executes. If it is determined that the first unique identifier and the second unique identifier match, then is it determined that the asynchronous transaction started with the first method and completed with the second method. In one embodiment, code that identifies a routine that has instructions for determining the first unique identifier at runtime is added to the first method, and code that identifies a routine that has instructions for determining the second unique identifier at runtime is added to the second method.

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: Monitoring asynchronous transactions in a computing environment is disclosed. A first unique identifier is determined when a first method executes. The identifier is associated with an asynchronous transaction. A second unique identifier is determined when a second method executes. If it is determined that the first unique identifier and the second unique identifier match, then is it determined that the asynchronous transaction started with the first method and completed with the second method. In one embodiment, code that identifies a routine that has instructions for determining the first unique identifier at runtime is added to the first method, and code that identifies a routine that has instructions for determining the second unique identifier at runtime is added to the second method.

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: 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: 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 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: 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.