The Association of System

Performance Professionals

The Computer Measurement Group, commonly called CMG, is a not for profit, worldwide organization of data processing professionals committed to the
measurement and management of computer systems. CMG members are primarily concerned with performance evaluation of existing systems to maximize
performance (eg. response time, throughput, etc.) and with capacity management where planned enhancements to existing systems or the design of new
systems are evaluated to find the necessary resources required to provide adequate performance at a reasonable cost.

This paper was originally published in the Proceedings of the Computer Measurement Group’s 2001 International Conference.

For more information on CMG please visit http://www.cmg.org

Copyright Notice and License

Copyright 2001 by The Computer Measurement Group, Inc. All Rights Reserved. Published by The Computer Measurement Group, Inc. (CMG), a non-profit
Illinois membership corporation. Permission to reprint in whole or in any part may be granted for educational and scientific purposes upon written application to
the Editor, CMG Headquarters, 151 Fries Mill Road, Suite 104, Turnersville , NJ 08012.

BY DOWNLOADING THIS PUBLICATION, YOU ACKNOWLEDGE THAT YOU HAVE READ, UNDERSTOOD AND AGREE TO BE BOUND BY THE
FOLLOWING TERMS AND CONDITIONS:

License: CMG hereby grants you a nonexclusive, nontransferable right to download this publication from the CMG Web site for personal use on a single
computer owned, leased or otherwise controlled by you. In the event that the computer becomes dysfunctional, such that you are unable to access the
publication, you may transfer the publication to another single computer, provided that it is removed from the computer from which it is transferred and its use
on the replacement computer otherwise complies with the terms of this Copyright Notice and License.

Concurrent use on two or more computers or on a network is not allowed.

Copyright: No part of this publication or electronic file may be reproduced or transmitted in any form to anyone else, including transmittal by e-mail, by file
transfer protocol (FTP), or by being made part of a network-accessible system, without the prior written permission of CMG. You may not merge, adapt,
translate, modify, rent, lease, sell, sublicense, assign or otherwise transfer the publication, or remove any proprietary notice or label appearing on the
publication.

Disclaimer; Limitation of Liability: The ideas and concepts set forth in this publication are solely those of the respective authors, and not of CMG, and CMG
does not endorse, approve, guarantee or otherwise certify any such ideas or concepts in any application or usage. CMG assumes no responsibility or liability
in connection with the use or misuse of the publication or electronic file. CMG makes no warranty or representation that the electronic file will be free from
errors, viruses, worms or other elements or codes that manifest contaminating or destructive properties, and it expressly disclaims liability arising from such
errors, elements or codes.

General: CMG reserves the right to terminate this Agreement immediately upon discovery of violation of any of its terms.
 Learn the basics and latest aspects of IT Service Management at CMG's Annual Conference - www.cmg.org/conference

End-To-End Scaling: The Response Time Pipe

Dr. Tim R. Norton

Buy the Latest Conference Proceedings and Find Latest Computer Performance Management 'How To' for All Platforms at www.cmg.org
Simalytic Solutions, LLC
CMG 2001, Session 3208, December 4, 2001

The notion of scaling used to mean “How big do we have to make the server?” Unfortunately, the
new e-business approach to applications has spread the work across many different components
owned by many different organizations. Now, when we talk about scaling, we have to address
Join over 14,000 peers - subscribe to free CMG publication, MeasureIT(tm), at www.cmg.org/subscribe

networks, storage, security, application architecture, and even other entire applications. This pa-
per proposes an approach to modeling business transactions to determine what is impeding the
business process, what to do about it, and the effect of taking that action.

1. Introduction have to address many different components of differ-

