Chapter 5

A STEP-BY-STEP
APPROACH TO CAPACITY
PLANNING
IN CLIENT/SERVER
SYSTEMS

5.1 Introduction
Planning the capacity of a C/S system requires that a series of steps be followed in a
systematic way. This chapter starts by providing a clear denition of what adequate
capacity means. It then presents a methodology that leads the capacity planner, in
a step-by-step fashion, through the process of determining the most cost-eective
system conguration and networking topology. Investment and personnel plans
follow as a consequence. The main steps of the methodology are: understanding
the environment, workload characterization, workload model validation and calibra-
tion, performance model development, performance model validation and calibra-
tion, workload forecasting, performance prediction, cost model development, cost
prediction, and cost/performance analysis.
The methodology presented here requires the use of three models: a workload
model, a performance model, and a cost model. The workload model captures the
resource demands and workload intensity characteristics of the load brought to the
system by the dierent types of transactions and requests. The performance model
is used to predict response times, utilizations, and throughputs, as a function of the
system description and workload parameters. The cost model accounts for software,
hardware, telecommunications, and support expenditures.
This chapter draws in part on material presented in [7] and Chap. 2 of [8]. Vari-
ous steps of the methodology are discussed in further detail in subsequent chapters.

100
Section 5.2. Adequate Capacity 101
5.2 Adequate Capacity
Many organizations invest millions of dollars to build client/server computing envi-
ronments and many millions more to maintain and update the environment. In most
cases, the overall capacity of the environment is unknown and capacity planning
and procurement is done without a dened methodology. To complicate matters,
the notion of what is adequate capacity is not well understood in many cases.
Figure 5.1 illustrates the three main elements used to dene adequate capacity
of a C/S system:
 Service-level agreements (SLAs). Adequate capacity has to be provided so
that acceptable or desirable values for performance metrics such as response
time or throughput can be achieved. Examples of SLAs include: \response
times for trivial database queries should not exceed two seconds," \response
times for database searches performed through the Web front-end should not
exceed three seconds," \the NFS server should be able to support at least
10,000 NFS I/O operations per second with response times not exceeding 0.1
sec." The values of SLAs are specic to each organization and are determined
by both management and users. Even when SLAs are not formally dened,
it is possible to determine a level of acceptable service when users start to
complain about poor performance.
 Specied technologies and standards . Providing adequate capacity to meet
service-level agreements can be done in many ways by using servers and op-
erating systems of various types and many dierent networking topologies.
For example, it is possible for a Windows NT-based le server running on a
PC-based machine to deliver the same performance as a Unix-based le server
running on a RISC machine. Some organizations may prefer to use one ver-
sus the other for reasons that are not directly related to performance (e.g.,
ease of system administration, familiarity with the system, and number and
quality of possible vendors for the underlying hardware). Users and manage-
ment may also choose to adopt certain standards for network protocols (e.g.,
TCP/IP) and middleware, further restricting the set of solutions that can be
used. Thus, users and management may specify that adequate capacity be
provided with certain specied technologies and standards for reasons other
than performance.
 Cost constraints . The problem of providing adequate capacity to meet SLAs
would be somewhat easier to solve if one had unlimited monetary resources.
Budget constraints are determined by management and limit the space of
possible solutions. Expenditures for C/S systems include startup costs and
operating costs for a dened period. Startup costs include purchase expen-
ditures for hardware and software, installation costs, personnel costs, and
initial training. Operating costs include hardware and software maintenance,
telecommunications costs, and personnel costs required to maintain the sys-
tem. Amortization costs may be included if they are incurred.
 A Step-by-Step Approach to Capacity Planning
102 in Client/Server Systems Chapter 5

Service e.g., response time < 2 sec

Level
Agreements

Users
e.g., NT servers
Specified
TCP/IP Adequate
Technologies
Capacity
and Standards

Management

Cost
Constraints e.g., startup cost < $5.5 million
maintenance cost < $1.6 million/yr

Figure 5.1. Denition of adequate capacity.

We say then that a C/S system has adequate capacity if the service-level agree-
ments are continuously met for a specied technology and standards, and if the
services are provided within cost constraints.

5.3 A Methodology for Capacity Planning in C/S Environments

