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
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
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.
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
Figure 3a: Output from the
sar utility for a normal
Figure 3b: Output from
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
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
other UNIX utilities for checking system resources.
Checking for disk I/O problems
Just as the
vmstat utility shows virtual memory statistics, the
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
utility displays disk activity
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
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
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
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
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
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
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
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.
I use two ClearCase tools to assess MVFS cache performance:
-mvfs, I can see how full the various MFVS caches are.
As Figure 6 shows,
also offers recommendations for adjusting MVFS cache parameters. The ClearCase
Administrator's Guide4 provides more information on what each of the caches
Figure 6: Sample output
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
as in Figure 7.
Figure 7: Sample output
from the ClearCase utility
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
mvfstime -cl <command>, where <command>
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
-scalefactor to adjust cache sizes. The
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
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
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
Figure 10: Setting individual view cache sizes
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
in a dynamic view,
clearmake "goes shopping." That is, it asks
the VOB if anyone else built
foo.o using the same version of
and all other source files, using the same command line. If someone did, then
there is no need to rebuild
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
What that means from a performance perspective is that every time
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
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
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
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
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
chview. For example, use
cleartool chview -nshareable_dos
<rest of command line>. After that, just use
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
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
commands. Other organizations create scripts to resemble legacy version management
systems. In either case, the scripts tend to issue multiple
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
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
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
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
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
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
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
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
(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.
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.
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.
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.
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
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
snoop is primarily a
Solaris tool. Microsoft's
Netmon is available for
ethereal is available for
multiple operating systems. In addition,
tcpdump provides similar
functionality for UNIX versions other than Solaris (including
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
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/
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.
|File description, 50 characters max.||8708_2832_cc_perf_panel.zip||15 KB|