ent types, such as networks, web servers, database
When we talk about ‘scaling’ an application we’re
servers, and storage devices. The relationships be-
interested in how much bigger it can become. If it
tween the components are complicated by security
processes 1,000 orders a day now, will it be able to
issues, application architectures and services provided
process 100,000 orders a day six months from now? In
by other companies. Such services, such as B2B
other words, will it scale by a factor of 100? In the past,
(Business-To-Business) solutions for functions such as
that type of scaling meant “How big do we have to
credit card processing and distributed document man-
make the server?” Times are different with the new e-
agement, are really entire applications but they appear
business approach to applications because work is not
to be a single component. This paper proposes an ap-
only spread across many different components, but
proach to modeling business transactions to determine
often some of those components are owned by differ-
what are the major obstacles impeding the business
ent organizations within the company or even by differ-
process, what are the actions needed to minimize the
ent companies. Now, when we talk about scaling, we
effects of the obstacles, and because there
Measurement are often mutually exclusive alternatives to
A dealing with obstacles, what are the effects
of taking different actions.
End User
Of course, before there can be any
! " # Server view of the future, there must be an under-
Measurement
standing of the present. Measuring the
B overall, or end-to-end, response time of web
applications provides the understanding of
what is happening; and a model of the re-
End User Server sponse time provides the view of what will
! " #
happen. By changing component behaviors
$ % & ' ( ) * in the model, different actions can be ex-
SM
Figure 1: The Response Time Pipe plored and different views of different fu-
! end-user connection to local LAN tures exposed. Most of the time, the
behaviors we want to change are those re-
" hosting site ISP (Internet Service Provider) lated to bottlenecks somewhere in the path
# hosting site application server the transaction follows.
$ end-user’s LAN environment The ability to identify bottlenecks in the
% end-user’s corporate firewall path of a web transaction is directly related
& end-user’s corporate ISP to the granularity of the measurements
' Internet backbone along that path. To visualize this process,
( hosting site firewall think of the path the transaction takes as a
) hosting site web server pipe that connects the end-user with the
web server as shown in Figure 1. If only one
* hosting site database server measurement is available, then the section
of the pipe that it represents will appear

© 2001 Simalytic Solutions, LLC, All rights reserved. Permission is granted to publish this article in the 2001 Computer Measurement Group
Conference Proceedings. Simalytic SM, The Response Time PipeSM and RTP SM are servicemarks of Simalytic Solutions, LLC. All other trade-
marked names and terms are the property of their respective owners.

Find a CMG regional meeting near you at www.cmg.org/regions

 Learn the basics and latest aspects of IT Service Management at CMG's Annual Conference - www.cmg.org/conference

End-To-End Scaling: The Response Time Pipe CMG01 Session 3208, December 4, 2001
smooth and straight. If several measurements are as a transaction moves from one section to another. Of
available then the major bottleneck can be identified as course, the political process for measuring each com-

Buy the Latest Conference Proceedings and Find Latest Computer Performance Management 'How To' for All Platforms at www.cmg.org
one of the sections with reduced capacity. If there is a ponent wants these delays accounted for in the re-
single small pipe section, then we cannot tell the dif- sponsiveness of the other components to avoid
ference between a pipe that has uniformly poor per- missing performance objectives that effect bonuses
formance and a pipe that performs very well except for and promotions.
a single constriction or bottleneck. Unfortunately, the Techniques to measure individual systems have
granularity must be relatively fine before corrective ac- been well understood for some time. Techniques to
tion can be determined. It is just not acceptable to tell measure applications have gained sophistication and
Join over 14,000 peers - subscribe to free CMG publication, MeasureIT(tm), at www.cmg.org/subscribe

