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 1996 International Conference.

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

Copyright Notice and License

Copyright 1996 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.
 CLIENT/SERVER END-TO-END RESPONSE TIME:
REAL LIFE EXPERIENCE
Mark Maccabee
IBM Thomas J. Watson Research Center
Yorktown Heights, NY

Abstract:
This paper deals with the use of End-to-End Response Time (ETE RT) information in a
production client/server application. The paper describes the instrumentation of the application,
the introduc-tion of ETE RT into the production environment, the business requirements for which
the ETE RT information is used and the current state of the evolving methodology for use of ETE
RT informa-tion. The main impression from user experience is that ETE RT is a powerful
business tool in a corporate environment. ETE RT data drives configuration updates and
software improvements. It is discussed almost daily at operations management meetings.
Although the data is technical (and contains a wealth of information) it relates well to terms that
end users and executives understand. The ETE RT facility was accepted and adopted very
naturally by the corporation.

environment comes in less expensive units (which

1. Introduction tends to reduce the importance of resource oriented
End-to-end response time is the time the user measurements). Thus the introduction of ETE RT
experiences in interacting with a computing system. It measurements and the methodology of its use in
is the duration between the start of a user’s request client/server environment are of significant business
(indicated by depressing a key or a button) and the interest (see [6]). Since the client/server environment
time when the user can use the data supplied in is relatively new and not well understood, introduction
response to the request. Thus end-to-end response of ETE RT facility presents a significant technical
time represents a user orientation in performance challenge. For the importance of end-to-end response
management as contrasted with resource oriented time from both technical and business perspective see
performance metrics such as CPU utilization and the [5] and [7].
number of I/Os per second. This paper discusses the introduction of end-to-
ETE RT bridges the business and technical end performance management capability in
worlds. On one hand, the end-to-end response time of client/server systems in a corporation. It also
a transaction is associated with the business discusses the use of this functionality for ongoing
transaction performed by the application. On the corporate business needs. As will be discussed later,
other hand, end-to-end response time of a user the impact of ETE RT facility use on business is very
transaction is also related to the resources consumed significant.
by the transaction. Thus, ETE RT serves a very This paper first describes the customer
important link between the business understanding of environment and his requirements (Section 2). Here a
computer use and the technical understanding of the review is done of the network configuration, the
system [4]. computer platforms, the software systems and the
ETE RT is available and is used today to some application that was instrumented first. Figure 1 in this
degree in a mainframe environment (in CICS/VTAM section depicts the configuration of the client/server
[2]). It is just emerging in a client/server environment. application and also singles out specific clients and
ETE RT measurement is one of the key measures of servers that are referenced as examples in
service level provided by the computing equipment. subsequent sections.
In many companies ETE RT is tracked at the This section is followed by a description of the
executive level (especially in the case of CICS). This instrumentation introduced into the client/server
is how user satisfaction is measured. When application (Section 3). We describe the
computing equipment is upgraded, the improvement organizational process we followed to instrument the
in ETE RT serves as one indication of the application, the technology, the implementation and
effectiveness of the upgrade. Thus ETE RT is a key present sample data produced by the ETE RT
measure. The client/server environment in general is measurement facility. Issues of control of data
more end user oriented. Also, the equipment in this
C/S End-to-End Response Time: Customer Experience - CMG96
collection, data repository and the reporting process
are mentioned, too. 2.2. Customer Environment and
Section 4 deals with the customer use of the ETE Requirements
RT function. Here we cover issues of methodology This Fortune 500 company uses mainframe
and also business topics related to the use of this equipment (in particular the CICS environment) for its
functionality. The use of this function has undergone IS needs. This environment is well understood and
a few stages. Initial stress was on verification and well managed. In addition, the company is in the
testing of the function. This was followed by process of rolling out new client/server applications for
establishment of base measurements. An attempt production use.
was made at defining Service Level Agreement.
Measurements of response time of individual query One of the well established processes in the
types vs number of rows returned and response time mainframe environment is the tracking of response
vs time of day are shown here (pre-production tests). time. The IS organization set a goal of achieving 3
Next we describe the initial production measurements. second response time for 95% of the CICS
Those measurements show the affect of geographical transactions. A report summarizing the actual
distance on response time and the of extent of usage response time is periodically prepared using
of the client/server system by the various divisions of mainframe measurement facilities. The CICS
the corporation. We finish this section by describing a response time is routinely tracked by management. IS
specific ETE RT problem and its resolution that management wanted to see similar capability
involved use of the ETE RT facility. Here we describe developed for the client/server env ironment.
the problem, steps undertaken at identifying it, we The first application just coming into production,
observe the unique client/server aspects and the Supplier Metrics, had an NT server running Oracle
expected resolution of the problem. We also show data base and a few application servers (currently 10)
response time behavior in this production serving an expected population of about 150 users
environment. (currently 100). This is a decision support application
Section 5 deals with the upcoming developments and it is used by purchasing managers to issue
in the use of this facility in the corporation. And we queries in the process of their work. The data on the
finish with the summary and conclusions in Section 6. Oracle data base contains purchasing information,
This Section deals with what we have learned. Those quality information, purchase orders (POs) and
observations we collected into a group of business supplier data. This information is downloaded from a
related observations and technical related mainframe at the beginning of every month. The
observations. The ETE RT facility is a natural, simple Supplier Metrics application was developed with
to use facility for a non technical user. And although it Powerbuilder. Following (Figure 1) is a diagram
has very important technical information, its business depicting the Supplier Metrics configuration.
use requires little technical skills. The section is Note: in the context of this paper an application
concluded with a mention of remaining technical server is a file server where Powerbuilder modules
challenges in the area of ETE performance (code) are stored. These modules are loaded to the
management. user workstations. In general, user workstation get
their code from those application servers.