Figure 5.2 illustrates the various steps of a capacity planning methodology for C/S
systems. While these steps are essentially the same as those for capacity planning
studies of mainframe-based environments, their implementation in a C/S environ-
ment is much more complex due to the heterogeneity of hardware and software
components involved.
The capacity planning methodology relies on three models: a workload model,
a performance model, and a cost model. The workload model captures the resource
demands and workload intensity characteristics for each component of a global work-
load within a representative time frame. The performance model is used to predict
the performance of a C/S system as a function of the system description and work-
load parameters. The outputs of the performance model include response times,
throughputs, utilizations of various system resources, and queue lengths. These
performance metrics are matched against the service-level agreements to determine
if the capacity of the system is adequate. The cost model accounts for software,
hardware, telecommunications, and support expenditures.
The following sections discuss in greater detail what is involved in each of the
steps of the methodology depicted in Fig. 5.2. We will use the C/S of Fig. 5.3 to
illustrate all phases of the capacity planning methodology.
Section 5.4. Understanding the Environment 103

Understanding the Environment

Workload Characterization

Development of
Workload Model Validation Workload
a Cost Model
& Calibration
Model

Workload Forecasting
Cost Model

Performance Model
Development

Cost Prediction Performance

Performance Model Validation
& Calibration Model

Performance Prediction

Cost/Performance Analysis

Configuration Plan Investment Plan Personnel Plan

Figure 5.2. A methodology for capacity planning.

5.4 Understanding the Environment

The initial phase of the methodology consists of learning what kind of hardware
(clients and servers), software (operating systems, middleware, and applications),
network connectivity, and network protocols, are present in the environment. It
also involves the identication of peak usage periods, management structures, and
service-level agreements. This information is gathered by various means including
user group meetings, audits, questionnaires, help desk records, planning documents,
interviews, and other information-gathering techniques [7].
Table 5.1 summarizes the main elements of a C/S system that must be cata-
logued and understood before the remaining steps of the methodology can be taken.
An example of the outcome of the Understanding the Environment step for the
C/S of Fig. 5.3 would be as follows.
Clients and servers. The network consists of four LAN segments (three 10
Mbps Ethernets and one 16 Mbps Token Ring) interconnected through a 100 Mbps
FDDI ring. LAN 3 is connected to the Internet. LAN 1 has a Windows NT-based
le server and 120 Windows NT-based PC clients. LAN 2 has a RISC-type Unix
le server and 50 Unix workstations. This le server uses a storage box with several
 A Step-by-Step Approach to Capacity Planning
104 in Client/Server Systems Chapter 5

file server
50 Unix workstations
10 Mbps
Ethernet ftp proxy server
LAN 2
LAN 3 telnet proxy server
Web proxy server
e-mail server
file
server
FDDI ring 100 Windows NT clients
100 Mbps
120 LAN 5
Windows NT Internet
clients LAN 1
10 Mbps
LAN 4 Ethernet
16 Mbps
Token
Ring 100 Windows NT
clients
file SQL
server server

Figure 5.3. Example C/S system for capacity planning methodology.

RAID-5 disks and a capacity of 512 Gbytes. LAN 3 runs an ftp proxy server, a
telnet proxy server, a Web proxy server, and the e-mail server on a Windows NT
server-based dual processor high-end PC-based machine. This LAN supports 100
Windows NT clients. Finally, LAN 4 has a Windows NT-based le server and
an SQL database server running Oracle to support enterprise-wide mission-critical
applications. This LAN has 100 Windows NT-based clients. BEA's Tuxedo [1] is
used as a Transaction Processing (TP) Monitor to support client/server transaction
management.
Applications. Workstations on LAN 2 are mostly used by researchers of the
R&D department engaged in running computer simulations of molecular biology
experiments. These researchers store all their les in the le server in LAN 2. They
use e-mail, ftp, telnet, and Web services from the proxy server on LAN 3. Clients
on LANs 1, 3, and 4 split their time between running oce automation applica-
tions (e.g., word processing, spreadsheets, and presentation preparation packages)
and running various types of client/server transactions to support sales, marketing,
personnel, accounting, and nancial activities. These C/S transactions use a TP
monitor and the SQL server on LAN 4. All users in LANs 1, 3, and 4 read e-mail
and access the Web through the proxy server on LAN 3. The company's employees
go through Web-based training courses hosted at the server on LAN 3. Most of the
accesses to these applications come from clients on LANs 1, 3, and 4.
Network connectivity and protocols. The network connectivity map is
Section 5.4. Understanding the Environment 105

Table 5.1. Elements in Understanding the Environment