end-users that the server is performing fine so the popularity over the last several years. The challenge
problem must be ‘somewhere’ in the Internet. Figure 1 now is to provide a business focus that gets the best
shows two examples of a Response Time PipeSM for return on application measurement while reducing the
an application. Measurement A shows three meas- cost of data collection and analysis. The Response
urement sections and Measurement B shows the Time Pipe facilitates this objective by measuring each
same connection with ten measurement sections. The section at the highest level and collecting detail meas-
identifiers on each of the sections are only for illustra- urements from the problem sections but not from the
tion as to what might be measured, not to identify the sections that are performing well.
actual components. There are many more components
involved in a connection such as this, but from the 1.1 Background
standpoint of transaction response times, many com- Today’s computer environments must be viewed
ponents will be hidden because they are not directly with the objective of understanding how the systems
measured. Ideally, each component should be meas- meet the end user’s requirements. By addressing the
ured and treated as a section of the RTPSM (Response business needs, we avoid viewing the computing envi-
Time Pipe), but that is seldom practical. What is ronment as an end in itself, and we can then relate the
measured for any given section of the pipe often de- benefits of an application to the business that depends
termined simply by what is already being measured or on it. Unfortunately, there are many pressures that try
what can be measured easily and quickly. to shift the focus to advances in technology without
When looking at transaction based applications, it regard for what the computing environment provides to
is easy to focus on the methods of measurement that the business it was intended to support. Advances in
are well known and comfortable. However, web appli- technology lead to a very rapid change, and it is often
cations are seldom measured in these terms. (Some difficult to relate the value of that change to the overall
planners even question if they are measurable in these business in an objective manner. (Business in this
terms!). Instead, they are measured using metrics like context means more than a for-profit company. It can
‘hits per second’ (the number of web page retrieves include any type of company, institution, agency, or
per second) and ‘stickiness’ (how long a user stayed at organization with an overall objective, be it revenue,
the site and clicked on different links) that don’t trans- service or regulatory.)
late well to the transaction modeling techniques that Measurement has traditionally focused on re-
we have used for so many years. Transactions vary in sources (CPU utilization, I/O rate, etc.) and workflows
how many web pages are required to complete the (job throughput, internal transaction response times,
business functions, and web pages vary in how many etc.) to determine if a given system is “good enough” to
artifacts (images, frames, ads, text, etc.) are retrieved. service a workload (which, in theory, translates to an
It is very difficult to relate such low level traffic to the application). Today, application measurement in large
overall business. The argument has been made that computer installations with multiple systems requires
business transactions will meet the overall service ob- an understanding of not only operating systems, plat-
jective if each of the components meets its service forms, clients, servers, networks, transaction systems,
objective. However, variability within a component of- etc., but also the relationships between them and the
ten requires that its service objective have a broad business objectives (such as staffing levels and
range to avoid false problem alerts. Normally the re- “widgets” sold). This relationship allows business man-
sponsiveness of all the components average out agers to understand the impact of application respon-
across the transaction path, but sometimes several siveness on the overall business objectives. Instead of
components are on the high end of the acceptable analyzing individual systems, the responsiveness of
range at the same time, which causes the overall the application needs to be understood across the en-
transaction to fail to meet its objective. Also, it is easy tire enterprise to insure that the computing environ-
to see from Figure 1 that there are many places in the ment addresses the requirements of the business
Response Time Pipe where a component of higher objectives and goals. But this understanding requires
capability may have to wait for a component of lower not only measurement of both the application (end-to-
capability. These narrow sections of the RTP can ac- end response time) and the individual components
count for traffic delays due to congestion and queuing, (internal response time), but also an understanding of

Find a CMG regional meeting near you at www.cmg.org/regions

 Learn the basics and latest aspects of IT Service Management at CMG's Annual Conference - www.cmg.org/conference

End-To-End Scaling: The Response Time Pipe CMG01 Session 3208, December 4, 2001
the relationship between the two. The focus of the Re- • Wire Sniffing: monitoring, decoding and ana-
sponse Time Pipe is to provide the understanding of lyzing either raw network (sniffer) traffic or

Buy the Latest Conference Proceedings and Find Latest Computer Performance Management 'How To' for All Platforms at www.cmg.org
the relationship between application responsiveness server network packets (i.e., TCP/IP).
and individual component responsiveness. • Benchmarking: application scripts periodically
2. Response Time Measurement executed and measured.
The idea of response time measurement has Although there are variations of these techniques
been around for a long time. Early mainframe transac- in both the cited references and other sources, the
tion systems, such as CICS and IMS, quickly devel- general concepts fall into the four broad categories
Join over 14,000 peers - subscribe to free CMG publication, MeasureIT(tm), at www.cmg.org/subscribe

