Understanding the Windchill Performance Tuning Process

By Matt Meadows, Sequoia Etcetera, LLC

PTC's Pro/INTRALINK Advisor website is littered with numerous knowledge base articles, forum discussions, and other sources of information about tuning various aspects of Windchill. While this is all great information, it leaves the impression that performance tuning is a collection of tips and techniques. All you have to do is gather and apply these tips until you get the performance you desire.

This article provides a broader perspective on performance tuning. As administrators, our product experience and implementation sizes vary. As a result, a handful of tuning tips may be enough for some companies, whereas others may spend weeks or even months improving performance. Each of us needs to understand our company's Windchill performance tuning scope and begin these projects accordingly. You have to understand where you are today, and what your expectations are, to get to your goal.

Down to Basics

To get started, we have to define what we mean by such terms like performance, baselines, and goals. For consistency, let's review some terminology.

• Performance is a measure of how effectively work gets done. With software, performance is typically measured in time (how long it takes to complete some task) and quantity (how many tasks can be completed simultaneously). In Pro/INTRALINK terms, this translates into how long it takes to check out and how many people can do it concurrently.

• Performance tuning is the ongoing process of improving performance. Sometimes tuning is also used to describe maintaining performance levels over time.

• A source system is the existing, legacy data management system. This may be a network drive, Pro/INTRALINK, or a third-party tool. In all cases, it is the current production data management or PLM system. There may even be multiple source systems.

• The target system is the new Windchill system. Initially, this should be a test system. Later in the process, it will be the production system.

• A baseline is a documented measurement of performance. There may be baselines for both the source and target systems.

• The goals are the desired performance. Goals must be stated quantitatively. The baseline performance of the source system may be the documented goal for the target system.

Resources at the Ready

All enterprise systems require some tuning. Companies and contractors have been doing this for years. There are many great resources available on the web about the performance-tuning process. A good place to start your own research is Wikipedia .

Establishing the Baseline

We must capture a baseline of the target system's performance before making any changes. There is no way to accurately determine if performance is better or worse without measuring what it currently is.

Many factors affect performance at any given moment. Mass user log-in at 8:00 a.m., nightly backups, malfunctioning switches, and any other conceivable interruption can skew performance results. To improve the accuracy of the baseline, measurements must be taken multiple times and averaged. Companies will differ on the number of times they test the system before averaging a baseline. As the performance gap between the baseline and the goal shrinks, the number of tests per baseline must increase. (For a great resource, Google wiki: Design of Experiments .)

The approved baseline is not only a measure of how fast a transaction can complete. It is also a measure of how many transactions can occur simultaneously. These are generally measured using a simulated load. Results are measured in transactions per second, response time, and concurrent transaction load.

A baseline is not necessarily a complete system measurement. A baseline of one aspect of performance, such as network speed, is very valuable when attempting to improve network performance. Ongoing measurements are necessary to ensure that changes made to the system are truly making a difference.

There are tools available to help capture performance baselines. Apache JMeter , designed to measure performance of web-architected products, is a free performance monitoring tool for Windchill applications. JMeter can, however, be challenging to configure and use. Other, more user-friendly products are available if you're willing to pay for them. HP Mercury Quick Test Professional is one example.

Quantifying Goals

The performance goal must be described in the same terms as the baseline. For example, if the target system's baseline is measured in transactions per second, the goal must also be measured in transactions per second.

Windchill is supposed to replace and possibly improve on the old system. If it doesn't perform as well as the old system, then we haven't replaced the old system. Consider this the lower limit of acceptable performance. The easiest way to establish the lower-limit goal is to capture a baseline measurement of the legacy system's performance.

While there is no hard ceiling for the goal, PTC provides some rough guidelines in a white paper describing how they improved performance in their test environment. But even PTC admits there are too many variables involved to exactly match these performance numbers in any given customer environment. The PTC numbers thus provide a relative performance goal for our system.

The real ceiling for performance tuning is resource allocation. Your boss will let you know what he is willing to spend in terms of your time and the company's money to keep improving performance beyond the base goal.

Making Changes

With well-defined baseline and goal numbers, we can begin making changes. You can start in any order, but there are a few heavy-hitters to focus on first to get the best bang for the buck. Review the Pro/INTRALINK Advisor site for some ideas.

Following the Design of Experiments philosophy, simultaneous changes are encouraged as long as they don't interfere with each other and affect the same performance measure. For instance, both increasing the number of threads and increasing packet sizes can potentially improve performance. But setting both at the same time may diminish overall performance because of more dropped packets. Instead, change one network-related setting and perhaps a browser XML processing setting at a time, since the performance for downloading can be measured independently. It's important to understand the potential impact of the options before you change them.

Measure the effect of changes on the system and keep or remove each change based on the outcome. This is where the plethora of knowledge base and Pro/INTRALINK Advisor performance tuning articles is really valuable. Here are just two key do's and don'ts.

1. Always implement changes in a test environment first . Use applications like those mentioned above to simulate load and measure performance changes. Document the changes for use on the production system. This will minimize the amount of time spent tuning the production system later.

Your IT department should be eager to provide you with a test system since they generally don't want to do the testing themselves. You and your IT resources must, however, work out the details of production environment tuning. In general, don't make unannounced, undocumented changes and avoid making changes in the middle of the workday.

2. Repeat the change and measurement process . Change multiple, unrelated options in various areas exhibiting poor performance, make a new baseline of the system, and compare it to the goal. Repeat this process until you achieve the minimum goal.

Production Hardware

Larger companies probably want to gauge production hardware based on the measured performance capabilities of the well-tuned test environment. Smaller companies may be more comfortable using tools like IBM's Windchill Server Sizing website.

Hardware calculators don't take into account many aspects that affect performance, such as size of database and quality of data. In general, though, spare hardware capacity at smaller implementations make up for these other considerations.

System Maintenance

It takes vigilance to keep Windchill running smoothly and efficiently. Good performance today can quickly degrade tomorrow without continual monitoring and maintenance.

PTC has and will continue to improve system performance in future builds and releases of both Windchill and Pro/ENGINEER. Keep up with the Windchill maintenance patches and Pro/ENGINEER build codes. Some patches and builds significantly improve performance. As always, apply them to the test environment first.

I'm certain more articles will be written and Knowledge Base Technical Points of Interest (TPIs) released as new performance tuning tips and techniques are discovered. These are valuable, and should be on every Windchill Administrator's reading list.

Shameless Plea for Focus Group Members

PTC/USER is working with PTC to clarify and simplify Windchill performance tuning for all companies. If you would like to aid in these efforts, please login to the PTC/USER members' website (members.ptcuser.org), join the System Administration Technical Committee, and ask to become part of the Windchill Performance Tuning focus group. We want to hear what you have to say. Please help us turn performance tuning into a short, simple, easy task. 

For more information on the System Administration Technical Committee, please contact Paul Crane at John Deere.

Matt Meadows is a solutions architect at Sequoia Etcetera, LLC in St. Louis, Missouri, USA.