C/S End-to-End Response Time: Customer Experience - CMG96

Figure 1. Supplier Metrics Client Server Config uration

3. Instrumentation 3.1. Design and Development of

At about the time when Supplier Metrics Instrumentation
application was going into production, executive Supplier Metrics system is used occasionally by
management was approached by the research the corporate purchasing managers. Whenever there
organization of a major computer manufacturer that is a need to do research as to which supplier to
wanted to experiment with a new technology that can choose. Although this is different from the CICS
measure end-to-end response time. An ad hoc group environment (where users continually use the system),
from 5 different organizations in the company plus management felt that response time information
employees of the computer manufacturer was formed. requirements are similar. The initial discussion
In two meetings (with the manufacturer’s people on revealed that there are 272 different transaction types
the telephone), a design was formulated to instrument in this application. Alarm was expressed on the part
Supplier Metrics application. The design called for the of some of the people present about the effort to
introduction of sensors (pieces of code) in the client instrument all those transactions. However, it was
application to record the clock time in the beginning suggested to check whether most or maybe even all
and the end of every transaction (in the case of this transactions share common code at the beginning and
application a transaction is a query). This will give the at the end of a transaction. The owner of the code
user response time (end-to-end response time) of the confirmed that all 272 transactions share one piece of
transaction. Some important issues came up in this code at the beginning and at the end. Indeed during
discussions. the implementation it was found that all transactions
start at the same piece of code and the transactions
end at one of two different locations in the code. Thus
instrumentation required sensors in just three locations

C/S End-to-End Response Time: Customer Experience - CMG96

in the code. Two sensors were developed. One 1. the employee user id,
sensor to mark the start of the transaction and one 2. time stamp (date and time of day),
sensor to mark the end of the transaction (the second
3. the name of the application (e.g. Metrics),
sensor was placed in two different code locations).
4. IP address of the workstation,
Right from the beginning of the design activity,
management involved the department that maintains 5. transaction start time,
code that is common throughout the company. The 6. transaction end time,
idea was to reuse those two sensors in other 7. transaction elapsed time (in milliseconds),
applications of the same class; i.e.
Windows/Windows NT/Oracle/Powerbuilder. This was 8. the number of relational table rows retrieved by
done because there are other applications in this class the transaction
that are in various stages of development that could 9. the type of the report built by the Powerbuilder
use those two sensors. After implementation the code application.
of the sensors became a common property of all For a sample of data collected by this facility see
applications in this class (see more on this in the the figure below. Each row in the figure represents
Summary section). one transaction.
Every invocation of a transaction resulted in one
record. The record contained:

Figure 2. Sample of End-to-End Performance Data