oped robust measurement facilities. Often referred to above. There are many factors involved in any decision
as internal response time, these measurements reflect to measure an application. Because each of these
the time from when the host system receives the authors has focused on a somewhat different combi-
transaction until a response is sent back to the user. nation of these factors, their conclusions and sug-
The application was considered to be performing well if gested solutions are more focused toward one of the
the internal response time was within prescribed limits. four categories than the other three.
Network time was generally considered a separate Tsykin and Langshaw (1999) are concerned
(external) problem to be dealt with by the network sup- about the volume of data and processing required to
port organization. correlate individual units of work across a complex
The proliferation of multiple-tier client/server ap- enterprise, so they advocate a technique based on
plications has made response time measurement client instrumentation that characterizes user work
much more complex. There is no longer a single place patterns, instead of collecting detailed transaction data.
to collect the measurement information needed to de- McBride (1997) focuses on the need to identify
termine how an application is performing. Network time and measure the business transaction and advocates
is now interwoven with the response times of other the use of application instrumentation with ARM
components of the application and cannot be easily (Application Response Measurement).
deferred to another organization. Furthermore, even if Smead (1998) provides an in-depth analysis of
all the transaction data is collected, it often doesn’t different application instrumentation techniques, but is
contain enough information for a planner to understand focused on the low-level IT transaction, rather than the
the impact of the application’s performance on the high level business transaction.
overall business.
Lipovich (1997) takes an application level, rather
2.1 Measurement Techniques than resource usage, view but looks at the compo-
The Response Time Pipe doesn’t provide any nents of the application response time from a server-
new techniques for measuring transactions, but in- centric perspective.
stead, it provides a new way of using the measure- Smith and Williams (1998) provide an interesting
ments from existing techniques. The details of various approach to understanding application design for mod-
techniques for measuring response time are available eling with the use of Message Sequence Charts to de-
in the current literature (Knight and Haworth 1996; scribe application behavior. These charts provide a
Lipovich 1997; McBride 1997; Ramanathan and Perry very clear representation of how messages and func-
1999; Smead 1998; Smith and Williams 1998; tions flow between servers or components in an appli-
Thompson, Muñoz, and DeBruhl 1997; Tsykin and cation. Their use of these charts to represent three
Langshaw 1999). Some of these concepts are briefly types of CORBA-based synchronization (synchronous,
described below. The interested reader is encouraged deferred synchronous and asynchronous) highlights
to refer to these, and other, papers on various aspects some of the pitfalls in selecting measurement points
of the general topic of application response time and attempting to correlate resource usage to end-to-
measurement for specific implement ation details. end response time.
Tsykin and Langshaw (1999) provide a good 2.2 Measurement Points
overview of the general techniques. They list four
broad techniques for application measurement: The concept of measurement points was intro-
duced by the author to promote a top down approach
• Application instrumentation: modifying the ap- to measuring transactions. The Response Time Pipe is
plication at the source code level to collect an extension of that idea. A full explanation of meas-
performance data. urement points is available in (Norton 1999). By start-
• Client instrumentation: inserting hooks into the ing with the business needs and functions, the
client environment to collect data on activities measurement effort can focus on actions which sup-
such as operating system interrupts and/or port business improvement to gain quicker acceptance
messages (as with Microsoft Wi ndows). by management and other sponsors. The Response
Time Pipe allows the data collected to be easily identi-
fied as either required or unnecessary.

Find a CMG regional meeting near you at www.cmg.org/regions

 Learn the basics and latest aspects of IT Service Management at CMG's Annual Conference - www.cmg.org/conference

End-To-End Scaling: The Response Time Pipe CMG01 Session 3208, December 4, 2001
The reader is reminded that this is not intended to In fact, you can think of each RTP section as the part
be a definitive, detailed description of transaction of the transaction path that a particular measurement

Buy the Latest Conference Proceedings and Find Latest Computer Performance Management 'How To' for All Platforms at www.cmg.org
measurement techniques. Each real client/server ap- covers. For example, in Figure 1B, measurement data
plication will differ. There are many measurement tools for section 4 (end-user’s LAN environment) might be from
to chose from, some of which may implement other sniffer data for the backbone section of the end-user’s
techniques. Omission of a tool or technique only indi- corporate LAN. The number of network packets and
cates the author is not familiar with it, not that there is the response times between each packet sent and its
any reason not to use it. The purpose of this short dis- acknowledgment are what can be measured. An ex-
cussion is to encourage critical thinking about what is ample formula might be something like:
Join over 14,000 peers - subscribe to free CMG publication, MeasureIT(tm), at www.cmg.org/subscribe

