Windows NT CREATING OUTSTANDING PERFORMANCE
by Dr. Michael Salsburg
[Dr. Michael Salsburg has been active in the IT field for the
last 18
years and has been publishing papers internationally for over 10 years.
He has published on subjects that include modeling worldwide systems,
I/O modeling, and statistical workload analysis. He is currently Vice
President of Engineering for Datametrics Systems Corporation, a Zitel
division. (http://www.datametrics.com)]
from Executive Software Team Jump Executive Software>@@@
Systems administrators employing Windows NT are well aware that if their
systems hobble along or go down, it can slash productivity, dull overall
network performance and be costly to the organization. With a
fine-tuned network, however, a systems administrator can devote more
time to planning and achieving long-range IS goals and less time
battling daily calamities.
Analyzing current performance elements and modeling potential changes to
a system can go a long way to finding and alleviating current
performance bottlenecks and, more importantly, predicting them and
taking care of them before they occur.
Perhaps the best way to illustrate analysis and modeling is with a case
study. Take, for instance, a fictitious e-commerce company called
Websell that relies on its Web site - which is performing poorly on an
NT system - to reach its customers. Business can be lost because people
often do not have the patience to wait for slow Web pages to appear. In
addition, let's assume the server hosting the Web application is also
running a database and a network application.
The first step in revving up the performance of the Web application is
to quantify the performance using a performance monitor. There are
excellent products, such as Datametrics ViewPoint, available on the
market. For this article, the NT Performance Monitor, which is bundled
in with the NT operating system, will be used. The monitor will be
started and used to measure a "baseline" of the Web application.
To monitor a baseline, set up a log file to store the performance
statistics. For instance, select the "Log" view. Then, under
"Options", assign a log a name, such as "Websell" and save the
file. In
the Edit menu you can add objects to be collected in the log, such as:
- NetBEUI
- Physical Disk
- Processor
These objects cover the network, disk and processor activities for the
system. Under "Options", click on "Start Log". The benchmark
should
last long enough to handle a simulated workload of a dozen or so Web
visitors. When it's completed, click on "Stop Log".
Then change the View to "Chart" and, under "Options", choose
"Data From
..." and specify the "Websell" file. Under the Edit menu, select
the
following counters to be added to the chart:
%Processor Time
Avg. Disk Bytes/Transfer
Disk Transfers/Sec
Frames Sent/Sec
Frame Bytes Sent/Sec
Frames Received/Sec
Frame Bytes Received/Sec
A model can be constructed that simulates the discrete events of
transactions that arrive in the system and use the various CPU, disk and
network resources. The results show how the workload can affect delay
times for the simulated Web visitors.
With system configuration information and the measured workload
statistics, the model can be populated with the statistics found in the
NT Performance Monitor. To observe the application response time,
statistics on a per transaction basis need to be normalized.
Since Web site visitors spend a great deal of time waiting for and being
serviced by the disk, this would likely indicate a high number of I/Os.
The conclusion would be trouble with the I/O subsystem. The options
would be to either devote engineering resources into restructuring the
database application or install a cached disk. Installing a commodity
hardware item can often be the least expensive route. The reasoning is
simple: Hardware is a relatively inexpensive product as opposed to
engineers who have open-ended completion costs and delivery dates. In a
model with a cached disk product the cache hit rate could probably
achieve 85% and significantly reduce the response time.
The next step would be to increase the workload to simulate growth in
Web activity. This can be evaluated by increasing the arrival rate in
the simulation model. In Websell's case, assume the model with the
increased arrival rate shows that the CPU needs upgrading. It is then
necessary to run a model with a faster CPU to evaluate the proper CPU
power necessary to support the increase in traffic.
So far, a disk and CPU upgrade have been modeled. If the Web
application is still not running optimally, another suggestion is go
back to the statistics per transaction derived from the baseline
results. It could be that there are a high number of frames being sent
and received for each transaction. This is likely caused by the network
application that resides alongside the Web application on the server.
This situation could cause real problems once the Web application is
launched in a Wide Area Network (WAN) environment.
To investigate further, model the placement of the server 3,000 miles
away and replace the existing LAN segment with a T1 line with a
propagation time of 30 milliseconds, thus stretching the distance
between two nodes on the WAN to 3,000 miles.
If the T1 line is over 80% busy for the return traffic, there can be
severe degradation of performance due to high contention. Also, the
media time could be excessively high since each visitor transaction may
require hundreds of packets to be sent each way at 30 milliseconds a
packet. Let's assume that each transaction requires 600 packets to be
sent and received. The propagation delay would then add another 36
seconds to the response time. This is not uncommon when an application
is developed on a single LAN segment and then deployed in a WAN
environment. The overhead of too many packets is usually not realized
until the workload is physically distributed and those pesky little
electrons have to travel thousands of miles. Other models can then be
created (e.g., replace the T1 line with T3) to judge the customer
processing/costs ratio.
Once a new cache disk was installed, along with an upgraded CPU and a
speedier networking link, the server's performance was fine tuned to
maximize the efficiency of the Web application.
Note that optimizing system performance is a rather simple and logical
sequence of events. First, the current system is monitored and
analyzed. Next, an increase in traffic is modeled and optimized.
Finally, network topology changes are evaluated and optimized. This
level of measurement/prediction/management is a minor cost in the life
cycle of the product, but it may be crucial to the product's survival in
the marketplace. With the system running optimally, the company stands
to generate more revenue. In addition, the system administrators are
freed from tactical issues to concentrate more on strategic ones.
@Macarlo, Inc. @Macarlo's Shareware & Web OS/2 Java Lobby Member
Java Site Accredited