Abstract: A mechanism for efficient collection of data is described for runtime middleware environments. Two frequencies are used, a collection frequency (CF) to collect the data and an aggregation frequency (AF) to aggregate and persist the data in a repository. The collection cycle is a shorter time interval than the aggregation cycle. An agent residing in the container periodically collects a set of data upon every collection cycle from the components of the middleware system and caches the set of data locally. Upon every aggregation cycle, the agent applies an aggregation function to the collected set of data and persists the set of data into a repository after the aggregation function has been applied. The aggregation function is such that it resulting data represents the behavior of the runtime environment in the total duration of the aggregation cycle.

Abstract: A method of determining a root cause of a performance problem is provided. The method comprises analyzing a plurality of performance indicators/metrics in a first time period and determining that at least one performance indicators/metric is exhibiting abnormal behavior. The method further comprises analyzing the plurality of performance indicators/metrics over a second time period, the second time period is longer than the first time period, and determining trend information for each performance indicators/metric over the second time period. The method further comprises correlating the trend information for each performance indicators/metric with performance problem information stored in a knowledge base, identifying a potential cause of the abnormal behavior based on the correlation, and alerting a user of the potential cause.

Abstract: Systems and methods are described for diagnosing behavior of software components in an application server. The application server can comprise a plurality of components that process incoming requests. A diagnostics advisor can be deployed with the application server and can determine an efficiency and/or inefficiency of each of the components of the application server or other middleware system. The efficiency determined by computing a ratio of the number of requests that completed execution during a particular sampling time period to the number of requests that were received. The inefficiency is the ratio of the number of requests that are still being executed at the end of the sampling time period to the number of requests that were received. The diagnostics advisor employs the determined efficiency and/or inefficiency to diagnose a misbehavior or other problem of the components in the application server.

Abstract: A method of isolating relevant components associated with a performance problem. The method comprises creating a static model of a system under test, including determining relationships between components in a middleware system. The method also comprises creating a dynamic problem tree by applying the static model to the system at runtime. The method further comprises identifying a link probability for each relationship in the dynamic problem tree; and traversing the dynamic problem tree to detect redundant components. A component is redundant if it has a link probability with its downstream component greater than a pre-determined threshold value. The method also comprises removing redundant components from the dynamic problem tree; and returning a set of components which are potential components to be analyzed further to determine the root causes of the performance problem.

Abstract: A system and method for providing a static model map of behaviors in a middleware system, for use in identifying problems. In accordance with an embodiment, the system provides a view of the system which allows for analysis of the various components. Locations within the system where a request spends its time are categorized into either “wait” or “execution” locations. The components exhibit static behaviors which affect the response time and can be predefined for different types of components and analyzed independently. In turn the behaviors can be classified as either “wait” or “execution”, each of which can be considered aspects of a component. Each aspect of a component must satisfy the same efficiency/inefficiency as defined by the requirements on the system. An aspect that does not meet the criteria is considered a “problem aspect” and is analyzed further to find the cause of the problem.

Abstract: A method of isolating relevant components associated with a performance problem. The method comprises creating a static model of a system under test, including determining relationships between components in a middleware system. The method also comprises creating a dynamic problem tree by applying the static model to the system at runtime. The method further comprises identifying a link probability for each relationship in the dynamic problem tree; and traversing the dynamic problem tree to detect redundant components. A component is redundant if it has a link probability with its downstream component greater than a pre-determined threshold value. The method also comprises removing redundant components from the dynamic problem tree; and returning a set of components which are potential components to be analyzed further to determine the root causes of the performance problem.

Abstract: Systems and methods are described for diagnosing behavior of software components in an application server. The application server can comprise a plurality of components that process incoming requests. A diagnostics advisor can be deployed with the application server and can determine an efficiency and/or inefficiency of each of the components of the application server or other middleware system. The efficiency determined by computing a ratio of a number of requests that completed execution in the component during a particular sampling time period to the number of requests that were received by the component during the sampling time period. The inefficiency is the inverse of efficiency, i.e. it is a ratio of the number of requests that are still being executed by the one or more components at the end of the sampling time period to the number of requests that were received by the one or more components during the sampling time period.

Abstract: A method of determining a root cause of a performance problem is provided. The method comprises analyzing a plurality of performance indicators/metrics in a first time period and determining that at least one performance indicators/metric is exhibiting abnormal behavior. The method further comprises analyzing the plurality of performance indicators/metrics over a second time period, the second time period is longer than the first time period, and determining trend information for each performance indicators/metric over the second time period. The method further comprises correlating the trend information for each performance indicators/metric with performance problem information stored in a knowledge base, identifying a potential cause of the abnormal behavior based on the correlation, and alerting a user of the potential cause.

Abstract: A mechanism for efficient collection of data is described for runtime middleware environments. Two frequencies are used, a collection frequency (CF) to collect the data and an aggregation frequency (AF) to aggregate and persist the data in a repository. The collection cycle is a shorter time interval than the aggregation cycle. An agent residing in the container periodically collects a set of data upon every collection cycle from the components of the middleware system and caches the set of data locally. Upon every aggregation cycle, the agent applies an aggregation function to the collected set of data and persists the set of data into a repository after the aggregation function has been applied. The aggregation function is such that it resulting data represents the behavior of the runtime environment in the total duration of the aggregation cycle.

Abstract: A system and method for providing a static model map of behaviors in a middleware system, for use in identifying system problems. In accordance with an embodiment, the system provides a view of the system, such as a middleware system, which allows for analysis of the various components involved, such that analysis of one component does not affect the analysis of a second component. Locations within the middleware system where a particular request spends its time before returning a response are broadly categorized into either “wait” or “execution” locations. Irrespective of which request calls a component, the components exhibit the same behaviors which affect the response time of the request serviced. These exhibited behaviors are static and can be predefined for different types of components and analyzed independently of each other. In turn the behaviors can be similarly classified as either “wait” or “execution”, each of which can be considered aspects of a component.

Abstract: Computing the values of configuration parameters for optimal performance of associated applications. In one embodiment, a rules data is maintained indicating a corresponding rule for each of the configuration parameters of an application sought to be optimized. Each rule specifies the manner of calculation of the corresponding configuration parameter based on a corresponding set of production metrics. On receiving an indication that the value of a specific configuration parameter is to be computed, the rules data is examined and a specific rule (indicating a set of production metrics) corresponding to the specific configuration parameter is identified. The corresponding values of each of the set of production metrics are then determined and the value for the specific configuration parameter is calculated using the identified rule and the estimated values of the set of production metrics.

Abstract: Computing the values of configuration parameters for optimal performance of associated applications. In one embodiment, a rules data is maintained indicating a corresponding rule for each of the configuration parameters of an application sought to be optimized. Each rule specifies the manner of calculation of the corresponding configuration parameter based on a corresponding set of production metrics. On receiving an indication that the value of a specific configuration parameter is to be computed, the rules data is examined and a specific rule (indicating a set of production metrics) corresponding to the specific configuration parameter is identified. The corresponding values of each of the set of production metrics are then determined and the value for the specific configuration parameter is calculated using the identified rule and the estimated values of the set of production metrics.