The key information is in the client column that introduced. The employee ids of those users whose
identifies the user, the date and time columns, the RT transactions are to be measured were included in this
column that gives ETE RT, the Query Type column file.
and the Rows column (indicates the number of rows After some experimentation it was decided to
returned by the query). store the ETE RT records in a relational (Oracle) table
There was a design question of controlling the in the NT server. Thus every transaction resulted in a
collection, storing and processing this data. Thus the record added to this table. As for reporting,
designers/developers of the sensors had to contend management felt that client/server response time
with systems management issues, in addition to the reporting should follow the pattern of mainframe
issues of actually gathering the data. To determine response time reporting.
which users are monitored, a control file was

C/S End-to-End Response Time: Customer Experience - CMG96

 Management and technical people decided to try to
4. Customer Use of the Function extend the mainframe response time requirement to
The use of ETE RT functionality, once it became the client/server environment. A tentative service
available, has undergone a few stages. Initial stress level requirement was formulated that a client/server
was on verification and testing of the functionality. response time should not exceed 3 seconds for a
The second stage dealt with establishing base reasonable sized query. A reasonable size query was
measurements. The third stage was oriented more defined as one that does not exceed 100 rows (of a
towards production. It included analysis and relational table) returned as a result of the query. This
correction of performance problems and some was an arbitrary and simple criteria but it was a fairly
management related measurements. The current, reasonable one.
fourth, stage is fully production oriented and during The manager of the Supplier Metrics system
this stage requirements were formulated for additional arranged for measurements of most of the available
functionality in ETE RT facility. We shall examine queries on this system. It was arranged that those
those stages and bring some real life stories. queries will have less than 100 rows of data returned.
Some query types whose response time exceeded 3
4.1. Verification and Testing second were given back to the developers to see
whether their performance can be improved. The
The code of the sensors was developed in a few measurements were on client workstations in close
hours. Unit testing and changes made this proximity to the data base server and the application
development undertaking about one week long. server to reduce the network impact. Queries that did
Clearly this activity was not very hard. The not satisfy the requirements were analyzed by the
instrumentation was done in Powerbuilder modules. development team and where possible were modified
Most of the work was in developing the approach and to comply with the base requirement. There was no
required familiarity with the Powerbuilder application systematic tracking of the queries measured, queries
code. This work was done by a contract programmer satisfying the requirements, those that satisfied the
and the manager of Supplier Metrics client/server requirement after rework, etc. We observed that the
system directing him. work with this ETE data for performance analysis was
done by business people rather than people trained in
4.2. Establishing Base Measurements performance and capacity planning.
As mentioned before, the response time Following are a few charts summarizing the
measurement requirement in client/server measurements that were done after development of
environment was based on the mainframe precedent. the system (before production).
R e sp o n se T im e b y T im e o f D a y
40000

35000

30000
Response Time (milliseconds)

25000

20000

15000

10000

5000

0
7:00 8:00 9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00
Event Measu remen t T im e o f D ay
P er f RT
P erf RT Tr end (P oly 4)

Figure 3. Response Time of "Perf" Query by Time of day

C/S End-to-End Response Time: Customer Experience - CMG96

Note that the response time is higher between 8:30 Although this data is not necessarily representative of
AM and 11 AM and between 3:30 PM and 5:30 PM. a typical response time of this application, it
This is fairly typical. This information is important for demonstrates the possibilities of the use of ETE
operational and planning purposes of the company. measurement facility.

Response Time by Rows Returned

40000

35000

30000
Response Time (milliseconds)

25000

20000

15000

10000

5000

0
0 5 10 15 20 25 30 35 40
Number of Rows
Perf Polis
Linear (Perf) Linear (Polis)

Figure 4. Response Time of Queries by Number of Rows Returned

This graph shows that response time increases exhibited 3-4 minutes response time. A controlled
with the number of rows and that "Polis" query is more experiment was conducted. Three different queries
sensitive to the increase in the number of rows than is were issued at each of three client workstations. All
the "Perf" query ("Polis" response time increases queries returned under 100 rows of information. One
faster). Both of the preceding graphs show that workstation was located as close as possible from the
important information about a client/server application data base and the application servers. Another
can be gained from ETE RT data. workstation was located about 40 miles from the
servers and was connected to the servers by means of
4.3. Initial Production Measurements a T3 line. A third workstation was in North Carolina
and the connection was through a T1 line. The closest
One aspect in those measurements was workstation had a response times of under 3 seconds.
determining whether geographical distance makes a The workstation at the end of T3 ran the queries in
difference as far as response time is concerned. under 3 seconds (although a fraction of a second
slower than the closest workstation). The workstations
4.3.1. Affect of Geographical Distance in North Carolina exhibited 3-4 minutes response time.
The background to this is the following. About 10 It seemed that the size of the data returned and the
of the client workstations were installed in North speed of the line to the data base could not have been
Carolina (see Figure 1). The data base server as well the reason for such a drastic change in response time.
as the application server were located in Middletown, Since there was no Application Server in North
Pennsylvania. The workstations in North Carolina Carolina a solution was attempted by moving an