Element Description
Client platform Quantity and type
Server platform Quantity, type, conguration, and function
Middleware Type (e.g., TP monitors)
DBMS Type
Application Main types of applications
Network connectivity Network connectivity diagram showing all LANs,
WANs, network technologies, routers, servers,
and number of clients per LAN segment
Network protocols List of network protocols being routed
Service-level agreements Existing SLAs per application. When
formal SLAs are absent, industry standards
can be used (see [4])
LAN management LAN management support structure, size,
and support expertise, and responsiveness to users
Procurement procedures Elements of the procurement process,
justication mechanisms for acquisitions,
expenditure limits, authorization mechanisms,
and duration of the procurement cycle

given in Fig. 5.3. The Internet and transport protocols used throughout all networks
is TCP/IP.
Service-level agreements. There are no formal SLAs established, but users
start to complain if response times exceed 2 sec for trivial C/S transactions and 5
sec for the more complex transactions. Response times at e-mail and Web services
has not been a problem.
LAN management and support. Each of the four user LANs (LANs 1{4)
have a dedicated team of LAN and system administrators. The number of system
administrators for each of these LANs is 6, 3, 5, and 6, respectively. There is also a
Database Administrator (DBA) for the database managed by the SQL server and
three network specialists that constantly monitor the performance on the FDDI ring
and are responsible for overall network management functions such as assigning IP
addresses to subnetworks, managing routing tables, maintaining network security,
and verifying the connection to the Internet.
Procurement procedures. As an example, procurement decisions could be
made by an Information Technology Committee, headed by the Chief Information
Ocer (CIO) of the company and composed of four user representatives and four
system administrators (one from each LAN), which reviews applications for hard-
ware and software upgrades. Decisions are made based on budget availability and
on how well the requests are justied. The average procurement cycle for items
 A Step-by-Step Approach to Capacity Planning
106 in Client/Server Systems Chapter 5

over $5,000 is 2 mo. Expenditures below $5,000 can be made using a much faster
procedure that takes two business days on the average.

5.5 Workload Characterization

Workload characterization is the process of precisely describing the systems's global
workload in terms of its main components. Each workload component is further de-
composed into basic components, as indicated in Fig. 5.4, which also shows specic
examples of workload components and basic components. The basic components
are then characterized by workload intensity (e.g., transaction arrival rates) and
service demand parameters at each resource.
The parameters for a basic component are seldom directly obtained from mea-
surements. In most cases, they must be derived from other parameters that are
measured directly. Table 5.2 shows an example of three basic components, along
with examples of parameters that can be measured for each. The last column indi-
cates the type of basic component parameter|workload intensity (WI) or service
demand (SD). Values must be obtained or estimated for these parameters, prefer-
ably through measurements with performance monitors and accounting systems.
Measurements must be made during peak workload periods and for an appropriate
monitoring interval (e.g., 1 hour). For example, consider the \Mail Processing"
basic component. Data would be collected relative to all messages sent during a 1
hour monitoring interval. Assume that 500 messages were sent during this interval.
Measurements are obtained for the message size, mail server CPU time, and server
I/O time for each of the 500 messages. The average arrival rate of send mail requests
is equal to the number of messages sent (500) divided by the measurement interval
(3,600 sec), i.e., 500/3,600 = 0.14 messages sent per second. Similar measurements
must be obtained for all basic components.

Global Workload

workload component 1 ... workload component n

(e.g., C/S transactions) (e.g., Web access)

... ...
basic basic basic basic
component 1.1 component 1.m component n.1 component n.k
(e.g., personnel (e.g., sales (e.g., corporate (e.g., use of search
transactions) transactions) training) engines)

Figure 5.4. Workload characterization process.

Section 5.5. Workload Characterization 107

Table 5.2. Example of Basic Component Parameters and Types

(WI = Workload Intensity; SD = Service Demand)
Basic Component and Parameters Parameter Type
Sales transaction
Number of transactions submitted per client WI
Number of clients WI
Total number of IOs to the Sales DB SD
CPU utilization at the DB server SD
Average message size sent/received by the DB server SD
Web-based training
Average number of training sessions/day WI
Average size of image les retrieved SD
Average size of http documents retrieved SD
Average number of image les retrieved/session SD
Average number of documents retrieved/session SD
Average CPU utilization of the httpd server SD
Mail processing
Number of messages received per day per client WI
Number of messages sent per day per client WI
Number of clients WI
Average message size SD
CPU utilization of the mail daemon SD

5.5.1 Breaking Down the Global Workload

When workload intensity is high, large collections of workload measures can be
obtained. Dealing with such collections is seldom practical, especially if workload
characterization results are to be used for performance prediction through analytic
models [8]. One should substitute the collection of measured values of all basic
components by a more compact representation|one per basic component. This
representation is called a workload model |the end product of the workload char-
acterization process.
Consider a C/S-based application that provides access to the corporate database,
and assume that data collected during a peak period of 1 hour provides the CPU
time and number of I/Os for each of the 20,000 transactions executed in that period.
Some transactions are fairly simple and use very little CPU and I/O, whereas other
more complex ones may require more CPU and substantially more I/O. Figure 5.5
shows a graph depicting points of the type (number of I/Os, CPU time) for all
transactions executed in the measurement interval. The picture shows three natural
groupings of the points in the two-dimensional space shown in the graph. Each
group is called a cluster and has a centroid |the larger circles in the gure|dened
 A Step-by-Step Approach to Capacity Planning
108 in Client/Server Systems Chapter 5

200

180 cluster 2
160

140
CPU Time (msec)

120

100
average over
80 all points

60
cluster 1
40
cluster 3
20

0
0 5 10 15 20 25 30 35 40 45
No. I/Os

Figure 5.5. Space for workload characterization (no. of I/Os, CPU time).

as the point whose coordinates are the average among all points in the cluster. The
\distance" between any point and the centroid of its cluster is the shortest distance
between the point and the centroid of all clusters. The coordinates of the centroids
of clusters 1, 2, and 3, are (4.5, 19), (38, 171), and (39, 22), respectively. A more
compact representation of the resource consumption of the 20,000 transactions is
given by the coordinates of centroids 1, 2, and 3. For instance, transactions of class
1 perform, on the average, 4.5 I/Os and spend 19 msec of CPU time during their
execution.
The graph in Fig. 5.5 also shows the point whose coordinates, (28, 68), are the
average number of I/Os and the average CPU time over all points. It is clear that if
we were to represent all the points by this single point|the single cluster case|we
would obtain a much less meaningful representation of the global workload than the
one provided by the three clusters. Thus, the number of clusters chosen to represent
the workload impacts the accuracy of the workload model.
Clustering algorithms can be used to compute an optimal number of basic com-
ponents of a workload model, and the parameter values that represent each com-
ponent. A discussion of clustering algorithms and their use in workload characteri-
zation is presented in Chap. 6.
Section 5.5. Workload Characterization 109
5.5.2 Data Collection Issues
In ideal situations, performance monitors and accounting systems are used to de-
termine the parameter values for each basic component. In reality, the tool base
required for integrated network and server data collection may not be available to
the system administrators, or they may not have enough time to deploy and use a
complete suite of monitoring tools. This is a chronic problem for many organiza-
tions. The problem is compounded by the fact that most monitoring tools provide
aggregate measures at the resource levels (e.g., total number of packets transmitted
on a LAN segment or total server CPU utilization). These measurements must be
apportioned to the basic workload components. Benchmarks and rules of thumb
(ROTs) may be needed to apportion aggregate measures to basic components in lieu
of real measurements. Figure 5.6 illustrates the range of data collection alternatives
available to a capacity manager.
In many cases, it is possible to detect a fairly limited number of applications
that account for signicant portions of resource usage. Workload measurements can
be made for these applications in a controlled environment such as the one depicted
in Fig. 5.7. These measurements must be made separately at the client and at the
server for scripts representing typical users using each of the applications mentioned
above. These measurements are aimed at obtaining service demands at the CPU
and storage devices at the client and server as well as number of packets sent and
received by the server and packet size distributions. The results thus obtained for a
specic type of client and server must be translated to other types of clients and/or
servers. For this purpose, we can use specic industry standard benchmarks, such
as SPEC ratings, to scale resource usage gures up or down.
Example 5.1: Assume that the service demand at the server for a given appli-
cation was 10 msec, obtained in a controlled environment with a server with a
SPECint rating of 3.11. To nd out what this service demand would be if the
server used in the actual system were faster and had a SPECint rating of 10.4, we
need to scale down the 10 msec measurement by dividing it by the ratio between
the two SPECint ratings. Thus, the service demand at the faster server would be
10=(10:4=3:11) = 3:0 msec. Of course, the choice of which benchmark to use to

use benchmark, use benchmark, use measurements

industry practices, and industry practices, only
ROTs only ROTs, and measurements

Data Collection Facilities

None Some Detailed

Figure 5.6. Data collection alternatives for workload characterization.

 A Step-by-Step Approach to Capacity Planning
110 in Client/Server Systems Chapter 5

dedicated
client running server
script for
application A

performance performance
monitor monitor

performance
monitor

Dedicated LAN

Figure 5.7. Controlled environment for workload component benchmarking.

scale measurements taken in controlled environments down or up depends on the

type of application. If the application in question is a scientic application that
does mostly number-crunching of oating-point numbers, one should use SPECfp
as opposed to SPECint ratings.
In general, the actual service demand, ActualServiceDemand, is obtained from
the measured demand, MeasuredServiceDemand, at the controlled environment by
multiplying it by the ratio of throughput ratings|such as the SPEC ratings|of
the resource used in the controlled environment and the resource used in the actual
environment:
ActualServiceDemand = MeasuredServiceDemand 
ControlledResourceThroughput : (5.5.1)
ActualResourceThroughput
Chapter 12 discusses in greater detail issues involved in data collection for
client/server systems.
5.5.3 Validating Workload Models
In building any model, abstractions of the reality being modeled are made for sim-
plicity, ease of data collection and use, and the computational eciency of the
modeling process. The abstractions compromise the accuracy of the model, so the
model must be validated within an acceptable margin of error, a process called
model validation . If a model is deemed invalid, it must be calibrated to render it
valid. This is called model calibration .
Validating workload models entails running a synthetic workload composed of
workload model results and comparing the performance measures thus obtained
with those obtained by running the actual workload. If the results match within a
Section 5.6. Workload Forecasting 111
10{30% margin of error, the workload model is considered to be valid. Otherwise,
the model must be rened to more accurately represent the actual workload. This
process is depicted in Fig. 5.8.

5.6 Workload Forecasting

Workload forecasting is the process of predicting how system workloads will vary in
the future. Through this process one can answer questions such as: \How will the
number of e-mail messages handled per day by the server vary over the next 6 mo?"
\How will the number of hits to the corporate intranet's Web server vary over time?"
Answering such questions involves evaluating an organization's workload trends if
historical data are available and/or analyzing the business or strategic plans of
the organization, and then mapping these business plans to changes in business
processes (e.g., sta increases and paperwork reduction initiatives will yield 50%
more e-mail and Internet usage and 80% more hits on the corporate Web server).
During workload forecasting, basic workload components are associated to busi-
ness processes so that changes in the workload intensity of these components can
be derived from the business process and strategic plans.

Actual Synthetic
Workload Workload

C/S System C/S System

measured response times, measured response times,

throughputs, utilizations, etc. throughputs, utilizations, etc.

NO Model
acceptable?
Calibration

YES

Figure 5.8. Workload model validation.

 A Step-by-Step Approach to Capacity Planning
112 in Client/Server Systems Chapter 5

Example 5.2: Consider the C/S transactions in the example of Fig. 5.3. Assume
that we plot the number of invoices issued for each of the past 6 mon, months
numbered 1{6, as depicted in Fig. 5.9. By using linear regression, we can establish
a relationship between the number of monthly invoices and the month number. In
this example,
NumberInvoices = 250  Month + 7; 250:
If we now need to forecast the number of invoices for the next month, we can
use the above linear relationship to predict that 9,000 invoices will be issued next
month. The number of invoices can be associated with the number of transactions
of various types submitted to the database server. We can use regression techniques
(see Chap. 11) to establish relationships between the number of invoices and the
number of C/S transactions of various types, such as sales, purchase requisition,
marketing, and nance. These relationships allow us to predict the arrival rate of
these types of transactions. For example, if each invoice generates, on the average,
5.4 sales transactions, we can predict that next month, the database server will
receive 9; 000  5:4 = 48; 600 sales transactions. If we divide this amount by the 22
working days of a month and by the 8 business hours of a day, we get an arrival
rate of 276 sales transactions/hour.
Chapter 11 discusses workload forecasting techniques, such as moving averages,
exponential smoothing, and linear regression, in detail.

5.7 Performance Modeling and Prediction

An important aspect of capacity management involves predicting whether a system
will deliver performance metrics (e.g., response time and throughput) that meet
desired or acceptable service-levels.

5.7.1 Performance Models

Performance prediction is the process of estimating performance measures of a com-
puter system for a given set of parameters. Typical performance measures include
response time, throughput, resource utilization, and resource queue length. Exam-
ples of performance measures for the C/S system of Fig. 5.3 include the response
time for retrieving mail from the mail server, the response time experienced during
Web-based corporate training sessions, the throughput of the le server in LAN 2,
the utilization of the backbone FDDI ring, and the throughput and average num-
ber of requests queued at the Web proxy server. Parameters are divided into the
following categories:
 system parameters : characteristics of a C/S system that aect performance.
Examples include load-balancing disciplines for Web server mirroring, network
protocols, maximum number of connections supported by a Web server, and
maximum number of threads supported by the database management system.
Section 5.7. Performance Modeling and Prediction 113

10,000
historical data
9,000

8,000
forecast point:
(7, 9,000)
7,000
Number of Invoices

Trendline:
6,000 No. Invoices = 250 * Month + 7,250

5,000

4,000

3,000

2,000

1,000

0
1 2 3 4 5 6 7
Months

Figure 5.9. Workload forecasting.

 resource parameters : intrinsic features of a resource that aect performance.

Examples include disk seek times, latency and transfer rates, network band-
width, router latency, and CPU speed ratings.
 workload parameters : derived from workload characterization and divided
into:
{ workload intensity parameters : provide a measure of the load placed on
the system, indicated by the number of units of work that contend for
system resources. Examples include the number of hits/day to the Web
proxy server, number of requests/sec submitted to the le server, number
of sales transactions submitted per second to the database server, and
the number of clients running scientic applications. Another important
characteristic of the workload is the burstiness of the arrival process as
discussed in Chaps. 4 and 10.
{ workload service demand parameters : specify the total amount of ser-
vice time required by each basic component at each resource. Examples
 A Step-by-Step Approach to Capacity Planning
114 in Client/Server Systems Chapter 5

include the CPU time of transactions at the database server, the total
transmission time of replies from the database server in LAN 4, and the
total I/O time at the Web proxy server for requests of images and video
clips used in the Web-based training classes.
Performance prediction requires the use of models. Two types of models may
be used: simulation models and analytical models. Both types of models have to
consider contention for resources and the queues that arise at each system resource|
CPUs, disks, routers, and communication lines. Queues also arise for software
resources|threads, database locks, and protocol ports.
The various queues that represent a distributed C/S system are interconnected,
giving rise to a network of queues, called a queuing network (QN). The level of detail
at which resources are depicted in the QN depends on the reasons to build the model
and the availability of detailed information about the operation and availability of
detailed parameters of specic resources.
Example 5.3: To illustrate the above concepts we will use the notation introduced
in Chap. 3 to show two versions|a high level and a more detailed level|of the QN
model that corresponds to LAN 3 in Fig. 5.3, its Web server, its 100 clients, and
the connections of LAN 3 to the Internet and to the FDDI ring. Figure 5.10 depicts
a high-level QN model for LAN 3. The 10 Mbps LAN is depicted as a queuing
resource and so is the Web server. The set of 100 Windows clients is depicted as
a single delay resource because requests do not contend for the use of the client;
they just spend some time at the client. The FDDI ring and the Internet are not
explicitly modeled as this model focuses on LAN 3 only. However, trac coming
from the FDDI ring and from the Internet into LAN 3 has to be taken into account.
Note that the model of Fig. 5.10 hides many of the details of the Web server.
As mentioned in Sec. 5.4, the Web server runs on a dual processor machine. Thus,
a more detailed representation of the QN model would have to include the server

FDDI

LAN 3

100 Windows Web server

clients
Internet

Figure 5.10. High-level QN of LAN 3.

Section 5.7. Performance Modeling and Prediction 115
processors and disks as shown in Fig. 5.11.
Chapters 8 and 9 discuss, in detail, techniques used to build performance models
of C/S systems.
5.7.2 Performance Prediction Technique
To predict the performance of a C/S system we need to be able to solve the per-
formance model that represents the system. Analytic models [8] are based on a set
of formulas and/or computational algorithms used to generate performance metrics
from model parameters. Simulation models [5], [6], [9] are computer programs that
mimic the behavior of a system as transactions ow through the various simulated
resources. Statistics on the time spent at each queue and each resource are accu-
mulated by the program for all transactions so that averages, standard deviations,
and even distributions of performance metrics can be reported on the performance
measures.
There is a wide range of modeling alternatives. As more system elements are rep-
resented in greater detail, model accuracy increases. Data gathering requirements
also increase, as shown in Fig. 5.12. It is important that a reasonable balance be
made between model accuracy and ease of use to allow for the analysis of many
alternatives with little eort and in very little time. Analytic models are quite
appropriate for the performance prediction component of any capacity manage-
ment/planning study. In this book, we explore how analytic-based QN models can
be used to model C/S systems, Web servers, and intranets.
Many times it is unfeasible to obtain detailed performance data. It is important
to note that a detailed performance model that uses unreliable data yields non-
representative results.
5.7.3 Performance Model Validation
A performance model is said to be valid if the performance metrics (e.g., response
time, resource utilizations, and throughputs) calculated by the model match the

FDDI

LAN 3
disks
100 Windows
clients
Internet CPUs

Web server

Figure 5.11. Detailed QN of LAN 3.

 A Step-by-Step Approach to Capacity Planning
116 in Client/Server Systems Chapter 5

coarse grain model fine grain model

little effort in large effort in
data collection data collection

Performance Model Accuracy

Low High

Figure 5.12. Performance model accuracy.

measurements of the actual system within a certain acceptable margin of error.

Accuracies from 10 to 30% are acceptable in capacity planning [8].
Fig. 5.13 illustrates the various steps involved in performance model validation.
During workload characterization, measurements are taken for service demands,
workload intensity, and for performance metrics such as response time, through-
put, and device utilization. The same measures are computed by means of the
performance model. If the computed values do not match the measured values
within an acceptable level, the model must be calibrated. Otherwise, the model is
deemed valid and can be used for performance prediction. A detailed discussion on
performance model calibration techniques is given in [8].

Real Performance
System Model

Measurements Calculations

measured response times, computed response times,

throughputs, utilizations, etc. throughputs, utilizations, etc.

NO Model
acceptable?
Calibration

YES

Figure 5.13. Performance model validation.

Section 5.8. Development of a Cost Model 117
5.8 Development of a Cost Model
A capacity planning methodology requires the identication of major sources of cost
as well as the determination of how costs vary with system size and architecture.
Costs are categorized into startup and operating costs. Startup costs are those
incurred in setting up the system, while operating costs are the annual expenses
incurred to maintain the system and provide upgrades in hardware and software to
avoid obsolescence, performance degradation, and security vulnerabilities. Startup
costs apply to hardware, software, infrastructure, and initial installation charges.
Operating costs are related to hardware and software maintenance and upgrades,
personnel costs, training, telecommunications services, and consulting fees.
The highly distributed nature of LAN and client/server environments is fre-
quently responsible for a lack of knowledge of the costs incurred in maintaining
these environments. A survey of 250 companies showed that fewer than 5% of
U.S. corporations quantify their expenditures of PCs and LANs [4]. The same
study indicates that costs associated with LAN-connected PCs range from $5,000
to $10,000 per user, making PC/LAN usage the largest undocumented IT cost in
most corporations. In general, client/server costs can be divided into four major
categories: hardware costs, software costs, telecommunications costs, and support
cost. Hardware costs include the cost of
 client and server machines along with their disks and other peripherals, mem-
ory, and network cards
 disk storage arrays
 routers, bridges, and intelligent switches
 backup equipment
 uninterrupted power supplies (UPS)
 cabling
 vendor maintenance and technical support
Software costs account for the cost of
 server and client network operating systems
 server and client middleware (e.g., TP monitors)
 database management systems
 HTTP servers
 mail processing software
 oce automation software
 A Step-by-Step Approach to Capacity Planning
118 in Client/Server Systems Chapter 5

 business applications
 antivirus software
 security and intrusion detection software
 software development
 vendor software maintenance and upgrades
Telecommunication costs include charges for
 WAN services (e.g., Frame Relay, X.25 networks, T1, T3, ISDN)
 Internet Service Providers
Support costs include
 salaries, fringes, and benets of all system administrators, database adminis-
trators, LAN, and Web administrators
 help desk support costs which includes salaries, fringes, and benets of help
desk sta, and their infrastructure (e.g., computers, servers, and phones)
 training costs for support sta (includes travel and time o for training
courses)
 network management hardware and software
 performance monitoring software
More than one survey [2], [4] indicates that personnel costs account for a large
percentage|between 60 and 70%|of client/server costs. One can be as detailed as
required when accounting for costs. This increases the accuracy of the cost assess-
ment at the expense of the time and eort needed to obtain all needed information.
Alternatively, one can use more aggregated cost models that account for most of the
cost elements with a reasonable degree of accuracy. When some of the cost elements
are not known precisely, one can use Rules of Thumb (ROTs) to obtain a rst-cut
approximation to the cost model. Examples of cost ROTs are: hardware and soft-
ware upgrade is 10% of the purchase price per year, system administrator costs lie
between $500 and $700 per client per month, training costs range from $1,500 to
$3,500 per technical sta person per year, 40% of personnel costs are in the resource
management category, 40% are in applications development and maintenance, and
20% in other personnel [3], [4].
An MS Excel spreadsheet, called Cost.XLS, included in the accompanying disk,
provides a template for computing startup and operating costs for C/S systems.
Section 5.9. Cost/Performance Analysis 119
5.9 Cost/Performance Analysis
Once the performance model is built and solved and a cost model developed, vari-
ous analyses can be made regarding cost-performance tradeos. The performance
model and cost models can be used to assess various scenarios and congurations.
Some example scenarios are, \Should we mirror the Web server to balance the load,
cut down on network trac, and improve performance?" \Should we replace the
existing Web server with a faster one?" \Should we move from a two-tier C/S
architecture to a three-tier one?" For each scenario, we can predict what the per-
formance of each basic component of the global workload will be and what the costs
are for the scenario.
The comparison of the various scenarios yields a conguration plan, an invest-
ment plan, and a personnel plan. The conguration plan species which upgrades
should be made to existing hardware and software platforms and which changes in
network topology and system architecture should be undertaken. The investment
plan species a timeline for investing in the necessary upgrades. The personnel plan
determines what changes in the support personnel size and structure must be made
in order to accommodate changes in the system.
Some people favor the exclusive use of Return on Investment (ROI) analyses
to assess the payback of migrating to a C/S system. These analyses have the
drawback of looking only at the economic aspect of the issue. Other people decide
to invest in client/server systems because they see them as a necessary ingredient
of a company's business strategy, an enabling factor to improve customer service
and product quality, and to shorten time to market of new products.

5.10 Concluding Remarks

Determining the adequate capacity of complex, distributed client/server systems
requires careful planning so that user satisfaction is guaranteed, company goals are
achieved, and investment returns are maximized.
This chapter presented the framework of a methodology for capacity planning
of client/server systems. Chapter 6 expands on the \workload characterization"
step and discusses clustering analysis techniques, data transformation, and other
related issues. Chapter 7 discusses several industry standard benchmarks that can
be used as an aid in the process of workload characterization in lieu of actual
measurements. Techniques for measurements and data collection are discussed in
Chap. 12. Chapters 8 and 9 introduce performance models. Chapter 8 looks at the
issue from a systems point of view where large subsystems|a complete Web server,
for example|are seen as black boxes. Chapter 9 looks at performance models that
allow us to take into account the details of subsystems|the disks and processors of a
Web server, for example. Chapter 10 considers performance modeling as it applies
to the Web. Finally, Chap. 11 discusses various workload forecasting techniques
such as linear regression, exponential smoothing, and moving averages.
 BIBLIOGRAPHY

[1] J. M. ANDRADE, M. T. CARGES, T. J. DWYER, and S. D. FELTS, The Tuxedo

System. Reading, MA: Addison Wesley, 1996.
[2] GARTNER GROUP, The Cost of LAN Computing: A Working Model , Feb. 7,
1994.
[3] E. HUFNAGEL, The hidden costs of client/server, your client/server survival kit ,
Network Computing , vol. 5, 1994.
[4] ITG, Cost of Computing, Comparative Study of Mainframe and PC /LAN In-
stallations , Mountain View, CA: Information Technology Group, 1994.
[5] A. M. LAW and W. D. KELTON, Simulation Modeling and Techniques . 2nd ed.
New York: McGraw-Hill, 1990.
[6] M. H. MACDOUGALL, Simulating Computer Systems: Techniques and Tools .
Cambridge, MA: MIT Press, 1987.
[7] D. A. MENASCE , D. DREGITS, R. ROSSIN, and D. GANTZ, A federation-oriented
capacity management methodology for LAN environments, Proc. 1995 Conf. Com-
put. Measurement Group , Nashville, TN, Dec. 3{8, 1995, pp. 1024{1035.
[8] D. A. MENASCE , V. A. F. ALMEIDA, and L. W. DOWDY, Capacity Planning and
Performance Modeling: From Mainframes to Client-Server Systems. Upper Saddle
River, NJ: Prentice Hall, 1994.
[9] S. M. ROSS, A Course in Simulation . New York: Macmillan, 1990.

120