Level: Introductory Tom Milligan, Software Configuration Management Specialist, IBM Rational
Jack Wilber, Independent Consultant, IBM
15 Nov 2001 from The Rational Edge: Part 2 of a series on principles and techniques for improving IBM Rational ClearCase performance.
Part I
of this series, published in the July, 2001 issue of The Rational Edge,
provided an overview of the principles of performance assessment in an IBM®
Rational® ClearCase® environment. I outlined
an approach that I have found useful in diagnosing performance issues. This
approach is based on proceeding methodically through the performance stack -- starting at the operating system/hardware level, then checking and tuning Rational ClearCase parameters, and finally examining and optimizing the application layer.
Now, in Part II, I will discuss how to use specific tools and practices at each
layer of the performance stack to assess and improve the performance of IBM
Rational ClearCase on both Windows and UNIX platforms.
The OS/Hardware level of the performance stack
As I discussed in Part I, I tackle performance issues by starting
at the bottom of the performance stack -- at the OS/Hardware level
(see Figure 1).
Figure 1: The IBM Rational ClearCase performance
At this level I check for:
- Memory shortfalls
- Disk input and output (I/O) problems
- Network bandwidth and latency issues.
I'll discuss these issues in detail below.
Checking for memory shortfalls
ClearCase uses a number of caches to improve performance. Memory is used to
cache data on view servers and VOB servers. In addition, there are MVFS caches,
and a cache for each view in a view server process. All of these caches rely
on having enough memory to work effectively, and that is why memory is so critical
to ClearCase performance.
Memory is also related to processor performance and disk
input/output. A system that is short on memory may also have high
CPU utilization, because the processor must frequently swap memory
pages to disk.
On UNIX systems, I use UNIX utilities such as vmstat, sar,
and glance to check memory utilization and processor loading. However,
not all of these utilities are found on all versions of UNIX. Linux and Solaris
implementations are likely to have vmstat, and HP-UX will have
glance.
Figure 2 shows vmstat output from a system with a severe memory
shortage; each row in the vmstat output represents a snapshot of
the system at a specified time interval.
Figure 2: Output from the
vmstat utility shows virtual memory statistics
The scan rate is a key indicator of a memory shortfall. When the
system has determined that it needs space in memory, it scans for
pages of memory that it can swap to disk. The scan rate reflects how
many pages of memory per second it is looking at. Before the
introduction of the Solaris 8 operating system, a sustained scan
rate of more than 200 pages per second indicated a memory shortfall
situation. For Solaris 8 and beyond, any non-zero value in the scan
rate column means the system is short of memory.
The run queue column is also important because it shows how many
processes are in the run queue awaiting service from the processor.
The run queue should not be more than the number of CPUs in the
system minus 1, but I look for any non-zero value in the run queue.
The metrics in Figure 2 indicate a memory shortage that seems to
point to a need for more processor power. The CPU idle time, shown
in the last column, is zero. The run queue is also stacked up, with
15 processes waiting in the final row. If you were to look only at
these two columns, you might think that more CPU power would solve
the problem; but in fact the processor is doing so much memory
scanning that it is overwhelmed with system overhead tasks, and has
little time to actually run other processes.
Note that the paging rate values are not always as important as
the scan rate. In some operating systems, input/output is mapped to
memory pages, so a high paging rate may simply reflect heavy I/O
activity. This is especially true on machines that are NFS
servers.
If vmstat is not available on your system, you can get much of
the same information from sar, although it is not always as simple
to read. Figure 3a shows sar output on a system that has enough
memory, and Figure 3b shows sar output on a system that is low
on memory.
Figure 3a: Output from the
sar utility for a normal
system
Figure 3b: Output from
the sar utility for a system with memory shortfall
You can see the percentage of memory used is only 77 percent in
the normal system but 94 percent in the troubled system; the normal
paging rate is zero, but the troubled system's rate is hundreds of
pages per second. For the latter system -- and for the system shown
in Figure 2 -- adding more memory is a good first step toward
improving performance.
Alternatively, you can view other processes running on the system using ps
or top, to see whether some memory-intensive processes can be offloaded
to a different system.
On Windows platforms, the Windows Task Manager ( taskmgr.exe) is an easy way
to check memory and CPU usage. Performance Monitor ( perfmon.exe) is another
good tool for analyzing Windows systems. In addition, you may find open source
or third-party Windows versions of vmstat, sar, and
other UNIX utilities for checking system resources.
Checking for disk I/O problems
Just as the vmstat utility shows virtual memory statistics, the
UNIX iostat utility shows I/O statistics. Figure 4 shows sample
iostat output, which you can use to identify disk bottlenecks and
load balancing issues.
Figure 4: The iostat
utility displays disk activity
In iostat output, I look first at the %w column, which indicates
the percentage of time that there are transactions waiting for service. Put
another way, this is the percentage of time that the device queue is not empty.
The number here should be zero. The remedy for a non-zero value in the %w column
is to redistribute the disks so that busy disks are spread across multiple disk
controllers. Alternatively, you can redistribute the data so that often-used
data is spread across disks on different disk controllers, or install a faster
disk controller.
I also look at the %b column, which shows the percent of time
that a device is busy. This column can help identify load balancing
issues. For example, you might notice that almost all of your
devices have low %b values -- say less than 5% -- and that one disk
is 30% busy. In this case, you have a disk that is really in demand,
and you might want to spread the data across other disks.
For Windows environments, I wrote a small Visual Basic
application (see Figure 5 and Appendix A) that helps identify both
disk bottlenecks and memory shortfall situations.1
Figure 5: A Visual Basic application for monitoring
disk and memory utilization
Checking for network bandwidth and latency issues
If I do not detect any resource shortages after checking the memory, disk,
and processor utilization on the ClearCase VOB host, view host, and relevant
ClearCase client machines, my next step is to look for network latency problems.
From the client machine, I use the UNIX and Windows ping utility to measure
the roundtrip time to the VOB and view hosts. As a rule of thumb, if I see roundtrip
times of greater than 10 milliseconds, then network latency may be affecting
ClearCase performance. Lost packets are also a cause for concern, because they
have to be retransmitted, effectively doubling transmission time.
If ping indicates there may be a problem, I use the traceroute utility (on
Windows, tracert.exe) to dig a little deeper by tracing the route
a packet takes as it travels to a server. Ideally, I like to see just one hop
(or even zero, but that's not likely in most networks) to the server. Each hop
represents a delay, as the packet is routed through network hardware --
so the fewer hops the better. Output from traceroute can also help
pinpoint exactly which hop is causing the most delay. Network administrators
can use this information to help improve network performance, and, ultimately,
ClearCase response times.
Two other tools that can be helpful in identifying network problems are strace
and truss.2 They are particularly useful in tracking down repeatable,
command-centric problems, because they identify each system call that is executed
by a program. For example, if I notice that a snapshot view update is taking
a long time, I can run strace during one of the updates. In analyzing
the output, I look for lengthy pauses during any system calls. If I see a long
delay on a call related to a network operation -- for example, resolving
a hostname or opening a file on a network server -- I can use that information
to isolate and resolve the cause of the slowdown.
If I suspect the network is contributing to poor performance but cannot determine
what the problem is, I use a "packet sniffer" such as snoop or
ethereal.3 Typically, I use these only as a last resort, to see
exactly what is going on at the packet level. It is important to remember sensitive
data often flows over a network in an unencrypted form and sniffer software
makes this data visible to the user. For this reason many companies take a dim
view of unauthorized sniffing of their internal networks, so it is advisable
to get network administration staff directly involved if this kind of data collection
is required.
Sometimes I find that it is instructive to just play around with the tools.
For example, not long ago I was wondering what would happen if my registry server
went down. I configured my network, fired up ethereal, and unplugged
the network cable to the registry server. Then I tried to use cleartool,
the ClearCase command line utility, to look at a VOB. I saw a packet go out,
asking where the registry server was, and it hung there waiting for a response.
At the command line, cleartool was also blocked and waiting for
a response. As soon as I plugged the cable back in, the packets started flying
again, and cleartool continued.
When I am tracking down performance problems, if a particular ClearCase command
appears to be blocked, I can use ethereal to see what kind of packet
activity occurs when the command finally wakes up. That often helps me identify
what network resource is either not available or is slow in responding.
The ClearCase level
of the performance stack
Once I resolve any problems I find at the bottom of the performance stack,
I move up and take a look at the ClearCase tunable parameters. At this level
I look at three principal areas to improve performance, all of which involve
dynamic views:
- MVFS caches. In ClearCase, MVFS (multiversion files system) supports
dynamic views. Dynamic views use the MVFS to present a selected combination
of local and remote files as if they were stored in the native file system.
Essentially, MVFS enables users to view a VOB as a collection of files and
folders. MVFS maintains several caches to maximize performance.
- Individual view caches. In addition to MVFS caches,
each individual view has its own cache. Dynamic views require
frequent checks for updates, making them fairly "chatty" in terms
of the number of RPCs (remote procedure calls) they use. The view
server maintains several caches, consisting mostly of VOB data, to
respond faster to RPCs from clients.
- Express builds. In my experience, relatively few people
are aware of express builds. Technically, these are not really
tunable parameters, but they can be used to significantly improve
build performance when using dynamic views.
Let's take a closer look at each of these areas.
MVFS caches
I use two ClearCase tools to assess MVFS cache performance: cleartool
and mfvsstat. Using cleartool getcache
-mvfs, I can see how full the various MFVS caches are.
As Figure 6 shows, cleartool getcache -mvfs
also offers recommendations for adjusting MVFS cache parameters. The ClearCase
Administrator's Guide4 provides more information on what each of the caches
does.
Figure 6: Sample output
from cleartool getcache -mfvs
Having a mostly full cache is not necessarily a problem. In fact, it often
reflects a smoothly running system. However, if you have a full cache with a
low hit rate, then that cache is likely undersized. The hit rate indicates how
often ClearCase finds the information it is looking for in the cache.
To determine hit rates for the MVFS caches, I use mvfsstat -cl,
as in Figure 7.
Figure 7: Sample output
from the ClearCase utility mvfsstat
I look for the pattern of full caches and low hit rates to identify a cache
that might benefit from an increased size. In general, I like to see a hit rate
above 90 percent. If I notice a hit rate below 80 percent, and the cache is
approaching full, then I increase the cache size. One more note: the enoent
or name not found cache is an important one, because a cache miss there
is particularly time consuming. If you find that the cache is full with a low
hit rate, increasing its size should improve performance substantially. On multi-processor
machines, you also need to be careful not to make the cache too large. Oversized
caches can actually cause some performance degradation on systems that have
multiple processors, because of the way ClearCase processes manage locks on
the cache memory and the extra time it takes to search through a larger cache.
You can also measure the effectiveness of MVFS caches with respect to a single
command using mvfstime -cl <command>, where <command>
could be clearmake or another ClearCase tool. This can be useful
to assess how the caches are performing during a specific activity such as a
build. After the command completes, mvfstime will display the cache
hit rates during the execution of that command.
Adjusting the size of MVFS caches is fairly straightforward. On Windows, use
the ClearCase applet in the control panel (see Figure 8). A scaling factor is
used to bump up the size of all the caches, which is the preferred approach
in most cases. Alternatively, you can set the sizes of the individual caches
by clicking the "override" check box. However, changing individual cache sizes
may negatively impact performance. Normally, I just gradually increase the scaling
factor, and then check cache performance again, repeating this until the cache
hit rate rises to an acceptable level.
On UNIX, I use cleartool setcache -mvfs -persistent
-scalefactor to adjust cache sizes. The -persistent option
maintains the change across MVFS restarts. Without it, the cache sizes would
return to their original values the next time MVFS started. It is beyond the
scope of this article to go into full detail, but the section on Examining
and Adjusting MVFS Cache Size in the ClearCase Administrator's Guide
provides excellent guidance.
Figure 8: Adjusting MVFS
cache sizes with the ClearCase applet
Individual view caches
The steps needed to analyze and adjust individual view caches are similar to
those for MVFS caches. To check cache effectiveness, use cleartool
getcache -view viewname on Windows and UNIX systems.
As with the MVFS caches, I look for full caches with low hit
rates. The example in Figure 9 shows a lookup cache is only six
percent full, with a hit rate of 59 percent. If the lookup cache was
close to 100 percent, I would make an adjustment, but in this case
there is nothing to worry about. It is also important to check cache
statistics more than once to ensure you are seeing valid results,
and not transient values that may be the result of a recently
restarted server.
Figure 9: Checking individual view cache
effectiveness
Figure 10 shows how to adjust individual view cache sizes using cleartool
setcache -view. In the example, the -cview option specifies
that I am setting the current view. The -cachesize 1M option specifies
the total amount of memory to use for all caches. The default values for total
cache size are 512 KB on 32-bit platforms and 1 MB on 64-bit platforms. Adjusting
the total cache size does not change the ratio allotted to the subcaches; if
I increase the total cache size, each subcache gets proportionately bigger.
I can also set a site-wide default on cache sizes, using the cleartool
setsite command.
Figure 10: Setting individual view cache sizes
Express builds
You may also want to consider using express builds to improve
build performance. If you are unfamiliar with express builds, here
is a brief overview.
During a normal ClearCase audited build in a dynamic view, the fact that a
derived object (for example foo.o) has been built, along with other
information such as the version of the source files and the commands used to
generate the derived object, is registered with the VOB. This is done to facilitate
the ClearCase build avoidance (or binary sharing) mechanism. Consider a project
in which multiple people are working together, and some are building the same
software over and over. When one person builds foo.o using clearmake
in a dynamic view, clearmake "goes shopping." That is, it asks
the VOB if anyone else built foo.o using the same version of foo.c
and all other source files, using the same command line. If someone did, then
there is no need to rebuild foo.o, so clearmake simply
shares the original foo.o, which it moves into a special pool within
the VOB called the derived object pool. When anyone builds using the
same parameters, they will use the foo.o from the derived object
pool. This operation is known as "winkin", and it typically happens faster than
a straight compilation of foo.c.
What that means from a performance perspective is that every time
I use clearmake or
omake to do a build
in a dynamic view, these tools tell the VOB what I am building. This
generates a lot of RPCs and write transactions to the VOB, which
slows performance.
During an express build, however, these tools do not tell the VOB about
anything that is built. I can still access the VOB's derived object pool and
share existing objects, but I don't tell the VOB what I am doing -- so no
one else can share the results of my build.
Now, this may seem selfish, but it speeds up the build process in
two ways. First, during an express build, derived objects are
"registered" with the VOB. This means the VOB database is not
blocked for write access; so other users can get quicker access to
the VOB during my builds, and the VOB host can support more users on
existing hardware. Second, my builds are faster because those same
time-consuming VOB writes are eliminated. I have found that
individual express builds are up to 20 percent faster than normal
builds, depending on the project.
In Figure 11, you can see that response time increases along with
the number of background users doing builds in non-express build
views. For express builds, the line has a much shallower slope. You
can support many more users with the same hardware because express
builds reduce the amount of traffic going to the VOB and the amount
of work the VOB server has to do.
Figure 11: Express builds keep response times down as
the number of users increases
Adopting express builds as a team practice usually requires a change in the
team's user interaction model. If I use express builds, then I have to explicitly
share my build results or build avoidance will not work well for the rest of
the team. I can do that manually using the winkin command. Also,
I can use cleartool ls -long to determine if an object is shared
or not. For example,
cleartool ls -long foo
derived object (non-shareable)
foo@@05-Mar.10:31.2147483694 |
indicates that the object foo is not being shared with the rest
of the team. It is important to remember that a shareable derived object cannot
have non-shareable parts. If I build an entire application, for example, I can't
just share the application; I have to share all of the objects that compose
it.
Typically, when a team adopts this model, they will set a site-wide default
to create views that use express builds. They will also set up one normal view
that is a not an express build view. Instead of relying on all team members
to explicitly share their derived objects, they use this normal view to do a
nightly build -- or even an hourly build if desired. The purpose is to populate
the VOB with derived objects that everyone on the team can winkin.
That way, everyone can still enjoy the advantages of binary sharing, but without
slowing down to tell the VOB every time they build something.
To create a new view that uses express builds, simply use the -nshareable_dos
option in cleartool when making the view. For example, you can
use this command: cleartool mkview -nshareable_dos <rest of command
line>. To convert an existing view to express builds, use the same
option with chview. For example, use cleartool chview -nshareable_dos
<rest of command line>. After that, just use clearmake
or omake to build as usual.
In a Unified Change Management, or UCM, 5 development stream, express build views are created
by default. In non-UCM projects they are not. However, you can use cleartool
setsite to set a site-wide default for creating views that use express
builds. For more information on express builds, see Building Software with
Rational ClearCase. 6
Whether you decide to use express builds or not, if your builds take advantage
of ClearCase's build avoidance and binary sharing capabilities, then ClearCase
administrators can help improve build performance by ensuring that obsolete
views are deleted when they are no longer needed. The process of "shopping"
for appropriate derived objects to winkin can affect performance when ClearCase
must examine several potential configuration records for a possible match. 7 This suggests that sites that depend on winkin need
to keep the VOB cleansed of old derived objects. This, in turn, implies removing
views that are no longer being used. The scrubber utility, whose job it is to
remove unused derived objects, will not remove a derived object so long as a
single view still holds a reference to it. Over time, the number of references
diminishes until only the view that created it holds a reference, which is sufficient
for the derived object to linger in the VOB while the view persists. By deleting
unused views, the Administrator enables the scrubber to remove old derived objects
from the pool, which accelerates the process of "shopping" during dynamic-view
builds.
 |
The application level of the performance stack
The application level is the uppermost layer of the performance stack. It consists
of process scripts and triggers that perform activities related to ClearCase
functions. It also consists of clearmake -- for building applications
-- and the makefiles that clearmake depends on. As I mentioned
in Part I of this series, the application level is sometimes difficult to address,
as it is often more complex, and frequently defended by the owners or creators
of the scripts, triggers, or makefiles that you may want to change. However,
the potential for performance gains in this area is great.
Process scripts and triggers
Many organizations use process scripts written in an interpreted language such
as Perl or a shell scripting language to perform special processing. For example,
instead of using a simple cleartool checkout, they will create
a script that first logs the checkout, and then issues one or more cleartool
commands. Other organizations create scripts to resemble legacy version management
systems. In either case, the scripts tend to issue multiple cleartool
commands, one after another.
Triggers, which are configured to run automatically during a particular ClearCase
operation, can also invoke cleartool from an interpreted language.
Unlike process scripts, triggers are often invisible to users, who might not
know that any additional processing is happening as part of their check-out
operations, for example.
If you are using Perl to implement process scripts or triggers,
there are a few steps that you can take to improve performance. In
fact, if you are not using Perl, you may want to consider
re-implementing your application level scripts in Perl to take
advantage of some of these techniques.
As I mentioned in an earlier Rational Edge article, "Using
Perl with Rational ClearCase Automation Library (CAL)," when a program invokes
cleartool, the operating system must create a new process, and
there is a significant amount of overhead associated with starting that new
process -- allocating memory for it, creating a new entry in the process
table, and so on. This can be very time consuming, and if a script calls cleartool
repeatedly, the delays accumulate and can become very noticeable. You can avoid
the delays associated with multiple cleartool commands by using
the Perl ClearCase package 8 or the ClearCase Automation Library, which provide entry
points directly into ClearCase. In my previous article on CAL, I noted a simple
experiment that I conducted to gather basic performance measurements. I timed
a task that I completed with cleartool and then timed the same
task using a CAL implementation instead. For this specific operation, the CAL
implementation was about 30 percent faster.
Another technique that can help improve performance is to precompile your Perl
scripts into self-contained applications, using PerlApp from ActiveState's Perl
Development Kit, for example. 9 In Part I of this series, the organization highlighted
in the case study took another approach. When they re-evaluated the functionality
they had implemented using scripts and triggers, they noticed that Unified Change
Management could handle much of it. So they decided to adopt UCM. As a byproduct
of that change, much of their application-level processing was moved down into
native ClearCase operations, which are much faster.
Before UCM was available, a number of organizations had written wrappers around
check-out and check-in operations to build up change sets associated with activities.
The wrapper scripts would prompt users to specify what activity they were working
on and then track the activity, using a database or some other mechanism. Now,
all of those operations are native UCM ClearCase operations. By using UCM to
perform them instead of homegrown scripts, you can achieve significant performance
gains.
Simplifying makefiles and accelerating builds
At many customer sites that I visit, I often find makefiles that
are arcane and convoluted.
Organizations that have used make or clearmake for
lengthy projects grow afraid to touch their makefiles for fear they will break
the build. The result is that these files grow over time with no controlling
plan. I compare this phenomenon to the Winchester Mystery House, near San Jose,
California, which has stairways and corridors that go nowhere, and doors that
open into empty spaces or walls. 10
Like this house, many makefiles have been built on over the years
with no blueprints for guidance. And people are afraid to do
anything to them, other than to add what is absolutely required to
make new builds. Typically, these makefiles are not optimized or
pruned, and no one knows exactly how they work. Yet organizations
rely on them to build their systems.
I always encourage customers to periodically review/rewrite project makefiles
to avoid the Winchester Mystery House syndrome. Plus, it is always useful to
have someone around who actually knows how to build the software. If you don't
know exactly what your makefile is doing but you can build your software, then
you can use the ClearCase configuration record to create a basis for a new makefile.
Simply build your application with an audited build using clearmake.
When the build is done, run cleartool catcr -makefile myapplication.
This will output the configuration record in makefile format. This makefile
may not be optimized, but it can be more understandable and provide a basis
for optimizations.
Of course, using express builds can also accelerate the build process. And
you may also want to consider performing parallel distributed builds in UNIX
environments or parallel builds in multi-processor Windows environments. See
the ClearCase manual, Building Software with ClearCase for more information
on setting up a parallel build.
A final note on build performance and MVFS caches: be careful of using many
-I directives in compiler search paths. The -I <dir>
compiler directive is used to designate <dir> as one of the directories
in which to search for header files used in source compilation. For each header
included in a source file, the compiler will search each directory in turn until
it finds a match, then it moves on to the next. The MVFS caches file information
in the dirent and enoent caches, the latter caching
the pathnames at which each file sought was not found. These caches provide
a faster means of lookup, both for finding correct and avoiding incorrect pathnames.
If you use many -I directives for many directories, and each of
those directories has many files of which only very few are actually needed
by the compiler, the effect is to fill the enoent cache with every
directory entry that was not a match for every file that was not found. With
sufficiently large numbers of file entries, the enoent cache becomes
full and searching it becomes less efficient. If you think this may be affecting
the performance of your builds, consider linking all headers and other compile-time
included files to a single directory, and include this one directory in a -I
directive.
Shared network resources and ClearCase Doctor
Shared network resources -- such as the domain controller, name servers,
and so on -- also affect ClearCase performance. On Windows systems, analysis
in this area is comparatively easy; just let the ClearCase Doctor do the work.
Figure 12 shows results from the standard static analysis that ClearCase Doctor
performs when it starts up. It tests host name resolution and reports how long
it took to contact the domain controller, to acquire a license, and to contact
the registry server.
Figure 12: ClearCase Doctor
shows response times for shared network resources
Most customers I talk with know about these reports, but few know that ClearCase
Doctor also does dynamic analysis. From the Analysis menu, you can select
Server Accessibility Analysis... to access a variety of dynamic analysis
capabilities, as shown in Figure 13a.
Figure 13a: ClearCase
Doctor provides server accessibility analysis capabilities
In Figure 13a, I've selected the radio button to check a specific
path relative to a view and a VOB. After I click "Start Analysis," I
see the results in Figure 13b.
Figure 13b: The results of a server accessibility
analysis
(click here to enlarge)
The result shows me the response times to access the file I specified in the
given view and VOB. In this case the response times were very fast, because
everything was self-contained on my machine. However, if I notice that it is
it taking too long to check out or check in a particular file, I can use this
dynamic analysis in ClearCase Doctor to get a better picture of what is happening.
Other performance factors
There are a few other ways to prevent slowdowns of ClearCase.
In general, don't store thousands of files in the VOB root, which
is not cached in the same way as other directories; instead, put
them in subdirectories. In fact, I follow this practice for any file
system that I use.
Also, if you are using a version of UCM from 2002 or earlier, try to keep the
number of modifiable components in your project down to ten or fewer and avoid
long-lived streams with large numbers of baselines. Either of these situations
can adversely affect performance. Enhancements to UCM for ClearCase version
2003 have greatly improved these areas, so these limits no longer apply.
Take it step by step
Analyzing and improving ClearCase performance can be a complex undertaking.
But like any complex task, it becomes manageable when you break it down into
smaller pieces. In my experience, the performance stack provides an excellent
framework for partitioning the job. As I move through the stack -- from
the OS/Hardware layer to the ClearCase parameters and application layers, I
keep in mind that even small performance gains can have a large impact on the
productivity and efficiency of an organization in the long term. Spending a
little time improving performance now can save a lot of time down the road.
Appendix A
The Visual Basic application shown in Figure 5 is available for
download here.
Note: This application is for instructional purposes only, and
may not be suitable for production use.
Notes
1 My application is based on two
books by Curt Aubley: Tuning & Sizing NT Server and
Tuning and Sizing Windows 2000 for Maximum Performance, both
published by Prentice Hall. These books provide more details on
using native Windows tools, such as Task Manager and Performance
Monitor, to pinpoint Windows performance bottlenecks.
2
truss is specifically a
Solaris utility (AIX has now emulated it in OS 5.x, but this version
is not as sophisticated as that on Solaris 5.7 and later). MKS
offers a Windows version,
truss.exe. There are (at
least) two types of
strace for Windows, the
better of them being that which is installed with Cygwin.
Cygwin
strace does provide
time-deltas, whereas the downloadable standalone does not. Cygwin is
careful to point out that
strace is primarily
designed for debugging the Cygwin dll. The analogous tool on HP 11.x
is called tusc, and
it provides output and functionality commensurate with that of
truss on later versions of
Solaris. AIX has a facility called 'trace' which, while more
difficult to use, does provide a comprehensive system call-tracing
facility.
3
snoop is primarily a
Solaris tool. Microsoft's
Netmon is available for
Windows platforms;
ethereal is available for
multiple operating systems. In addition,
tcpdump provides similar
functionality for UNIX versions other than Solaris (including
Linux).
4 This manual ships with the ClearCase product.
5 Unified Change Management is Rational's "best practices"
process for managing change, from requirements to release. Enabled by ClearCase
and IBM® Rational® ClearQuest®, UCM defines a consistent, activity-based
process for managing change that teams can apply to their development projects
right away.
6 This manual ships with the ClearCase product.
7 ClearCase uses a hashing strategy to quickly eliminate
most derived objects, but large development efforts can still have several potential
matches that must be examined in more detail.
8 The Perl ClearCase package is available from CPAN at http://www.cpan.org/. The package ClearCase::CtCmd,
provided by Rational, is a compilable interface into the cleartool subcommand
process table. It bypasses the startup cost of a cleartool session by linking
directly with the IBM Rational ClearCase libraries and using compiled entry
points into the Rational ClearCase shared objects. This can significantly improve
performance in scripted use of Rational ClearCase within Perl.
9 See my Rational Edge
article "Using
Perl with Rational ClearCase Automation Library (CAL)," for more
information on this, and additional details on using CAL.
10 Sarah Winchester, an heir to the
Winchester rifle company fortune, had constant work done on the
house for 38 years. See http://www.winchestermysteryhouse.com/
References
Curt Aubley, Tuning & Sizing NT
Server. Prentice Hall, 1998.
Curt Aubley, Tuning and Sizing Windows 2000 for
Maximum Performance. Prentice Hall, 2000.
Adrian Cockroft and Richard Pettit, Sun
Performance and Tuning: Java and the Internet. Prentice Hall,
1998.
Gian-Paolo D. Musumeci and Mike Loukides,
System Performance Tuning, 2nd Edition. O'Reilly &
Associates, 2002.
Richard Pettit, SE Toolkit. http://www.setoolkit.com/.
Joseph D. Sloan, Network
Troubleshooting Tools. O'Reilly & Associates, 2001.
Hal Stern, Mike Eisler, and Ricardo Labiaga,
Managing NFS and NIS, 2nd Edition. O'Reilly & Associates,
2001.
Ed Wilson and James Naramore, Network
Monitoring and Analysis. Prentice Hall, 2000.
Brian L. Wong, Configuration and
Capacity Planning for Solaris Servers. Prentice Hall, 1997.
"HP-UX Memory Management." Hewlett Packard Company
White Paper, 2000. http://docs.hp.com/hpux/onlinedocs/os/11i/mem_mgt.html.
Download | Description | Name | Size | Download method |
|---|
| File description, 50 characters max. | 8708_2832_cc_perf_panel.zip | 15 KB | HTTP |
|---|
About the authors  | | | Tom Milligan works in IBM Rational Software's Western Regional Services Organization (RSO West) and doing Clear* consulting. Prior to joining Atria Software in 1995, Tom was ClearCase czar and buildmeister for a project at a utility company in Portland, Oregon.
He has spoken at the Rational Users Conference three times:
1997: Integrating ClearCase NT with Third-Party Applications
1999: Integrating Requisite Pro and DDTs
2001: Using Perl with the ClearCase Automation Library (CAL)
Tom counts Astronomy among his hobbies and is active in the Central Coast
Astronomical Society in San Luis Obispo, CA. |
| | | Jack Wilber has worked with Rational Software as an independent consultant since 1998. In that time he has either authored or co-authored many whitepapers, case studies, product datasheets, and even an article or two for The Rational Edge. When not writing for Rational, Mr. Wilber spends his time developing software out of his home office in South Carolina. He has more than ten years of experience in software development and holds a B.S. in Computer and Electrical Engineering from Carnegie Mellon. |
Rate this page
| 
