Browse Prior Art Database

System and Method for Improving the Capacity Management Process

IP.com Disclosure Number: IPCOM000248505D
Publication Date: 2016-Dec-09
Document File: 5 page(s) / 209K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a system and method for improving the capacity management process.

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

1

System and Method for Improving the Capacity Management Process

The IT services offered over the internet, and within enterprise premises, increased rapidly over

the past few decades. The expectation of a consistent high-quality level of service is growing and

becoming more difficult to be met. In the meanwhile, the demand for a cost effective solution to

efficiently use computing resources according to workload variations is getting stronger,

especially for enterprise service providers.

Predicting enterprise applications service levels under various loads and resources is

widely done based on time and cost efficient performance modeling techniques [1]. A Queuing

Network Model (QNM) representing the various system resources (such as the CPU and Disk

I/O) is built and solved during this process. One input to the QNM solver is the amount of time

required to serve each transaction on each resource in all visits to the underlying resource, while

excluding the queuing time. This input value is known as the Service Demand. Obtaining such

service demands by measuring the time spent by a single user transaction on each resource faces

a major measurement problem due to small service demands. Additionally, some functionality,

such as caching, can be only triggered when multiple users access the system, which leads

capacity engineers to infer these service demands from multi-user measurements [2] [3] [4]. Such

approaches have problems which lead to various approximations and lengthy procedures. This

causes less accurate prediction results which are usually solved by deliberately increasing the

hardware requirements to compensate for this imprecision, resulting in an under-utilized

infrastructure. Additionally, the lengthy procedure can easily put an extra pressure on an already

busy capacity management (CM) project.

Transactions are created by users of enterprise applications to perform certain

functionalities (such as search and buy). These transactions are served by the various system

resources (such as the CPU and Disk I/O of each server) to fulfill the user request [1]. The flow

of the transaction through the system can be represented by a Queuing Network Model (QNM)

[1] such as the one shown in Figure 1. Each node represents a system resource (e.g., CPU, Disk

I/O) which consists of a processing unit and a queue for the transaction to wait if the processing

unit is busy. Each transaction may visit each resource multiple times and the total time required

to serve the transaction on each resource, during all visits and excluding the time in the queue, is

called service demand.

2

The Transaction Response Time (TRT) is the time spent by a certain transaction on all

system resources [1] which is the sum of the actual processing time (service demand) along with

the time in the queue as shown in Figure 2. The Transaction Profile (TP) is defined as the total

series of service demands on all system resources. Thus, the TP is the lower bound of the TRT

or,...