C/S End-to-End Response Time: Customer Experience - CMG96

application server there. Indeed the response time Application Server. Once it was made local, response
drastically improved. The reason for this is the time time did improved.
required to load the code to execute in a client When the application server is local, distance to the
machine. Code is loaded by segments (see [1]). Data Base Server is a factor. Especially if the
When the code is loaded from a local (LAN attached) connection to the remote location is slow. Following is
application server the loading is fairly fast (LAN speed a chart depicting response time of a client that is local
is 10 Mbits/sec). However, when the application (to the Data Base Server) vs response time of a
server is not local (as was the case in North Carolina) remote client (Philadelphia, Pennsylvania) (see Figure
but is rather connected at the end of a line, loading of 1). The two users are COM63441 (local) and
code took minutes instead of seconds. So the reason COM97443 (remote) and the query measured is
for this problem was speed of connection to the "Perf".

Response Time By Rows Returned

18000

16000

14000
Response Time (milliseconds)

12000

10000

8000

6000

4000

2000

0
0 5 10 15 20 25 30 35 40
Number of Rows
COM63441(Perf) COM97443(Perf)

Linear (COM63441(Perf)) Linear (COM97443(Perf))

Figure 5. Response Time of a Local User vs a Remote User

This graph shows that response time of the local averaged 100 queries per month, with the heaviest
user is smaller that the response time of the remote use by one division topping 600 queries per month.
user for the "Perf" query. Response time of both An analysis by the manager of the client/server
users increases with the number of rows. system indicated that more queries are issued at the
beginning of the month (when the data is fresh) with
4.3.2. Extent of Usage queries tapering off towards the end of the month.
Since the manager knows how the users use the
As soon as the system was operational, management system, she believes that some of the usage is due to
wanted to know how widely used it is. This was users playing with the system, rather than actual
motivated by a few factors. Those had to do with production. This is another aspect of systems
justifying the investment, tracking the biggest users, management we noticed in this client/server system:
tracking pattern of use, etc. A monthly report it is done by a person familiar with the business of the
revealed a low usage, perhaps not surprising in view company rather than with the technology. The
of the fact that the system was just put in production. measurement technology for this manager is just an
Of the 13 divisions of the corporation, three divisions
did not use the system at all. The other ten divisions
C/S End-to-End Response Time: Customer Experience - CMG96
aid rather than the major source for her information
about what goes on in the system. 4.4. Production Measurements