being measured and where the measurements are r4 = SUM ( (k 41 - j41), …, (k4n - j4n) ) / n (1)
taken (measurement points). It is expected that read-
ers will identify measurement points supported by tools where r4 is the average response time of packets, j4 is
with which they are experienced. This is not intended the timestamp of a packet (j41 for the first packet
measured through j4n for the n packet measured), k4
th
to imply any negative connotation to these, or any
other, techniques, but to encourage readers to investi- is the timestamp of the packet’s acknowledgment, and
gate what is being measured, how it is being measured n is the number of packets, all for section 4 of the RTP.
and the relationship between the measurements, the Care must be taken to use the actual packet acknowl-
transactions and the resulting business value of per- edgment and not the response to the request in the
formance trade-offs to a given application. packet. For example, if the packet contains an HTTP
GET request, the acknowledgment is the TCP/IP ACK,
3. The Response Time Pipe not the web page requested. Some network protocols
When building a Response Time Pipe, the overall do not acknowledge every packet or block acknowl-
th
objective is to develop a set of transformation formulae edge every n packet. Such behavior must be consid-
that are then combined to provide the total transaction ered when creating this formula.
response time. The formula for each section of the The objective of the second formula is to under-
RTP is based on that section’s contribution to the stand the relationship between the section metric and
overall response time. (Note: All of the formulae pre- the business transaction. This requires some form of
sented here are for illustration only. Each application correlation between the two, either by identifying which
requires the creation of appropriate formulae for each of the low level items being measured (network pack-
section of the Response Time Pipe.) To create the set ets in the example) belong to each of the transactions
of formulae for a section of an RTP, start with the low- or by running the transactions in a standalone envi-
est level measurement data available and create a ronment and just measuring all of the low level items.
formula for the response time of whatever it measures, An example formula might be som ething like:
such as network packets or web server hits. Each suc-
cessive formula within the formulae set for that section p4 = q 4 / t ∗ i (2)
builds on the prior formula, until a response time num- where p4 is the average number of packets per trans-
ber is derived for use in the overall response time for- action, q4 is the count of the number of packets asso-
mula (see Equation (5) on the next page). Different ciated with the transaction for section 4 of the RTP and
measurement units and scales can be used for each t is the measured number of transactions per second
section because the final response time value derived and i is the number of seconds over which the packets
is for the impact of that section on a single business were counted.
transaction. The final scale for the response time val-
The objective of the third formula to understand
ues for each of the RTP sections will be the same be-
the load on the measured section of the RTP. It is very
cause it must match the scale used for the business
important to understand the difference between the
transaction objective (i.e., if the business transaction
current load from the transactions of interest and the
objective is expressed in seconds per transaction, then
load from other traffic. The predictive value of the Re-
the response time values for each section of the RTP
sponse Time Pipe depends on also understanding the
must also be in seconds). The remainder of this sec-
future load of both. In the above example, assume the
tion of the paper shows the creation of an RTP using a
transaction we’re interested in contributes t∗137 pack-
network section as an example. The creation of the
formulae shown in Equations (1) through (4) make up ets per second to the section load, where t is the
a formulae set for one section of the RTP and would measured number of transactions per second. Load
be repeated for each RTP section (the number of for- from other workloads must be measured or estimated
mulae required for a formula set will vary depending on independently. It is also extremely important to under-
the measurement data available and the type of RTP stand the variability of the other workloads. If they are
section). uniform over the measurement interval then they will
affect all transactions in the measured workload
The objective of the first formula is to have some equally. However, as their variability increases, their
low level measurements for each section of the RTP. impact will become more erratic, thus reducing the ac-

Find a CMG regional meeting near you at www.cmg.org/regions

 Learn the basics and latest aspects of IT Service Management at CMG's Annual Conference - www.cmg.org/conference

End-To-End Scaling: The Response Time Pipe CMG01 Session 3208, December 4, 2001
curacy of this formula. The measurement interval may where R is the total transaction response time and R1
need to be reduced to decrease workload variability. through Rn are the calculated response times for sec-

Buy the Latest Conference Proceedings and Find Latest Computer Performance Management 'How To' for All Platforms at www.cmg.org
The future load is based on the business forecast. tions 1 through n. There is no restriction on the com-
Therefore, the load in a section might be expressed plexity of this formula except what is practical to collect
something like: data for and to solve. In fact, it is quite reasonable to
u4 = ( ( t ∗ p4 ∗ s4 ∗ f ) + ( x4 ∗ y4 ∗ z4 ) ) / c4 (3) use the results or metrics from one section in the part
of the combination formula for a different section. For
where u4 is the utilization of section, t is the measured
example, high loads in one section might cause
number of transactions per second, p4 is the number queues to build up in another to the point where pack-
Join over 14,000 peers - subscribe to free CMG publication, MeasureIT(tm), at www.cmg.org/subscribe

