The Prior Art Database and Publishing service will be updated on Sunday, February 25th, from 1-3pm ET. You may experience brief service interruptions during that time.
Browse Prior Art Database

Application Runtime Analysis for Achieving Response Time NFRs

IP.com Disclosure Number: IPCOM000234123D
Publication Date: 2014-Jan-13
Document File: 4 page(s) / 57K

Publishing Venue

The IP.com Prior Art Database


This publication provides the ideas that help determine the best possible application topology and ongoing monitoring of an application (say a 3 tier web application), in order to achieve/satisfy a given NFR such as response time.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 26% of the total text.

Page 01 of 4

Application Runtime Analysis for Achieving Response Time NFRs

Web applications usually require short response time, especially when a user is waiting at a web browser for their request to be serviced. When the web application run time environment is undergoing a technical problem, it is not unusual to see the response time getting larger than the stated response time business requirement. In extreme scenarios, when a key web application resource is unavailable, the web user requests will time out. This leads to customer dissatisfaction with the business which can be translated into financial loss.

One of the key problems facing Business application team is to choose the appropriate application topology and middleware components. Another key problem is how to monitor the continued operations of the application in order to achieve the NFR goals.


The response time monitoring tools currently available (Prior Art) are able to:
Track the response time for various components involved in a web application



Response time monitoring tools (like ITCAM for Transaction Tracking) are able to track the end-to-end transaction that covers different components and transaction segments between these components. (Prior Art)

Analysis algorithms such as Clustering, Pattern matching and Association are prior art.


Current monitoring tools do not identify which metrics are important to be monitored in order to satisfy the NFR (eg. business transaction response time). None of the existing art identifies how the application topology should be changed in order to achieve the NFR for a specific type of application - say a three tiered web application.

The main idea is to determine the best possible application topology and ongoing monitoring of an application (say a 3 tier web application), in order to achieve/satisfy a given NFR.

For a given application (ex: 3 tiered web application), provided is an analytics engine that recommends what elements of underlying IT infrastructure should be changed and monitored in order to achieve the given response time requirement (NFR).

It would take following datums as input:

a) Application deployment topology - middleware components connected to form an application.

b) Configuration of middleware components - examples: clustering enabled at Web Server, multiple Database servers, etc.

c) Business Rules or constraints

d) NFR - Response time requirements

It will produce a recommendation on

i) Any changes required in application topology

ii) What metrics to monitor on the middleware components, to achieve the required Response time characteristics.

iii) How to monitor these metrics - specific product/tool recommendations

Analytics engine will utilize the observational approach in understanding the application's run time characteristics and determine what middleware changes are necessary. It will also determine how to monitor the application to achieve the response time requirements.

Key benefits of...