4.4.1. Description
A typical incident is the following. A user
complained about a response time (of a "Perf" report)
being higher than the norm he is used to. The
manager of Supplier Metrics system turned on the
measurement facility for this user. The
measurements showed that the response time was
high and it was significantly higher than the response
time experienced by the manager when she tried to
issue the same query from her workstation. The
manager’s workstation was connected to an Ethernet
segment that is further from the data base server than
the user that reported the problem. The manager
suspected that the response time problem may be
shared by other users in the hub where the
complaining user is connected. She turned on the
measurement for a few users in the hub and found all
of them had a response time problem. Some
experienced a response time as high as 31 seconds
for a report involving one row of data returned. It
seemed that the problem had to do with this particular
hub. To get a resource oriented perspective the
manager requested measurement with the Sniffer (a
LAN traffic measurement tool).
The response time problem was reported
originally at 4 PM. The measurements on the
workstation of the complaining user, the analysis of
his data, the measurements for the workstations of the
other users on the hub, the analysis of their data and
the activation of the Sniffer on the hub occurred all on
the day when the problem was reported. The
manager of the Supplier Metrics system felt she
needed to act fast because she did not want her
system to get bad publicity. She felt that the response
time measurement facility gave her the functionality
and that this functionality could be activated fast.
Note: To activate the measurements the manager
needs to specify the employee id (COM#) in a control
file and the user needs to log off and to log back on.
4.4.2. Observations
Some of the observations about this incident are
of interest.
1. The detection of the problem was done manually;
i.e. a user complained. An existence of a
measurement tool, such as the one described in
the paper, may allow in the future detection by a
performance management application.

C/S End-to-End Response Time: Customer Experience - CMG96

2. Verification of the problem was done through our
measurement facility. The manager turned on the
measurement facility for this user, obtained
measurements and verified the existence of a
problem independently (without relying on the
subjective impression of a human). This is a
relatively new capability in a production
client/server environment. This functionality
exists in CICS/VTAM environment (to some
degree), but it is not well established in the
client/server environment. Since response time
measurement are not generally available today,
the very existence of a response time problem
and certainly its extent are very frequently in
dispute between the user of the system and the
owner of the system. Thus management usually
has difficulty determining whether to spend
resources on upgrading the system and once the
upgrade is undertaken it is impossible to measure
the improvement in response time. The
measurement facility described in this paper
solves this difficulty.
3. The activation of measurements is relatively fast
and allows measurement and analysis within a few
minutes.
4. Although operating the facility does not require
specialized skill, knowledge of LAN configuration
was necessary (i.e. hub, etc.) for analysis.

4.4.3. Follow on
Measurements with the Sniffer, as well as
additional response time measurements indicate the
following condition. All the workstations on the local
segment tend to get long response time. Whenever
workstations are requesting service within the local
segment (Supplier Metrics is not local) the response
time is good. The conclusion is that the activity
generated by the people and devices on this segment
of the LAN is too much for the router (that is
connected to this segment) to handle. A LAN
hardware solution will probably be undertaken after
additional measurements. .*(e.g. placing the users on
2 separate segments).

4.4.4 Response Time Measurements in

Production
Following is a chart showing response time vs
number of rows returned. These measurements were
taken during production operation of the system. The
chart is intended to demonstrate use of the response
time data (rather than measurement of a typical
workload).

C/S End-to-End Response Time: Customer Experience - CMG96

 Response Time by Rows Returned
40000

35000
Response Time (milliseconds)

30000

25000

20000

15000

10000

5000

0
0 5 10 15 20 25 30 35 40
Number of Rows
Perf Graph
Linear (Perf) Linear (Graph)

Figure 6. Response Time of Queries vs Rows Returned

These production measurements show that The manager of Supplier Metrics system
response time increases with the number of rows (we complained that in cases where response time is long,
have seen this already in pre-production it is hard to determine whether the problem is in the
measurements). We also see that "Graph" query is data base or in the network (her expression was "we
more sensitive to the increase in the number of rows are blind without this data"). For this purpose one
than the "Perf" query. developer was assigned to investigate the possibility
of developing sensors in the Oracle Data Base to
5. Upcoming Developments measure the time spent in the data base. The
requirement to measure the components of respose
The use of the response time measurement time is fairly typical once the total response time is
facility, lead to additional requirements and uses of available.
this capability. Here we will list a few of those.
The company is planning to start operation of a 6. Summary and Conclusions
new client/server system. This one is planned for
about 3000 workstations and 9 large data base The work described in this paper is the first
servers. The application for this system was methodical application of the ETE RT technology we
developed using Powerbuilder as well. have done in a production corporate environment.
This work is part of an ongoing research in the
To allow response time measurements, the
methodology and technology of ETE RT.
sensors from Supplier Metrics will be used. For use
on this system, the sensors will be re-implemented in Throughout our work, both conceptual and
object oriented technology based on Microsoft practical, we gained an appreciation of the importance
distributed OLE. Once operational on the new of user-oriented measurements. One motivating
system, the sensors on the Supplier Metrics system example is described in the Summary Section of [4].
will be replaced with the new OLE conforming The ability to have a metric is an important
sensors. management requirement. It is important both to

C/S End-to-End Response Time: Customer Experience - CMG96

establish the current reality and to measure reasonable time. This response time can be
improvements once changes are made. measured and tracked. It allow establishment of a
As described in [4], the ETE RT facility is a norm and a focus on the exceptions to the norm.
performance management tool but it is also a 2. In addition to supporting day to day operation of
business performance management tool. In this it the system, we noticed that network and computer
differs from existing performance management tools upgrades are many times driven by ETE RT
that deal with more technical measurements such as measurements (see Section 4.3.1). Also, software
CPU utilization, etc. and are used by technical changes that are necessary for performance were
people. The ETE RT functionality is fairly readily initiated as a result of ETE RT data (see Section
usable by an executive or a business person. To 4.2). Thus we see that ETE RT facility has a
separate the two aspects of ETE RT facility we shall strong influence on the expenditure of hardware
group our observations separately first from a and programming resources (which must mean
technical and then from the business (management) that management decision was involved).
perspective. 3. The facility is easy to operate and use for
analysis. The terminology is identical to that used
From a technical perspective we noticed that: by the end users of the system. For this reason
many employees relate to the measurements
1. As was the case in prior experiences, provided by this facility, adopt it and agree to be
instrumentation was relatively easy to implement. guided by its findings. This is quite different from
Design was harder and required cross disciplinary the resource oriented measurement tools where
activity. Executive management, developers of the terminology is very technical.
the application, the business manager of the 4. The use of ETE RT seems to require limited skill for
client/server system, manager of the corporate both measurement and analysis. It is user friendly.
software library and others had to be involved. 5. In addition to measuring ETE RT, the facility can
2. Analysis of data requires good understanding of be used for measuring throughput (Section 4.3.2).
the configuration of the client/server system and This capability, too, relates to the corporate
the business use of the client/server system. The management needs.
need for configuration information is a recurring 6. The importance of the ETE RT facility is
theme in our work on performance, especially in underscored by the fact that the sensor code
client/server systems (see [3]). became a corporate resource from the very
3. Although knowledge of configuration and business beginning. The code was placed with the
is needed, it seems that not much more was department in charge of shared corporate
required. At least for the level of activity software.
described in this paper (see Section 4.4), analysis 7. Another observation is that the ETE RT facility
did not seem to require technical skill. was developed as a logical extension of the
4. This ETE RT facility was effective for measuring a corporate mainframe service level tracking. From
geographically distributed client/server system. the executive perspective this is just a
The examples in Section 4.3.1 and Figure 5 both continuation of an existing procedure applied to
demonstrate that this facility is not limited to a different equipment.
LAN. This is an important capability. 8. This facility is a powerful tool. It provides very
important information for decision makers. The
From a business perspective we had the following ETE RT facility provides high visibility for
observations: everybody involved.

1. Management is interested in ETE RT information Although highly productive the facility described here has
on a day to day basis. What is measured affects limitations. For one it is limited to a simple client/server
daily business operation and is of direct business system. More complex system have additional
consequence. Thus we find discussions based on complicating issues to deal with. Larger systems have
ETE RT data at management meetings, meetings’ tens of thousands of clients. There are cases of three or
participants share their perspective on the data even four levels of hierarchy. Those complex systems
and discussion sometimes centers on the validity have multiple types of servers and server requesting
of the data. ETE RT is clearly important service from other servers. Then there are internet
information for management. This tells systems. Beyond this is the subject of breaking the total
management whether the system delivers the response time (ETE RT) to its components or
information the purchase managers need within a decomposition. Decomposition is harder to implement
than ETE RT. Especially daunting is the task of

C/S End-to-End Response Time: Customer Experience - CMG96

decomposition in complex systems. Dealing with those
Acknowledgments:
additional issues is the subject of our future work.
I am very grateful to Richard Nevins, an executive
with the Fortune 500 company mentioned in the
paper, for his business, organizational and technical
guidance and to the employees of the company who
were so helpful. I also would like to acknowledge the
design support and organizational guidance offered by
Wally Schwane.

C/S End-to-End Response Time: Customer Experience - CMG96

7. References
1. Microsoft Developer Network Development
Library, April 1996.
2. IBM Corporation, CICS/ESA Performance Guide
for Release 4.1, 1996. SC33-1183-00
3. Mark M. Maccabee and Seraphin S. Calo.
Configuration Management in Enterprise Wide
Systems. Computer Measurement Group
Conference Proceedings, December 1994.
4. Mark M. Maccabee, Anna Long, and Walter
Schwane. Distributed Client Server End-to-End
Response Time: Instrumentation, Methodology
and Experience. Computer Measurement Group
Conference Proceedings, December 1995.
5. Daniel A. Menasce, Virgilio A. F. Almeida and
Larry W. Dowdy. Capacity Planning and
Performance Modeling. Prentice Hall, 1994.
6. Richard S. Ralston. In Search of End-to-End
Response Time. Computer Measurement Group
Conference Proceedings, December 1995.
7. Paul E. Renaud. Introduction to Client/Server
Systems. Wiley, 1993.

C/S End-to-End Response Time: Customer Experience - CMG96