of packets in section 4 for each transaction, s4 is the ets are rejected and performance suffers due to in-
average size of the packets for the transactions, f is creased retries.
the forecast multiplier (1 for the current load, 1.3 for
projection of 30% more load, etc.), x4 is the measured 4. Transaction Measurement
packets per second for all other workloads, y4 is the For any given application, understanding the
average size of the other packets, z4 is the forecast measurement points (where measurement data should
multiplier for other work in the section, and c4 is the be collected in the application) is a function of both
total capacity, all for section 4 of the RTP. The load in what the application does and the objective of the
this case is expressed as utilization because that’s measurement. What constitutes a transaction? How do
what is needed in Equation (4) below. we count them? What is the business impact if there
are more (or fewer) transactions than expected or if
The objective of the fourth formula is to develop a
they take more (or less) time to complete? Measure-
transformation function from the measured units to
ments for Service Level Management (Service Level
response time units. Following with the same example,
Objectives and Service Level Agreements) may satisfy
assume we observe that there are 137 network pack-
a political need, but they will be frustratingly useless if
ets (with accompanying acknowledgments) for each
they do not provide enough information to determine
transaction and that the packet response time in-
what is causing the application response time to fail to
creases by a factor of three times the section utilization
meet the service objective. On the other hand, large
above 40%. (Please note that this is a completely hy-
amounts of resource-centric information (i.e., CPU
pothetical example with no basis in real measure-
utilization, network segment utilization, I/O rates, etc.)
ments. These formulae, relationships and
doesn’t help the decision makers understand the im-
measurement values are for illustrative purposes only
pact to the application at the business level. The Re-
and should not be used without modification and verifi-
sponse Time Pipe provides a way to take all of the
cation.) We can now express the impact of this section
measurements, from many different measurement
of the RTP with a formula like:
points, and combine them into a single response time
R4 = IF( u4<0.4, r4 ∗ p4, (r4 ∗ (u4 ∗ 3 )) ∗ p4) (4) value that can be verified using existing end-to-end
where R4 is the transaction response time impact, r4 is measurement tools. The measurements don’t have to
the average response time of packets (from Equation be in the same units or even of the same type. The
(1) above), p4 is the average number of packets per only requirement for building a Response Time Pipe is
transaction (from Equation (2), 137 in this example) that there must be a way to connect the measure-
and u4 is the utilization from Equation (3), all for sec- ments for a given section of the RTP with the transac-
tion 4 of the RTP. Because each section of the RTP tions being modeled. Verification then becomes very
has its own transformation formula that is based on a important but it also can be done pragmatically. Meas-
measurement of that section, the type of metric used urement data from different sample times can be
must measure only that section, and not the remaining loaded into the model and verified against the end-to-
sections, of the RTP. If a metric also measures an ad- end measurements to insure that the results are con-
jacent section of the RTP, which is also included in the sistent.
final combining formula, then the final transaction re- Once an overall Response Time Pipe model is
sponse time value will be incorrect (effectively double built, it should be verified that its result is reasonably
counting a section of the RTP). The complexity of the close to measured response times. Then the overall
transform function is dependent on the available response time value can be used to determine the im-
measurements and the desired accuracy. pact of changes to different sections of the RTP. The
The objective of the fifth formula is to combine all objective is not to predict the exact response time of a
of the transformation functions into a single formula transaction under all conditions, but rather to see how
that predicts the overall, or end-to-end, response time major changes effect the overall response time, so that
by combining the results from each section of the RTP. their business value can be determined.
In it’s simplest form this combination will be a summa- End-to-end response time measurements must
tion, such as: be related back to the business impact. Response time
R = R1 + R2 + … + Rn (5) is a valid metric only if there is some valid business

Find a CMG regional meeting near you at www.cmg.org/regions

 Learn the basics and latest aspects of IT Service Management at CMG's Annual Conference - www.cmg.org/conference

End-To-End Scaling: The Response Time Pipe CMG01 Session 3208, December 4, 2001
reason to use it. An example of this relationship is network section, is as described above in section 3,
shown by relating the responsiveness of an application The Response Time Pipe. Because this example is

Buy the Latest Conference Proceedings and Find Latest Computer Performance Management 'How To' for All Platforms at www.cmg.org
supporting an order entry call center to the number of just to illustrate the RTP, we will use some extreme
calls an operator can handle in an hour. The fewer simplifying assumptions, such as the effect of load on
calls the operator handles means the more operators network utilization in Equation (4) and the effect of
that are required for a given call volume. That relation- server load below. These are not realistic assumptions
ship provides the information necessary to make the but adequate for the purposes of illustration.
business decision of upgrading the server or hiring For RTP section 1, assume:
more operators (Norton 1998).
r1 = 0.3 seconds from (1)
Join over 14,000 peers - subscribe to free CMG publication, MeasureIT(tm), at www.cmg.org/subscribe

Understanding the overall end-to-end transaction

response time only addresses part of the problem. The p1 = 180000/10∗900=20 (2)
end-to-end transaction response time is directly related u1 =((10∗20∗300∗f)+(2500∗700∗z))/5000000 (3)
to bottlenecks or constrictions in the RTP. A single u1 = 36% if f=1, z=1 (3)
poorly performing component will cause increased re-
sponse time, regardless of the speed and capacity of u1' = 47% if f=10, z=1 (3)
all of the others components. The Response Time u1'' = 71% if f=1, z=2 (3)
Pipe doesn’t provide a detailed analysis of any of the R1 = 0.3 ∗20 = 0.6 for u1 < .4 (4)
sections. Instead, it provides a way to determine if im-
proving the responsiveness in one section makes a R1' =0.3∗(0.47∗3)∗20=8.46 for u1 > .4 (4)
significant enough difference to the overall response R1'' =0.3∗(0.71∗3)∗20=12.78 for u1 > .4 (4)
time to improve the business. Continuing with the
same example from above, the overall effect on re- For RTP section 2, assume that we measured
sponse time can be examined for different alternatives, web server hits at the server with the following values
such as reducing either s4, the average size of the (please remember that this is an extreme example,
packets for the transactions in Equation (3), or p4, the greatly over simplified, for illustrative purposes only):
average number of packets per transaction in Equation Hits per transaction = 15
(4). These are two very different actions and require Average response time per hit
different implementation. Either change will have an = 0.7 seconds if hits/sec < 300
effect on the results of Equation (5). Then the question
becomes which has the greater desired effect and = 1.9 seconds if hits/sec > 300
what is the cost to implement that change. The Re- Average response time per transaction
sponse Time Pipe helps understand which alternative = 15∗0.7 = 10.5 seconds if hits/sec < 300
provides the greatest return in the form of improved
= 15∗1.9 = 28.5 seconds if hits/sec > 300
response time. How to implement either one or the
trade-offs in terms of costs, such as implementation R2 = 15 ∗0.7 = 10.5 for h1 < 300
and operations issues, are best addressed by other, R2' = 15 ∗1.9 = 28.5 for h1 > 300
more traditional, techniques, but those decisions are
much easier when the effect on the overall business is For the overall analysis we can look at several
known. The value of the Response Time Pipe is gain- alternatives:
ing the understanding as to where to apply those tech- Current response time:
niques without having to try them everywhere to
R = R1 + R2 = 0.6 + 10.5 = 11.1
determine that only a few have a return to the busi-
ness. Increased network load response time (f=10):
In the final analysis, the measurement objective R = R1' + R2 = 8.46 + 10.5 = 18.96
has the greatest influence over the type of transactions Increased network load response time (z=2):
to measure. Business related questions will focus at-
R = R1'' + R2 = 12.78 + 10.5 = 23.28
tention on business transaction measurement and re-
source related questions will focus measurement on IT Increased server load response time (h>300):
transaction measurement. While it is certainly possible, R = R1 + R2' = 0.6 + 28.5 = 29.1
and even desirable, to collect both measurements, any
correlation between the two must be done very care- The way these response time values are as-
fully. The Response Time Pipe provides the formal sessed depends on the business transaction response
structure to develop and define that relationship. time objective, so assume that 20 seconds is accept-
able for this business, based on what the transaction
5. Simple Example does and the nature of the business. In that case, we
Now let’s look at a very simple example of a Re- can see, at a high level, that a ten fold increase in
sponse Time Pipe that only has two sections, one net- transaction network volume will still result in accept-
work and one web server. Assume section 1, the able response times. However, either doubling the

Find a CMG regional meeting near you at www.cmg.org/regions

 Learn the basics and latest aspects of IT Service Management at CMG's Annual Conference - www.cmg.org/conference

End-To-End Scaling: The Response Time Pipe CMG01 Session 3208, December 4, 2001
other network traffic or increasing server, load will ness result to avoid massive data collection and
cause the response time to be unacceptable. If this is analysis problems.

Buy the Latest Conference Proceedings and Find Latest Computer Performance Management 'How To' for All Platforms at www.cmg.org
the only transaction using the server then it will gener- The Response Time Pipe is a series of response
ate 150 hits per second (10 transactions per second ∗ time measurements, represented as sections of a
15 hits per transaction). Therefore, doubling the trans- pipe, connected together to provide an overall busi-
action volume will not cause a response time problem ness analysis. Each section is related to the application
from the network perspective but will exceed what the by the way its measurements affect the overall re-
server can absorb without increased response times. sponse time. Because unique formulae are developed
This example shows how some very quick and for each section, there are no requirements that the
Join over 14,000 peers - subscribe to free CMG publication, MeasureIT(tm), at www.cmg.org/subscribe

simple calculations can provide a great deal of insight same measurement technique be used for every sec-
about transaction response times, especially when tion. Each section can use different metrics and tech-
coupled with the business objectives and expectations. niques as long as the results for each section describe
It also shows how easy it is to jump to wrong conclu- its impact on the business transaction in the same
sions when the interrelationships between RTP sec- units as the business transaction objective.
tions aren’t considered, as in the case above of How measurements are connected is more im-
increasing the transaction arrivals in the network sec- portant than where the application is measured, which
tion but neglecting to propagate that increase to the is more important than how the measurement is im-
server section. Such errors can be avoided by imple- plemented. This top down approach starts with the
menting the RTP with some calculation tool, such as a business need to determine what type of information is
spreadsheet program. required and then implements the measurement tech-
In addition, the RTP results for different alterna- nique that both provides that type of information and
tives can be connected with an overall business proc- fits with the application. If the business need is to un-
ess model to see the business level impact of the derstand the number of call center operators to hire,
changes. Assume the transaction supports some type then there must be a section of the Response Time
of call center that receives 3,000 calls during the peak Pipe for each of the required activities. If the business
hour. If it takes an operator an average of 15 transac- need is to understand the server capacity required to
tions plus 3 additional minutes per call, then 289 op- meet the planned call volume, then each of the server
erators are required, as shown by: types used must be shown as an RTP section while all
289 = 3000 / ( 60 / (((15 *11.1)/60)+3)) of the network can be a single section. In each case,
once the business need has been identified, it be-
For the increased network load alternative, 387 op- comes much easier to determine where, and then how,
erators are required because the transaction response to measure the application and to create a Response
time goes up to 18.96 seconds, as shown by: Time Pipe showing the relationships between those
387 = 3000 / ( 60 / (((15 *18.96)/60)+3)) measurements.
For the increased server load alternative, 514 opera-
tors are required because the transaction response
time goes up to 29.1 seconds, as shown by:
514 = 3000 / ( 60 / (((15 *29.1)/60)+3))
The difference between 289 and 387 operators, or
between 289 and 514 operators, to support the busi-
ness over the peak hour is substantial and just the type
of information the decision maker is looking for to as-
sess the ROI (Return On Investment) for a network or
server upgrade. This, admittedly exaggerated, exam-
ple shows how the Response Time Pipe provides es-
timated response time information in a way that can be
used effectively at the business decision level.
6. Conclusion
The traditional view of application measurement is
evolving because of the desire to understand the im-
pact that application response time has on the overall
business. Applications designed to exploit a cli-
ent/server architecture greatly increase the complexity
of both the computer system configurations and the
applications themselves. Measurement of these appli-
cations is very complex and must focus on the busi-

Find a CMG regional meeting near you at www.cmg.org/regions

 Learn the basics and latest aspects of IT Service Management at CMG's Annual Conference - www.cmg.org/conference

End-To-End Scaling: The Response Time Pipe CMG01 Session 3208, December 4, 2001

7. References
Knight, Alan and Jonathon Haworth. 1996. Self Instru-

Buy the Latest Conference Proceedings and Find Latest Computer Performance Management 'How To' for All Platforms at www.cmg.org
menation - A Discussion of Requirements and
Approaches. In UKCMG, Proceedings: Com-
puter Measurement Group.
Lipovich, G. Jay. 1997. Fixing Capacity Planning’s
Achilles Heel: An Approach to Managing Fore-
cast Inaccuracy. In Computer Measurement
Join over 14,000 peers - subscribe to free CMG publication, MeasureIT(tm), at www.cmg.org/subscribe

Group, Proceedings.
McBride, Doug. 1997. Performance Management of
the Desktop Client Fact or Fantasy? In Com-
puter Measurement Group, Proceedings.
Norton, Tim R. 1998. Don’t Predict Applications When
You Should Model the Business. In Computer
Measurement Group, Proceedings:922-933.
Anaheim, CA: CMG, Inc.
Norton, Tim R. 1999. End-To-End Response Time:
Where to Measure? In Computer Measure-
ment Group, Proceedings:322-330. Reno, NV:
CMG, Inc.
Ramanathan, Srinivas and Edward H. Perry. 1999. The
Value of a Systematic Approach to Measure-
ment and Analysis: An ISP Case Study. In
SIGMETRICS, Proceedings V24 N1:232-233.
Atlanta, Georgia: ACM.
Smead, Steven. 1998. Service Level Instrumentation
101 - An in depth look at how to instrument
end user transactions. In Computer Measure-
ment Group, Proceedings.
Smith, Connie U. and Lloyd G. Williams. 1998. Per-
formance Engineering Models of CORBA-
based Distributed-Object Systems. In Com-
puter Measurement Group, Proceedings.
Thompson, George I., Javier Muñoz, and James K.
DeBruhl. 1997. The Availability & Quality of
SAP R/3 Workload Data For Performance /
Capacity Management Process Requirements.
In Computer Measurement Group, Proceed-
ings.
Tsykin, Mike and Christopher D. Langshaw. 1999.
End-to-End Response Time And Beyond: Di-
rect Measurement of Service Levels. Com-
puter Measurement Group Transactions (95):
41-48.

Find a CMG regional meeting near you at www.cmg.org/regions