Windchill Performance Tuning Guide

Windchill® Performance Tuning GuideWindchill® 9.1

Pro/INTRALINK® 9.1Arbortext® Content Manager™

Windchill® PDMLink™Windchill® ProjectLink™

December 2008

Copyright © 2007 Parametric Technology Corporation. All Rights Reserved.

User and training guides and related documentation from Parametric Technology Corporation and its subsidiary

companies (collectively “PTC”) is subject to the copyright laws of the United States and other countries and is

provided under a license agreement that restricts copying, disclosure, and use of such documentation. PTC

hereby grants to the licensed software user the right to make copies in printed form of this documentation if

provided on software media, but only for internal/personal use and in accordance with the license agreement

under which the applicable software is licensed. Any copy made shall include the PTC copyright notice and any

other proprietary notice provided by PTC. Training materials may not be copied without the express written

consent of PTC. This documentation may not be disclosed, transferred, modified, or reduced to any form,

including electronic media, or transmitted or made publicly available by any means without the prior written

consent of PTC and no authorization is granted to make copies for such purposes.

Information described herein is furnished for general information only, is subject to change without notice, and

should not be construed as a warranty or commitment by PTC. PTC assumes no responsibility or liability for any

errors or inaccuracies that may appear in this document.

The software described in this document is provided under written license agreement, contains valuable trade

secrets and proprietary information, and is protected by the copyright laws of the United States and other

countries. It may not be copied or distributed in any form or medium, disclosed to third parties, or used in any

manner not provided for in the software licenses agreement except with written prior approval from PTC.

UNAUTHORIZED USE OF SOFTWARE OR ITS DOCUMENTATION CAN RESULT IN CIVIL DAMAGES

AND CRIMINAL PROSECUTION.

For Important Copyright, Trademark, Patent, and Licensing Information: For Windchill products, select About

Windchill at the bottom of the product page. For InterComm products, on the Help main page, click the link for

Copyright 2007. For other products, select Help > About on the main menu for the product.

UNITED STATES GOVERNMENT RESTRICTED RIGHTS LEGEND

This document and the software described herein are Commercial Computer Documentation and Software,

pursuant to FAR 12.212(a)-(b) (OCT’95) or DFARS 227.7202-1(a) and 227.7202-3(a) (JUN’95), and are

provided to the US Government under a limited commercial license only. For procurements predating the above

clauses, use, duplication, or disclosure by the Government is subject to the restrictions set forth in subparagraph

(c)(1)(ii) of the Rights in Technical Data and Computer Software Clause at DFARS 252.227 7013 (OCT’88) or

Commercial Computer Software-Restricted Rights at FAR 52.227 19(c)(1)-(2) (JUN’87), as applicable.

02202007

Parametric Technology Corporation, 140 Kendrick Street, Needham, MA 02494 USA

Contents

Change Record.................................................................................................... vii

About This Guide.................................................................................................. xi

Related Documentation ............................................................................................................... xii

Technical Support........................................................................................................................ xii

Documentation for PTC Products................................................................................................xiii

Comments ...................................................................................................................................xiii

Windchill Tuning Methodology ......................................................................... 1-1

Windchill Solution Architectural Overview ..................................................................................1-2

Introducing the Windchill Tuning Methodology...........................................................................1-4

Identify Important User Actions............................................................................................ 1-4

Gather Dataset Details ........................................................................................................ 1-6

Gather Server Details .......................................................................................................... 1-6

Build a Resource Profile ...................................................................................................... 1-7

Client-side Diagnostic Logging......................................................................... 2-1

Overview.....................................................................................................................................2-2

Web Browser ..............................................................................................................................2-2

Java Clients ................................................................................................................................2-2

Logging in Java Applets....................................................................................................... 2-3

Client-side RMI Call Logging ............................................................................................... 2-3

Tunneling RMI over HTTP or HTTPS .................................................................................. 2-7

Pro/ENGINEER Wildfire Clients .................................................................................................2-7

Desktop Integration Clients ........................................................................................................2-7

Server-side Diagnostic Logging ....................................................................... 3-1

Overview.....................................................................................................................................3-2

Web Server Diagnostics .............................................................................................................3-2

Apache................................................................................................................................. 3-2

WebSphere and Embedded HTTP Server .......................................................................... 3-5

Servlet Engine Diagnostics.........................................................................................................3-5

Request Level Logging ........................................................................................................ 3-5

Servlet Engine to Method Server Call Diagnostics .............................................................. 3-7

Windchill Performance Tuning Guide iii

Windchill Application Server Diagnostics................................................................................. 3-11

Windchill Server Manager Diagnostics.............................................................................. 3-12

Windchill Method Server Call Diagnostics......................................................................... 3-12

Windchill Method Server Service Diagnostics................................................................... 3-27

Oracle Diagnostics................................................................................................................... 3-31

Oracle Tracing................................................................................................................... 3-31

Aphelion Diagnostics ............................................................................................................... 3-33

Application Tuning .............................................................................................4-1

HTML Browser Tuning ............................................................................................................... 4-2

Browser Cache Settings...................................................................................................... 4-2

Java Plug-in and Java Application Tuning ................................................................................. 4-2

TCP/IP Tuning..................................................................................................................... 4-2

JAR File Tuning................................................................................................................... 4-3

Plug-in Heap Settings.......................................................................................................... 4-3

Web Server Tuning for Apache 2............................................................................................... 4-4

Compressing File Content................................................................................................... 4-4

Tuning Directives................................................................................................................. 4-5

Servlet Engine Tuning................................................................................................................ 4-5

Tomcat 5.5 Tuning .............................................................................................................. 4-5

WebSphere and Embedded HTTP Server .......................................................................... 4-7

Windchill Servlet Tuning ............................................................................................................ 4-7

Tomcat Servlet Session Activation/Passivation ................................................................ 4-10

Windchill Method Server Tuning .............................................................................................. 4-12

Setting Cache Sizes .......................................................................................................... 4-12

wt.properties...................................................................................................................... 4-13

service.properties .............................................................................................................. 4-21

db.properties ..................................................................................................................... 4-22

Windchill Adapter Properties ............................................................................................. 4-26

Webject Optimization ........................................................................................................ 4-28

Background Method Server Tuning ......................................................................................... 4-28

Java Garbage Collector Tuning.........................................................................5-1

Garbage Collection .................................................................................................................... 5-2

Young Generation Guarantee ............................................................................................. 5-2

Monitoring Garbage Collection Duration & Frequency........................................................ 5-4

wt.method.MemoryMonitor Class........................................................................................ 5-7

Managing System Memory ........................................................................................................ 5-8

Balancing System Memory ........................................................................................................ 5-9

iv Windchill Performance Tuning Guide

Performance Checklist....................................................................................... 6-1

Performance Checklist ...............................................................................................................6-2

Troubleshooting Flowcharts .......................................................................................................6-6

Response Time Diagnosis................................................................................................... 6-6

System Performance Diagnosis .......................................................................................... 6-8

CPU, Memory, Disk, Network Metrics............................................................... 7-1

CPU Analysis..............................................................................................................................7-2

Distinguishing Windchill Processes By Executable Name................................................... 7-2

CPU Statistic Snapshots...................................................................................................... 7-2

CPU Resource Profile.......................................................................................................... 7-5

Detecting CPU Bottlenecks ................................................................................................. 7-6

Generating Thread Dumps .................................................................................................. 7-6

How to Fix CPU Bottlenecks................................................................................................ 7-7

Memory Analysis ........................................................................................................................7-8

Memory Statistic Snapshots ................................................................................................ 7-8

Detecting Memory Bottlenecks ............................................................................................ 7-8

How to Fix Memory Bottlenecks .......................................................................................... 7-9

Disk Analysis ..............................................................................................................................7-9

Detecting Disk Bottlenecks ................................................................................................ 7-10

How to Fix Disk Bottlenecks .............................................................................................. 7-11

Network Analysis ......................................................................................................................7-12

Measuring Network Traffic ................................................................................................. 7-12

Detecting Network Bottlenecks.......................................................................................... 7-13

How To Fix Network Bottlenecks....................................................................................... 7-16

Resolving Domain Names ................................................................................................. 7-16

Oracle Tuning Guidelines..................................................................................A-1

Improving Oracle Database Performance ................................................................................. A-2

Approximating the Initial Instance Memory Size........................................................................ A-2

Further Memory Size Redistribution and Tuning ....................................................................... A-6

Gathering and Maintaining System Performance and Data Distribution Statistics.................... A-7

Gathering and Updating System Performance Statistics.................................................... A-8

Oracle Database Performance Baselines ................................................................................. A-8

Establishing Performance Baselines .................................................................................. A-9

Preserving, Purging, and Managing Performance Statistics Snapshots .......................... A-10

Generating Reports and Analyzing Database Performance Statistics ............................. A-10

Tuning Oracle for Customized Windchill Applications ............................................................. A-11

Identifying and Tuning SQL Statements ........................................................................... A-12

Oracle Tools to Collect Database Performance Statistics....................................................... A-13

Reporting Performance Problems to PTC ............................................................................... A-13

Windchill Performance Tuning Guide v

SQL Server Tuning Guidelines......................................................................... B-1

SQL Server Recommendations .................................................................................................B-2

General Recommendations................................................................................................. B-2

Data Loading Recommendations ........................................................................................ B-2

Operating System Tuning ................................................................................. C-1

HP-UX Tuning............................................................................................................................C-2

Tuning the HP-UX Kernel.................................................................................................... C-2

VxFS Tuning........................................................................................................................ C-4

Configuring Oracle Data Files with Raw Logical Volumes .................................................. C-6

Solaris Tuning ............................................................................................................................C-7

Tuning the Solaris Kernel .................................................................................................... C-7

Configuring Oracle Data Files With Directio Filesystem...................................................... C-7

Windows Tuning ........................................................................................................................C-8

Windows System Tuning..................................................................................................... C-8

NTFS Tuning ....................................................................................................................... C-8

Application Server Disk I/O Tuning ..................................................................................... C-9

Network Adapter Tuning...................................................................................................... C-9

Workflow Queue Tuning.................................................................................... D-1

Queue Pooling ...........................................................................................................................D-2

Dedicated Queues .....................................................................................................................D-3

Enabling Dedicated Queues................................................................................................ D-3

Setting “has dedicated queue” Flag to True ........................................................................ D-4

Combining Queue Pooling and Dedicated Queues ...................................................................D-5

Index

vi Windchill Performance Tuning Guide

Change Record

The following tables describe the major changes made in the guide for each

update.

Table 1 Changes for 9.0

Chapter Description

Entire guide Removed Oracle 9i information and

updated third-party product

information for Apache, Tomcat,

Aphleion, and supported platforms.

Server-side Diagnostic Logging Updated the Servlet Engine

Diagnostics and Windchill

Application Server Diagnostics to

document log4j messaging

capabilities.

Oracle 9i Tuner Appendix was removed as Oracle 9i is

no longer supported.

Oracle Tuning Guidelines Updated content to provide useful

information for tuning Oracle 10g

Windchill databases.

Oracle Tuning Scripts Appendix was removed as the scripts

are not needed for Oracle 10g.

vii

Table 2 Changes for Windchill 8.0, Maintenance Release M040

Table 3 Changes for Windchill 8.0, Maintenance Release M030

Chapter Description

Chapter 4, Application Tuning Removed indexing information from

chapter as RetrievalWare is no longer

used for Windchill Index Search.

Chapter 6, Performance Checklist Updated Performance Checklist

section to include the use of the Oracle

9i Tuner and reference a new guide for

indexing information.

Chapter 7, CPU, Memory, Disk,

Network Metrics

Updated Detecting Memory

Bottlenecks section with new

threshold information.

Appendix A, Oracle 9i Tuner New appendix with information on

installing and using the Oracle 9i

Tuner.

Appendix B, Oracle Tuning

Guidelines

Updated content to provide useful

information for tuning Oracle 9i and

10g Windchill databases.

Appendix C, Oracle Tuning Scripts Added Oracle 9i Tuner reference.

Appendix D, SQL Server Tuning

Guidelines

New appendix with information on

SQL Server recommendations.

Chapter Description

Chapter 1, Windchill Tuning

Methodology

Added Architecture overview in

Windchill Solution Architectural

Overview section

Updated existing sections under new

Introducing the Windchill Tuning

Methodology section

viii Windchill Performance Tuning Guide

Chapter 2, Client-side Diagnostic

Logging

Split existing logging chapter into this

chapter and the next chapter.

Reorganized an d updated this chapter

to clarify information and improve

ease of use.

Added Pro/ENGINEER Wildfire

Clients section.

Chapter 3, Server-side Diagnostic

Logging

Split existing logging chapter into this

chapter and the previous chapter.

Reorganized an d updated this chapter

to clarify information and improve

ease of use.

Updated Aphelion Diagnostics section

to recommend a change in the default

log level.

Chapter 4, Application Tuning Client-side Tunables section became

the HTML Browser Tuning section

and was updated.

Updated Compressing File Content

section.

Updated the Java Plug-in and Java

Application Tuning section to include

JAR file tuning and plug-in heap

settings.

Updated connector example and

added session timeout information in

Tomcat 5.5 Tuning section.

Added com.ptc.core.ca.web.client.gw.

sessionTime property to the Windchill

Servlet Tuning section.

Added

wt.cache.size.RoleAccessCache

property to the wt.properties section.

Reorganized properties and added

wt.pom.paging.snapshotQueryLimit

property to the db.properties section.

Added RetrievalWare Index Tuning

section.

Chapter Description

Change Record ix

Chapter 5, Java Garbage Collector

Tuning

Updated the following sections:

Garbage Collection

Balancing System Memory

Chapter 6, Performance Checklist Updated checklist and flowcharts.

Moved information from ancillary

sections to other chapters.

Chapter 7, CPU, Memory, Disk,

Network Metrics

Updated information and grouped it

under the following main headings:

CPU Analysis

Memory Analysis

Disk Analysis

Network Analysis

Appendix A, Oracle Tuning

Guidelines

Added Oracle 10g information.

Appendix B, Oracle Tuning Scripts Minor update.

Windchill Profiler appendix Moved from this guide to the

Windchill Customizer’s Guide.

Appendix C, Operating System

Tuning

Reorganized the information in the

appendix.

Added Using Hyper-Threading

Technology section.

Appendix D, Workflow Queue Tuning Updated queue names and property

values.

Chapter Description

x Windchill Performance Tuning Guide

About This Guide

The Windchill Performance Tuning Guide is designed to help improve the

performance and scalability of the Windchill system. The purpose of this guide is

to equip you, as the performance analyst, with the means to gather sufficient data

through the analysis of logs so that you can diagnose and resolve performance

issues. The information provided is applicable to all Windchill solutions unless

explicitly stated.

This guide contains the following:

• An introduction to the Windchill architecture and the PTC tuning

methodology in the first chapter.

• Basic logging information relating to Windchill performance tuning in the

Client-side Diagnostic Logging and Server-side Diagnostic Logging chapters.

• The tuning properties available in each tier of the solution in the Application

Tuning chapter.

• A discussion about memory management and impact of garbage collection on

performance in the Java Garbage Collector Tuning chapter.

• Performance checklists to guide you when analyzing performance issues in

the Performance Checklist chapter.

• Descriptions of some tools that can be used for analyzing CPU, memory, and

network problems in the CPU, Memory, Disk, Network Metrics chapter.

• Reference information that you can use on an as needed basis in the

appendices.

The information in the guide can be used in the following ways:

• To create some general performance metrics that can be run at specified

intervals to capture information that can be used in capacity planning.

• To build resource profiles for specific performance problems that you have

identified and then use that information to improve performance.

• Read the first five chapters of this guide to become familiar with the

Windchill performance tuning methodology, the diagnostic information that

is available in Windchill, and some of the tools that are available for your use.

xi

Then, review the performance checklists provided, starting on page 6-2.

Working through these checklists can help you isolate system level

performance problems and can help you determine if a bottleneck is caused

by the application or is an effect of some other resource.

Examples in this guide referencing third-party products are intended for

demonstration purposes only. For additional information about third-party

products, contact individual product vendors.

Some code examples in this guide have been reformatted for presentation

purposes and, therefore, may contain hidden editing characters (such as tabs and

end-of-line characters) and extraneous spaces. If you cut and paste code from this

manual, check for these characters and remove them before attempting to use the

example in your application.

Related Documentation

The following documentation may be helpful:

• Windchill Installation and Configuration Guide - Advanced

• Windchill System Administrator’s Guide

• Windchill Business Administrator’s Guide

• Windchill Customizer’s Guide

• Windchill Advanced Deployment Guide

• Oracle 10g Tuner for Windchill Solutions Installation and Configuration

Guide

For the latest documentation, access the PTC Reference Documents Web site. For

access to this site, see Documentation for PTC Products.

Technical Support

Contact PTC Technical Support via the PTC Web site, phone, fax, or e-mail if you

encounter problems using Windchill solutions or the product documentation.

For complete details, refer to Contacting Technical Support in the PTC Customer

Service Guide. This guide can be found under the Related Links section of the

PTC Web site at:

http://www.ptc.com/support/index.htm

The PTC Web site also provides a search facility for technical documentation of

particular interest. To access this page, use the following URL:

http://www.ptc.com/support/support.htm

xii Windchill Performance Tuning Guide

http://www.ptc.com/support/index.htm



You must have a Service Contract Number (SCN) before you can receive

technical support. If you do not have an SCN, contact PTC Maintenance

Department using the instructions found in your PTC Customer Service Guide

under Contacting Your Maintenance Support Representative.

Documentation for PTC Products

You can access PTC documentation using the following resources:

• Windchill Help Page — Click Help in the header of any Windchill page to

open the Windchill Help page, which provides you with a portal to all

Windchill documentation, including:

– A complete set of current online help topics for your products

– Product tutorials available on the PTC Web site

– Windchill manuals for users, administrators, and programmers

In addition, you can click Search All Help Sources to access the Windchill

Help Center, an online knowledgebase that includes a universal index of all

Windchill documentation. You can search all of the documentation at once, or

use the advanced search capability to customize your search. Once you have

located a topic you want to reference later, you can bookmark that topic for

quick access and even save your own comments about the topic.

• Product CD — All relevant PTC documentation is included on the CD set.

• Reference Documents Web Site — All books are available from the

Reference Documents link of the PTC Web site at the following URL:

http://www.ptc.com/appserver/cs/doc/refdoc.jsp

A Service Contract Number (SCN) is required to access the PTC

documentation from the Reference Documents Web site. For more

information on SCNs, see Technical Support:


Comments

PTC welcomes your suggestions and comments on its documentation. You can

submit your feedback through the online survey form at the following URL:

http://www.ptc.com/go/wc_pubs_feedback

About This Guide xiii



http://www.ptc.com/go/wc_pubs_feedback

xiv Windchill Performance Tuning Guide

1Windchill Tuning Methodology

This chapter introduces the Windchill architecture and tuning methodology. It

provides information about identifying the user actions where performance is an

issue and gathering the needed data to analyze the issue.

Topic Page

Windchill Solution Architectural Overview........................................................1-2

Introducing the Windchill Tuning Methodology ................................................1-4

1-1

Windchill Solution Architectural Overview

The following diagram provides a general architectural overview of the main

components in Windchill solutions:

The diagram shows components that are usually part of a Windchill solution; the

components in your particular solution could vary to some degree. For example,

you can use a Web server and servlet engine that is one component (such as

WebSphere with its embedded HTTP Server) instead of the individual

components shown in the diagram. Also, you can have a different set of clients

that your users access or you may have customized code that introduces additional

components into your architectural picture. The following discussion and later

discussions in this guide assume an architecture similar to the one presented in the

diagram.

Performance issues can occur in any of the components in the three tiers shown in

the diagram or can result from the communication that takes place between the

tiers or between components in single tier.

1-2 Windchill Performance Tuning Guide

Use the following diagram to gain some knowledge about the protocols used to

pass information between the software components that are in the servlet engine,

any Java application that is used (such as a workgroup manager), and the

Windchill method server:

As you can see from the diagram, there are three unique protocols used to pass

information to the method server:

• SOAP (Simple Object Access Protocol) is a lightweight protocol that is used

to send requests to the Info*Engine Simple Task Dispatcher in the Windchill

adapter. The task dispatcher executes Info*Engine tasks and returns the

output that is generated.

• IE SAK (Info*Engine Service Access Kit) directly utilizes the functions and

features of Info*Engine within the Windchill adapter to invoke tasks and

individual webjects.

• RMI (Remote Method Invocation) is a Java-centric remote procedure call

(RPC) mechanism implemented on sockets. Many Windchill applets and

applications use Java RMI to invoke server transactions.

Windchill Tuning Methodology 1-3

Introducing the Windchill Tuning Methodology

The general Windchill performance tuning methodology focuses on improving

client response times and transaction throughput by means of adjustable (tunable)

application properties.

To determine what your performance problems really are, you should first

identify specific user actions that are most costly (or time-consuming) and which

negatively affect customer business processes. After you identify a problematic

user action, you will need to determine which of the protocols described in the

previous section are used so that you collect data from relevant components.

After user actions and protocols are identified, complete the follow tasks:

1. Understand client/server control and data flows for the actions.

2. Collect diagnostic data from relevant tiers (client, application, or database).

3. Identify any bottleneck, and , if there is a bottleneck, determine if bottleneck

is affected by properties that can be tuned.

4. If there are affected properties, adjust property values and retest.

Note: The methodology does not discuss software optimization, which generally

requires specialized knowledge of the Windchill application. If you determine that

an unacceptable response time is caused by inefficient software, contact PTC

Technical Support to report the problem. See Technical Support for information

about reporting problems.

The following sections expand on identifying user actions and collecting related

data from which you can identify performance problems. Later chapters provide

information on logging options and property settings that you can use after you

have determined where the problem is located.

Identify Important User Actions

The first step is to determine a small set of user actions that are failing to meet

performance expectations. It must be recognized that Product Data Management

processes may negatively affect business performance when and if the end users

are unable to perform their work because of unresponsive software.

PTC recommends that you work with customer business analysts to prioritize a set

of user actions that have the greatest impact on productivity and user actions

where there are performance issues. The business critical user actions will vary

from business to business so it is important that the list of top priority actions be

defined by someone knowledgeable in the business processes.

Before proceeding, PTC recommends that performance expectations be defined

and agreed upon. Without a clear understanding of what constitutes acceptable

performance, it is difficult to know when goals have been met.


At this point, it is useful to understand if the performance problems are

consistently reproducible. If the problems are transient, then it will be necessary to

understand under what circumstances the symptoms arise. Analysis of the

application log files can reveal if the problem might be related to contention for

resources (for example, queuing). If the problem is reproducible when the system

is quiescent then it is usually safe to rule out resource contention. Such problems

are generally easier to profile and analyze.

Client response times are largely affected by server resource utilization. If you

conclude that the unacceptable response times tend to occur during periods of

high transaction concurrency then the methodology must take all client activity

into account. This is because one or more long running client requests can

consume excessive resources and cause newly received requests to queue.

PTC recommends that you work on one user action at a time. For each problem,

gather specific information on each user action, for example, gather the client

details. For a user experiencing unacceptable performance, collect:

• User name

• Client host name and IP address

• Client operating system and patch level

• Access method (LAN, WAN, dialup)

• Browser type and version

• JRE and plug-in version

• Stopwatch times for user action

• Date and time of recent or last request execution

• HTML/XML page being requested (where applicable)

• Determine if all users on all client hosts experience the same response time

• Differences in client CPU speed and access method

Depending on the nature of the problem, it might be necessary to enable and

collect client-side logs produced while the user performs the operation.

In addition to the client-side logs, it may be necessary to collect client-side CPU

and disk activity logs. The types of client processes for which CPU usage should

be measured include:

• Browser (IEXPLORER.EXE, FIREFOX.EXE)

• Java

• Anti virus (McShield.exe, and so on)

• Microsoft Office applications (if testing Desktop Integration)

• Pro/ENGINEER Wildfire


Refer to CPU, Memory, Disk, Network Metrics for information on gathering CPU

metrics.

Gather Dataset Details

Use the following list to gather dataset details for each user action you have

identified:

• Gather step by step sequence of operations.

• Identify business objects (part, assembly, folder, and so on) that exhibit the

problem.

• Identify business objects that do not exhibit the problem (if any).

• Measure size of data sent in request and response.

• Measure number of client server round-trips.

Gather Server Details

Use the following list to gather server details for each user action you have

identified:

• Gather all server hardware specifications: number of cores, CPU speed,

RAM, disk layout (RAID, UFS, VxFS, and so on), network bandwidth, and

latency between Windchill and Oracle /LDAP server.

• Gather release and patch levels for all server software including: operating

system, Web server, servlet engine, Windchill, Aphelion, Windchill Index

Search, and Oracle.

• Locate and gather configuration files for all server software including:

wt.properties, db.properties, codebase/WEB-INF/web.xml, Aphelion LDIF,

Web server, and servlet engine configuration files, and Oracle initialization

parameters.

• Try to determine which property settings have been modified from their

default values.

• Analyze application log files. Try to determine average and peak transaction

concurrency levels.

Depending on the nature of the problem, it might be necessary to enable and

collect server side logs produced while the client exercises the use case.

In addition to the server side logs, it will be necessary to collect server side CPU

and disk activity logs (Windchill and Oracle servers). The types of processes for

which CPU times should be measured include: Web server, servlet engine,

method server, Oracle, and the LDAP server. Refer to the CPU, Memory, Disk,

Network Metrics chapter for information on gathering CPU metrics.


Build a Resource Profile

Use the sequence diagrams that are later in this section to understand the flow of

data between client and server tiers. Client access to Windchill business objects

and services is performed with a range of different protocols and each request may

interact with different components in the Windchill technology stack.

After the flow of data between client and server is understood, you should build a

resource profile that describes which tiers consume significant CPU and I/O time

while processing one client request.

Many of the components can be configured to generate diagnostic data, including

the elapsed time and call counts.

In addition to the elapsed times, you should collect CPU usage for all processes as

reported by the client and server operating systems.

Wherever possible, ensure that the scope of the profile is limited to a single client

request. Windchill does not include instrumentation that reports CPU usage per

request. This has to be collected with operating system tools when the system is

quiescent.

In general1 response times are composed of one or more process’ CPU times plus

the sum of all I/O waits. A properly scoped resource profile should indicate which

tiers account for the majority of the CPU and I/O time. The diagnostic data

collected at that tier should then help you determine which method calls were

active.

The following sections describe sequence diagrams that show the interaction

between components. The steps listed after each diagram correspond to the

numbers in the diagram and describe details of each interaction.

1. This assumes that there is no queuing in the system and that each tier executes calls synchronously.


HTML Generation Using JSP with RMI Acquisition

The following diagram shows the interaction of components that starts at an

HTML browser and uses JSP with RMI acquisition. The descriptions below

correspond to the numbered interactions in the diagram.

1. HTML browser issues GET request for URL, for example: GET

/Windchill/netmarkets/jsp/workspaces/MyWorkspace.jsp?oid=

OR%3Awt.org.WTUser%3A9&u8=1.

2. Web Server forwards request to servlet engine.

3. Servlet Engine establishes servlet session for user (if one does not already

exist) and executes Java class compiled from MyWorkspace.jsp. A

NmCommandBean is instantiated and session specific state is restored for

servlet session. RMI calls are invoked for Windchill services to acquire

business objects or perform business logic.

4. The method server’s Java RMI runtime assigns the call to a thread and

executes the target method. The request may perform JDBC/JNDI and

Windchill cache queries. Zero or more objects may be serialized back to the

servlet engine as results.

5. Zero or more additional RMI calls may be invoked.

6. Zero or more additional result sets may be returned.

7. The servlet engine generates the resulting HTML page and sends it back to

the Web server.

8. The Web server streams the resulting HTML page back to the browser.


HTML Generation Using Windchill Template Processor


HTML browser and uses the Windchill template processor. The descriptions

below correspond to the numbered interactions in the diagram.


/Windchill/servlet/WindchillAuthGW/wt.enterprise.URLProcessor/

URLTemplateAction?oid=OR%3Awt.epm.workspaces.EPMWorkspace

%3A59233&action=ObjProps&u8=1.

2. Web server forwards request to servlet engine.

3. Servlet engine calls the Windchill Authenticated HTTP GatewayServlet,

which in turn invokes the static method processRequest on the

wt.httpgw.HTTPServer class in the method server using RMI.

4. The method server’s RMI runtime assigns the client request to a thread. A

MethodContext is created, the client arguments are unmarshalled, and the

target method is called. The request may require request data from

RDBMS/LDAP and remote Windchill caches. The MethodContext associated

with the call remains active until the call completes and is then discarded. The

thread may be subsequently assigned another client request.

5. The resulting HTML page is streamed back to GatewayServlet.

6. The resulting HTML page is streamed back to the Web server.

7. The resulting HTML page is streamed back to the browser.

8. The browser may perform a conditional GET request for a static resource (for

example: JPEG, GIF). The Web server responds with resource or 'not

modified' status.


HTML Generation Using JSP with Info*Engine RPC Model Acquisition


HTML browser and uses JSP with Info*Engine RPC model acquisition. The

descriptions below correspond to the numbered interactions in the diagram.


/Windchill/com/ext/jsp/reports/CustomReport.jsp.

2. Web server forwards request to servlet engine.

3. Servlet Engine establishes servlet session for user (if one does not already

exist) and executes Java class compiled from CustomReport.jsp. The

CustomReport invokes an Info*Engine task that executes a Webject. The

servlet engine resident Info*Engine server makes a remote procedure call to a

WTAdapter using Info*Engine IPC. The servlet engine thread associated with

the call waits for the IPC call to complete.

4. The WTAdapter invokes the webject corresponding delegate class in a

dedicated thread. A MethodContext may be created and the thread may

perform JDBC/JNDI/RMI queries causing the thread to wait. Zero or more

result objects get translated to an Info*Engine Group and serialized back to

the servlet engine when the call completes.

5. Zero or more additional IPC calls may be invoked.

6. Zero or more additional result sets may be returned.

7. The servlet engine generates the resulting HTML page and sends it back to

the Web server.

8. The resulting HTML page is streamed back to the browser.


XML Generation Using Info*Engine SOAP Model Acquisition


HTML browser and uses Info*Engine SOAP model acquisition. The descriptions


1. Client issues POST request with SOAP attachment, for example: POST

/Windchill/servlet/SimpleTaskDispatcher?CLASS=com.ptc.windchill.uwgm.

2. Web Server forwards request to servlet engine.

3. Servlet Engine invokes SimpleTaskDispatcher servlet that simply forwards

the request to the SimpleTaskDispatcher port in a Windchill Adapter. The

servlet engine thread associated with the call waits for the call to complete.

4. The SimpleTaskDispatcher component of the Windchill Adapter translates

SOAP attachment into Info*Engine task and input data and invokes

appropriate task (for example: tasks/com/ptc/windchill/uwgm/execute.xml).

The task creates a MethodContext and calls Windchill services (in process).

The thread may perform JDBC/JNDI/RMI queries. Zero or more result

objects get translated from Persistables to Info*Engine elements to XML and

are returned to the servlet engine when the call completes.

5. Zero or more additional IPC calls may be invoked.

6. Zero or more additional results sets may be returned.

7. The servlet engine passes results directly back to the Web server.

8. Web server streams result back to client.


Java Applet or Application with Direct RMI Model Acquisition

The following diagram shows the interaction of components that starts at a Java

plug-in or application and uses direct RMI model acquisition. The descriptions


1. Java Plug-in issues HTTP GET request for static resource (JAR file, class file,

GIF, and so on). Web server responds with resource or 'not modified' status.

2. Applet invokes RMI call directly to method server in order to acquire

business objects or execute business logic.

3. The method server RMI runtime assigns the client request to a thread, a

MethodContext is created, the client arguments are unmarshalled and the

target method is called. The thread may require data from RDBMS/LDAP, or

an out-of-process Windchill cache. The MethodContext associated with the

call remains active until the call completes.

4. Zero or more objects are serialized back to the client in response to the call.


Java Applet or Application with Tunneled RMI Model Acquisition

The following diagram shows the interaction of components that starts at a Java

plug-in or application and uses tunneled RMI model acquisition. The descriptions


1. Java client issues HTTP GET request for static resource (JAR file, class file,

GIF, and so on). Web server responds with resource or "not modified".

2. Applet issues HTTP POST request with RMI call arguments encoded as form

parameters. Example URL: /POST

/Windchill/servlet/JavaRMIServlet?forward=5002.

The RMI call is made in order to acquire business objects or execute business

logic.

3. The Web server forwards the POST request to the servlet engine.

4. The servlet engine invokes the JavaRMIServlet which forwards the RMI call

and arguments to the method server.

5. The method server RMI runtime assigns the client request to a thread, a

MethodContext is created, the client arguments are unmarshalled and the

target method is called. The thread may require data from RDBMS/LDAP, or

an out-of-process Windchill cache. The MethodContext associated with the

call remains active until the call completes.

6. Zero or more objects are serialized back to the JavaRMIServlet in response to

the call.

7. The JavaRMIServlet sends the resulting output back to Web server.

8. Web server passes output back to Java client.



2Client-side Diagnostic Logging

This chapter discusses the diagnostics logging options available in clients.

Topic Page

Overview .............................................................................................................2-2

Web Browser.......................................................................................................2-2

Java Clients..........................................................................................................2-2

Pro/ENGINEER Wildfire Clients .......................................................................2-7

Desktop Integration Clients.................................................................................2-7

2-1

Overview

When analyzing client response times, it is important to know how much of the

elapsed time is spent server side (for example, building an HTML response) and

how much time is spent client side.

CPU time on both the server and client can be a major component of the response

time, but so can network and disk I/O time. By subtracting the combined client

and server CPU times (for example, IEXPLORER, Tomcat, method server, and

Oracle) from the overall response time, you can estimate the time spent waiting

for I/O.

If the I/O component is significant, it will need to be included in the profile. For

information on gathering CPU and I/O metrics, see the CPU, Memory, Disk,

Network Metrics chapter.

Web Browser

HTML browsers do not generally produce diagnostic data that are useful for

performance analysis. Therefore, you need to rely on operating system tools such

as TaskManager, pstat, perfmon, ps, sar, and so on to measure CPU time

consumed by the browser process. Be aware of anti-virus processes that may

consume CPU and disk time when data is downloaded from the Web server.

Network packet capture tools such as MicroSoft NetMon, windump, snoop,

tcpdump, and so on are all useful for diagnosing network latency or TCP/IP

tuning issues. They can be run client side to record and timestamp all network

packets exchanged between client and server.

Java Clients

Java clients include both Java applets and Java applications:

• Java applets run within the client’s HTML browser and require that the Java

plug-in be installed in browser. The following section describes logging

options for Java applets.

• Java applications do not require a browser and diagnostic logging is

dependent on the capabilities in each application. The Windchill workgroup

managers are Java applications. For logging information on the Windchill

workgroup managers, see the workgroup manager documentation.

All Java clients use RMI. The RMI logging options available are described in the

following Client-side RMI Call Logging and Tunneling RMI over HTTP or

HTTPS sections.


Logging in Java Applets

The Java plug-in has powerful logging and diagnostic capabilities. Windchill

transactions that use the RMI protocol may be logged to the Java Console (see

below).

The Java Console itself has several levels of verbosity that log each HTTP request

to the Web server (set trace level to 2). The levels of verbosity can be useful for

checking whether any class or JPG files are missing from the Windchill JAR files

specified in the applet tag.

The Java Console can be configured to write to a separate log file by setting the

property javaplug-in.trace=true in the Java Runtime Parameters in the Plug-in

Control Panel.

Other useful features in the Java console include generating thread dumps (‘v’),

dump system properties (‘s’) and print memory usage (‘m’). Taking several thread

dumps in quick succession can show which threads are most active and also

whether they are CPU or I/O bound.

For more information on the Java Plug-in refer to the Tracing and Logging section

in the Java Plug-in Developer Guide. You can search for this guide on the Sun

site at:

http://developers.sun.com/index.html

Client-side RMI Call Logging

Client-side activity logging for Windchill RMI calls can be enabled with a

property in wt.properties. If the client is an applet running in the Java plug-in, the

messages are sent to its Java console; otherwise the output is written to stdout.

RMI client logging is activated by setting the following property:

wt.method.clientMethodTiming=true.

This property can be changed without restarting the method server. This is

because wt.properties is downloaded from the Web server when the client Java

VM first needs to read it. You must restart the browser each time you change

wt.properties; The wt.properties file is only read once per browser session.

For example, the following set of invocation messages was displayed at the

Tomcat output console when the Folders link from the Product tab was selected:

2007-09-05 14:15:40,426 INFO [TP-Processor13] wt.method.client.timing - INVOKE:

start com.ptc.core.components.util.InPlaceCommand$Remote.execute

[f687i6tz;2672;151]

2007-09-05 14:15:40,536 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end

com.ptc.core.components.util.InPlaceCommand$Remote.execute [f687i6tz;2672;151], 94

ms

Client-side Diagnostic Logging 2-3

http://developers.sun.com/index.html


start wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;152]


wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;152], 0 ms


start wt.session.SessionManagerFwd.getPrincipal [f687i6tz;2672;153]


wt.session.SessionManagerFwd.getPrincipal [f687i6tz;2672;153], 0 ms


start wt.preference.PreferenceService2Fwd.getValue [f687i6tz;2672;154]


wt.preference.PreferenceService2Fwd.getValue [f687i6tz;2672;154], 0 ms


start wt.preference.PreferenceService2Fwd.setValue [f687i6tz;2672;155]


wt.preference.PreferenceService2Fwd.setValue [f687i6tz;2672;155], 15 ms


start wt.preference.PreferenceService2Fwd.setValue [f687i6tz;2672;156]


wt.preference.PreferenceService2Fwd.setValue [f687i6tz;2672;156], 0 ms


start com.ptc.core.task.TaskManagerFwd.userHasAlertTasks [f687i6tz;2672;157]


com.ptc.core.task.TaskManagerFwd.userHasAlertTasks [f687i6tz;2672;157], 0 ms


start com.ptc.netmarkets.util.misc.NmActionServiceFwd.getAction [f687i6tz;2672;158]


com.ptc.netmarkets.util.misc.NmActionServiceFwd.getAction [f687i6tz;2672;158], 0 ms




com.ptc.netmarkets.util.misc.NmActionServiceFwd.getAction [f687i6tz;2672;159], 0 ms



















start com.ptc.netmarkets.folder.NmFolderServiceFwd.getFolderDetailsObjects

[f687i6tz;2672;164]


com.ptc.netmarkets.folder.NmFolderServiceFwd.getFolderDetailsObjects

[f687i6tz;2672;164], 0 ms



[f687i6tz;2672;165]



[f687i6tz;2672;165], 0 ms




com.ptc.netmarkets.util.misc.NmActionServiceFwd.getAction [f687i6tz;2672;166], 16

ms






start wt.fc.cache.ObjectReferenceCacheFwd.inflate [f687i6tz;2672;168]


wt.fc.cache.ObjectReferenceCacheFwd.inflate [f687i6tz;2672;168], 0 ms




























[f687i6tz;2672;175]



ms























[f687i6tz;2672;181]



[f687i6tz;2672;181], 16 ms











[f687i6tz;2672;184]



ms










To calculate the elapsed time for the client action of clicking the Folders link,

manually add the individual elapsed times of the invocations that are displayed. In

this case, the total elapsed time is 940 ms.

Tunneling RMI over HTTP or HTTPS

Java clients that are separated from the server tier by a firewall may need to use

RMI tunneling over HTTP/HTTPS. This is necessary if the range of port numbers

used by the server manager (5001) and method server (5002-5009) are blocked by

the firewall. In this case the Windchill JavaRMIServlet ‘unwraps’ the RMI call

from the HTTP request and forwards it to the method server.

When RMI requests are tunneled over HTTP or HTTPS, each request is logged in

the Web server access log as a POST request to the JavaRMIServlet.

Refer to the Windchill System Administrator’s Guide for details on configuring

RMI clients to use a custom socket factory for enhanced tunneling performance.

Pro/ENGINEER Wildfire Clients

Pro/ENGINEER Wildfire uses the config.pro file for setting the values it uses.

The following options from the config.pro file can impact performance, and you

should check their values when looking at Pro/ENGINEER Wildfire client

performance:

dm_http_compression_level

dm_network_threads

dm_network_request_size

dm_cache_size

For additional information about tuning Pro/ENGINEER Wildfire client, see the

Using Pro/Engineer with Windchill Guide.

Desktop Integration Clients

Windchill Desktop Integration (DTI) integrates PDM operations with various

Microsoft tools. The DTI configuration screen is accessed by going to the

Windchill menu in the Office application and selecting configuration. There is a

general tab with a check box for debug output.

The log files get written to the logs directory in the location where DTI was

installed. This would typically be c:\Program Files\ptc\Desktop Integration\logs.

The default file name is debug.log.



3Server-side Diagnostic Logging

This chapter discusses diagnostic logging options available in your Web server,

and servlet engine. Additionally, it describes Windchill, Oracle, and Aphelion

logging options.

Topic Page

Overview .............................................................................................................3-2

Web Server Diagnostics ......................................................................................3-2

Servlet Engine Diagnostics .................................................................................3-5

Windchill Application Server Diagnostics........................................................3-11

Oracle Diagnostics ............................................................................................3-31

Aphelion Diagnostics ........................................................................................3-33

3-1

Overview

The sever-side logging information is divided into the following areas:

• Web server diagnostics

• Servlet engine diagnostics

• Application server diagnostics

• Service diagnostics

• Oracle diagnostics

• Aphelion diagnostics

Use the following sections to learn about these diagnostic capabilities.

Web Server Diagnostics

Diagnostic information is provided for Apache and WebSphere servers.

Apache

Apache activity log (access.log) is usually found under

<Apache>/logs/access.log. By default, every request received by Apache is

logged to either the access.log or the error.log. It is important to monitor the

error.log file for errors that might affect client response times (such as missing

resources). The access.log file records every client request – including requests

for static resources (for example, gifs, .class), and dynamic content (for example,

JSP, HTML).

Note: The timestamp reported for each request in the Apache access.log file is

received. The log entry is written when the server finishes processing the request.

The following paragraphs describe the format of the log entries and contain

excerpts from the Apache documentation:

The access.log format is configured in httpd.conf with the LogFormat and

CustomLog directives and is:

LogFormat "%h %l %u %t \"%r\" %>s %b" commonCustomLog logs/access_log common


The above configuration will write log entries in a format known as the Common

Log Format (CLF). The log file entries produced in CLF are similar to the

following:

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200

2326

Each part of this log entry is described in the following table.

Log Entry Description

127.0.0.1 (%h) This is the IP address of the client (remote host) that

made the request to the server. If HostnameLookups

is set to on, then the server will try to determine the

host name and log it in place of the IP address.

However, this configuration is not recommended

since it can significantly slow the server.

The IP address reported here is not necessarily the

address of the machine at which the user is sitting. If

a proxy server exists between the user and the server,

this address will be the address of the proxy, rather

than the originating machine.

-(%l) The hyphen in the output indicates that the requested

piece of information is not available. In this case, the

information that is not available is the RFC 1413

identity of the client determined by identd on the

client's machine.

frank (%u) This is the user ID of the person requesting the

document as determined by HTTP authentication. If

the document is not password protected, this entry

will be a hyphen just like the previous one.

[10/Oct/2000:13:55:36

-0700] (%t)

The time that the server finished processing the

request. The format is:

[day/month/year:hour:minute:second zone]

day = 2*digit

month = 3*letter

year = 4*digit

hour = 2*digit

minute = 2*digit

second = 2*digit

zone = (`+' | `-') 4*digit

Server-side Diagnostic Logging 3-3

Note: You can record the elapsed time (in seconds) that Apache spent executing

the request by adding %T to the LogFormat, as follows:

LogFormat "%h %l %u %t %T \"%r\" %>s %b" common

For example, the following log entry indicates the Windchill client request

completed in 14 seconds:

132.253.8.192 - admin [06/Apr/2005:17:00:13 -0500] 14 "POST

/Windchill/wtcore/jsp/com/ptc/core/ca/web/gw/gw.jsp?alias=com.ptc.windchill.

enterprise.search%3AsimpleFrame.simpleSearch&u8=1 HTTP/1.1" 200 10419

A full description of the Apache access log file can be found at:

http://httpd.apache.org/docs-2.2/logs.html

GET /apache_pb.gif

HTTP/1.0" (\"%r\")

The request line from the client is given in double

quotes. The request line contains a great deal of

useful information. First, the method used by the

client is GET. Second, the client requested the

resource /apache_pb.gif, and third, the client used

the protocol HTTP/1.0.

It is also possible to log one or more parts of the

request line independently. For example, the format

string "%m %U%q %H" will log the method, path,

query-string, and protocol, resulting in exactly the

same output as "%r".

200 (%>s) This is the status code that the server sends back to

the client. This information is very valuable because

it reveals whether the request resulted in a successful

response (codes beginning in 2), a redirection (codes

beginning in 3), an error caused by the client (codes

beginning in 4), or an error in the server (codes

beginning in 5). The full list of possible status codes

can be found in the HTTP specification (RFC2616

section 10).

2326 (%b) The last entry indicates the size of the object

returned to the client, not including the response

headers. If no content was returned to the client, this

value will be "-". To log "0" for no content, use %B

instead.



http://httpd.apache.org/docs-2.2/logs.html

Apache mod_deflate Logging

To enable logging of compression ratios, insert the following three directives at

the end of deflate.conf file, before the </IfModule> element:

DeflateFilterNote Input instream

DeflateFilterNote Output outstream

DeflateFilterNote Ratio ratio

LogFormat '%h %l %u %t %D %>s "%r" %{outstream}n/%{instream}n

(%{ratio}n%%)"' deflate

CustomLog logs/deflate_log deflate

Contents that is compressed is indicated by the compression ratio after the URL.

For example, the following lines show compression ratios of 14 and 21 percent:

"GET /Windchill/netmarkets/jsp/site/listFiles.jsp?oid=site%7Ewt.inf.container.

ExchangeContainer%3A101&u8=1 HTTP/1.1" 8955/60762 (14%)"

"GET /Windchill/netmarkets/css/nmstyles.css HTTP/1.1" 3442/16340 (21%)"

WebSphere and Embedded HTTP Server

Refer to the online documentation for the WebSphere performance tuning at:

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com

.ibm.websphere.base.doc/info/aes/ae/welc6toptuning.html

Servlet Engine Diagnostics

The following sections describe request level logging for supported servlet

engines and logging that can be turned on for calls from the servlet engine to the

Windchill server.

Request Level Logging

Request level logging is available with the supported servlet engines. To enable

the request logging feature, edit Windchill WEB-INF/web.xml file as follows

(replace /dummy/* with /*):

<filter-mapping>

<filter-name>RequestTimingFilter</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

All servlet requests completed by the servlet engine are logged to the servlet

engine stdout. In the case of Tomcat, the log file is written to:

<Tomcat>/logs/localhost_Windchill_log.<date>

The following example shows a servlet request written to the Tomcat stdout:

2007-04-04 17:00:27 StandardContext[/Windchill]Request Completed

[Client=132.253.8.192, User=admin, Date=Wed Apr 04 17:00:13 CDT 2007,

Elaped=14153ms, URI=/Windchill/wtcore/jsp/com/ptc/core/ca/web/gw/gw.jsp]


http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.base.doc/info/aes/ae/welc6toptuning.html

Each part of this log entry is described below:


2007-04-04 17:00:27

StandardContext[/Windchill]

Request Completed

The fields prior to “Request

Completed” are servlet engine

specific. The Tomcat servlet engine

log has the date and time and the

context – Windchill in this case.

Client=132.253.8.192 This is the IP address of the client

remote host. The IP address reported

here is not necessarily the address of

the machine at which the user is

sitting. If a proxy server exists

between the user and the server, this

address will be the address of the

proxy, rather than the originating

machine.

User=admin This is the user ID of the person

requesting the document as

determined by HTTP authentication.

If the document is not password

protected, this entry will be “null”.

Date=Wed Apr 04 17:00:13

CDT 2007

This is the date and time at which the

servlet engine started to execute the

client request.

Elapsed=14153ms This is the elapsed time in

milliseconds that Tomcat spent

executing the request.

URI=/Windchill/wtcore/jsp/co

m/ptc/core/ca/web/

gw/gw.jsp

This is the URI sent in the client

request. It does not log form

parameters or query pairs.


Servlet Engine to Method Server Call Diagnostics

Depending on the type of page requested and the servlet or JSP invoked, the

servlet engine usually makes one or more calls into the Windchill method server

to request data or HTML streams. The following sections describe the techniques

that are commonly used to execute these calls and the logging that is available.

Message Logging using log4j

Starting with Windchill 9.0, Apache log4j is now being used as the primary

mechanism for managing and issuing log messages.

You can use the ServletRequests monitoring MBean to set up Windchill log4j

message logging for the servlet engine.

For example, to access the ServletRequests MBean on a Windows system using

jconsole from the local machine where Tomcat is the installed servlet engine, start

jconsole using the Java Console option from the Windchill shortcuts that are

installed. To connect to the local process for Tomcat, click the Local tab.Then

select the class named org.apache.catalina.startup.Bootstrap.start and click


Connect. The following window shows the jconsole window with

ServletRequests MBean attributes displayed:

Setting the logger level attributes in this MBean sets the logging level for the

servlet engine. For many of the MBeans, settings made through the MBeans apply

only to the current instance that is running. However, you can save the

configuration settings for both the ServletRequests and ServletSessions MBeans

by using the Save function from the Loader MBean. For information about using

Java Management Extensions (JMX), JMX clients, Windchill MBeans, and log4j

logging, see the Windchill System Administrator’s Guide.


Java Remote Method Invocation (RMI)

RMI provides servlet engines the most direct access to Windchill business objects

and services. RMI calls invoked by the servlet engine may originate in the

HTTPGateway servlet (for example, Windchill template processor requests) or

from explicit RMI calls embedded in JSP. To enable RMI call logging in the

servlet engine, refer to the Client-side RMI Call Logging section.

Dynamic Client Architecture (DCA)

Windchill DCA runs in the servlet engine and requests persistent data from

Windchill by using the Windchill adapter. The calls are made using the

Info*Engine SOAP protocol.

To measure the elapsed time spent in DCA versus executing Info*Engine tasks,

set the following property in wt.properties:

com.ptc.core.ca.co.common.util.dcaTimerMode

DCA then generates log entries into the following file:

<Windchill>/logs/DCAtiming.log

Example entries are as follows:

DCA Time=380 Task Time=1072 JSP Rendering Time=0

DCA Time=290 Task Time=962 JSP Rendering Time=0

Each DCA page request has the following format:

Preferences Reading (preload) Description

count = 4

time = 48

The page loaded four pre saved preferences and the

loading time was 48 milliseconds.

IE Tasks

count = 4

time = 3093

The page invoked four Info*Engine tasks. It is possible

that one task has invoked other tasks. The count

includes each task that is invoked.

The total time to invoke the tasks was 30093

milliseconds.

DCA Runtime

count = 1

time = 780

The number of pages invoked is always one. Each

request in DCA is treated as single page, although a

page can include several DCA frames.

The total time taken to load the DCA page was 780

milliseconds.

Preferences Reading (get(key))


This example shows that a single DCA page took 3 seconds to build during which

4 Info*Engine tasks were executed comprising 3093 ms and 780 ms spend by

DCA rendering the results. Other actions took minimal amounts of time.

Additionally, each DCA page request can include the following:

To turn on general logging for every DCA request, set the following property in

wt.properties:

com.ptc.core.ca.co.log.rules.file=*

The DCA framework maintains a cache of DCA frame elements. Setting this

property dumps the content of frame cache. The information in the frame cache

can be used to determine if the cache needs to be sized.

Every frame element has a unique address and time stamp of the last draw. When

a new frame element needs to be created and there is not enough space in the

cache, any older frames are discarded. DCA Web provides the following property

to control the maximum number of frames in the frame cache:

com.ptc.core.ca.web.client.element.factory.maxFrameCount=<cnt>

where <cnt> is the maximum number. The default value is 10.

When DCA Web receives a request to perform an operation resulting from

triggering an action, it tries to locate an appropriate frame in the cache that the

action belongs to. If a frame is not in the cache, a new frame is created and drawn.

When this happens in debug mode, DCA Web throws an exception; in user mode,

the user is prompted to repeat the operation.

count = 77

time = 0

The total number of preference keys loaded was 77.

Total time = 3 Seconds



Preferences Writing

count = 1

time = 16

The number of preferences that were updated was 1. The

total time taken to update the preference was 16

milliseconds.

IE Schema

count = 7

time = 16

The number of attributes that are extracted from a type

on the page was 7.

The total time taken to extract the attributes was 16

milliseconds.


SOAP

SOAP (Simple Object Access Protocol) based requests originate from the

Windchill Dynamic Client Architecture (DCA). Each SOAP request is sent to the

Simple Task Dispatcher in the method server. The Simple Task Dispatcher listens

on a socket for incoming requests (wt.adapter.simpleTaskDispatcher.minPort).

Based on arguments passed in the request, it invokes the appropriate target

methods in the method server using the Windchill adapter webject and task

delegates.

Refer to the Info*Engine Administration and Implementation Guide and the

Info*Engine User’s Guide for more information on logging.

Info*Engine

Info*Engine webjects and tasks are invoked in the Windchill adapter calls

received from the Info*Engine SAK. Such calls typically originate from the

Info*Engine servlet but may also come from JSP, JMS, or custom Java

applications.

For more information on logging, see the Info*Engine Administration and

Implementation Guide and the Info*Engine User’s Guide.

Windchill Application Server Diagnostics

Starting with Windchill 9.0, Apache log4j is now being used as the primary

mechanism for managing and issuing log messages. Some legacy logging has

been modified to make use of log4j, but a large amount of previously existing

Windchill logging capabilities remain as they were in previous releases and are

still managed by Windchill property files configuration settings.

There are numerous Windchill log4j loggers and properties that control the

verbosity and timing of transaction logging. For information about using Java

Management Extensions (JMX), JMX clients, Windchill MBeans, and log4j

logging, see the Windchill System Administrator’s Guide.

The following sections describe diagnostics for server manager, method server,

Info*Engine, Windchill adapter administration, and Windchill queues.


Windchill Server Manager Diagnostics

The Windchill server manager process writes a new log file. The log file name is

assigned using the value from the wt.manager.log.file property. The default value

is:

$(wt.logs.dir)$(dir.sep)ServerManager-$DATE(yyMMddHHmm)-$(wt.jvm.id).log

This creates a unique ServerManager-[creation date]-[jvm id].log file in the

<Windchill>/logs directory for the server manager.

Log entries generally comprise three fields: date, thread name, message detail. For

example:

Thu 6/7/07 13:52:47: RMI TCP Connection(1)-132.253.8.192: Starting

com.ptc.core.meta.server.impl.LogicalIdentifierCacheMgr

The server manager has the following responsibilities:

• Starts and monitors method servers and background method servers

• Connects RMI clients to method servers

• Ensures cache consistency in multi-method server configurations

Generally speaking, the server manager process is not a heavy consumer of CPU

time; however, if the resource profile suggests it could be a significant component

of the response time, it is most likely due to excessive cache activity. In order to

log cache activity in the server manager set property wt.cache.verboseServer=true

in wt.properties.

Additionally, Windchill maintains a separate log file containing only the

messages generated by the Windchill log4j loggers for the server manager. To set

the message verbosity, the timing of messages, some message formatting, and the

log file name used for this log file, you set properties in the

log4jServerManager.properties file. For information modifying the

log4jServerManager.properties file, see the Windchill System Administrator’s

Guide.

Windchill Method Server Call Diagnostics

The Windchill method server is at the heart of the application tier. It is a Java

application that executes methods on Windchill business objects. Embedded with

the method server is the Windchill adapter. The actual business logic (or method)

is implemented by a set of application services instantiated by the method server

at startup. In order for a client request to gain access to these application services

it is necessary to use one of three access paths: RMI, SOAP, Info*Engine IPC.

The following sections describe the use of MBeans for monitoring, logs, and

logging options that provide logging at the call level.


Using MBeans for Monitoring Purposes

You can use the monitoring MBeans that are available when you connect a JMX

client to a method server.

From a JMX client , such as jconsole, you can set up the monitoring of method

server activities. For example, to access the set of monitoring MBeans on a

Windows system using jconsole from the local machine where method server is

running, start jconsole using the Java Console option from the Windchill

shortcuts that are installed. To connect to the local process for the method server,

click the Local tab.Then select the methods server and click Connect.

The following figure shows the MBeans tree panel in the jconsole window with

MethodContexts MBean selected:

All monitoring MBeans are located under the Monitors leaf in the tree. The

following monitoring MBeans can provide you with useful information:

• The MethodContexts MBean keeps track of Windchill method contexts (RMI

requests, other internal Windchill method invocations, and some requests that

overlap with the Windchill adapter).


• The IeContexts MBean keeps track of Info*Engine requests (SOAP and

normal Info*Engine IPC requests, and other internal requests like task

invocation through the use of the workflow robot or something similar).

• The DirContexts MBean keeps track of JNDI requests based on the JNDI

adapter name.

• The IeCalls MBean keeps track of outgoing calls based on type (SOAP,

Info*Engine IPC or JNDI) and how much time they take.

This MBean is configured for both the method server and servlet engine, but,

out-of-the-box, only shows interesting information in the servlet engine since

that is where outgoing requests typically originate. If you implement a

customization involving more Info*Engine related processes, then whatever

issues outgoing requests will have interesting information collected by the

IeCalls MBean.

For each of the monitoring context MBeans, there are associated loggers: context,

statistics baseline, statistics recent, and statistics summary. The actual logger


names are exposed by the corresponding MBeans as attributes. For example, the

following Attributes tab shows the attributes for the MethodContexts MBean:

For the context and summary loggers, the pieces of information that a logger

issues are configurable. The information that can be logged is exposed by the

MBean in read-only in attributes that include the logger type. For example, the


MethodContexts MBean lists the information that can be logged in the

ContextLoggerOutputAttributesSupported and

StatisticsLoggerOutputAttributesSupported attributes. In general, these attribute

names have the following format:

<type>LoggerOutputAttributesSupported

The information that can be logged includes things like "Action", "Client",

"StartTime", "Id", "ThreadId", "ElapsedTotalSeconds", and so on.

If you set a context logger level to INFO, then each context logs the requested

information upon completion. If the context logger level is ERROR, then only

contexts resulting in an exception are logged. If the summary logger level is set to

INFO, then every time the configured interval elapses, statistics for activity over

the interval are logged.

At runtime, you can configure the these MBeans using a JMX client. However, if

you want the configuration to remain after restarting a method server, then you

must save the MBean configuration by invoking the Save operation on the Loader

MBean. Changes to log levels must be configured by updating the appropriate

log4j properties file.

For information about using Java Management Extensions (JMX), JMX clients,

Windchill MBeans, and log4j logging, see the Windchill System Administrator’s

Guide.

Method Server Log

The method server log file name is controlled by the wt.method.log.file property.

The default value is:

$(wt.logs.dir)$(dir.sep)MethodServer-$DATE(yyMMddHHmm)-$(wt.jvm.id).log

This creates a unique MethodServer-[creation date]-[jvm id].log file in the

<Windchill>/logs directory for each method server.

All diagnostic messages written to the method server log file follow a standard

format. Each line in the log file comprises the following three fields:

Date & timestamp

Thread name

Message detail

The timestamp field is accurate to within one second. The thread name

distinguishes log messages written by separate threads. The names assigned to

threads processing RMI requests are generally named “RMI TCP

Connection(yyyy). Thread names for SOAP or Info*Engine requests are named

“Thread-zzz”.

By default the background method server process (when configured) uses the

same wt.method.log.file property to assign its log file. You can change the log file

name configured by overriding the wt.method.log.file property value when the


background method server starts up. For example to name the log

BackgroundMethodServer instead of MethodServer, change

wt.manager.cmd.BackgroundMethodServer property in the wt.properties file as

follows:

wt.manager.cmd.BackgroundMethodServer=$(wt.manager.cmd.MethodServer)

wt.method.serviceName\=BackgroundMethodServer

wt.queue.executeQueues\=true

wt.queue.queueGroup\=default wt.adapter.enabled\=false

wt.method.minPort\=3000

wt.method.log.file=

$(wt.logs.dir)$(dir.sep)BackgroundMethodServer-$DATE(yyMMddHHmm)-$(wt.jvm.id).log

Additionally, Windchill maintains a separate log file containing only the

messages generated by the Windchill log4j loggers for each method sever. To set

the message verbosity, the timing of messages, some message formatting, and the

log file name used for this log file, you set properties in the

log4jMethodServer.properties file. For information modifying the

log4jMethodServer.properties file, see the Windchill System Administrator’s

Guide.

Server-side RMI Call Logging

The following sections describe relevant Windchill log4j logger and properties

that can be used to capture information about RMI calls.

Using the wt.method.server.timing Logger

To enable server side RMI call logging in the method server, set the logging level

for the Windchill log4j wt.method.server.timing logger to INFO.

The following extract illustrates the message format appearing in the method

server log file as a result of a client RMI request.

INVOKE: start

wt.clients.folderexplorer.FolderBusinessObject$LiteObjectProvid

er.getWTBusinessObjects

INVOKE: end

wt.clients.folderexplorer.FolderBusinessObject$LiteObjectProvid

er.getWTBusinessObjects, 1312 ms (15/1281/16)

The extract shows the fully qualified method being invoked; the IP address of the

remote client and, on the last line, the elapsed time spent processing the call. In

the latter case the figures in parentheses break down the total elapsed time into

three distinct phases:

1. Time to unmarshal arguments received from the client.

2. Time to execute the method.

3. Time to marshal the results to the client.


Note: The Windchill template processor actually builds the HTML as it marshals

the response. As a result, template processor requests typically exhibit much

higher elapsed times for marshalling than execution.

Using the wt.method.access.log.enabled Property

The next level of verbosity causes logging of every completed RMI call to a file.

Various data including the name of the target method and the duration of the call

is logged. The property is defined in wt.properties and has a default value of false.

It can be set true in both production and benchmarking tests –with a slight I/O

overhead. The method server must be restarted for the new value to be noticed.

The access log is written in a comma separated value (CSV) format to allow easy

import into a spreadsheet for further analysis. Unfortunately some spreadsheets

limit the number of rows read from file so it may be necessary to split the file into

several chunks.

Property wt.method.access.log.file specifies the path to the output file. The

default value is $(wt.logs.dir)\\access.csv

The following extract shows two entries from an access.csv file:

Wed 7/14/99 17:26:42: , 130.21.55.229, 340, 0, 1,

wt.session.SessionManagerFwd.getPrincipal,

wt.method.AuthenticationException,

Wed 7/14/99 17:26:45: , 130.21.55.229, 150, 0, 1,

wt.httpgw.HTTPServer.processRequest, wt.httpgw.HTTPResponse,

/wt.httpgw.HTTPAuthentication/login, admin

Each entry has the fields that are described in the following table:

Field Description

Date The timestamp generated when the call completed

rounded down to the nearest whole second.

Client Host The IP address of the originating host. Many of the IP

addresses will likely resolve to the host name where the

HTTPGatewayServlet is invoked. RMI calls from

applets and remote applications are logged with the

client IP address (or firewall IP address).

Time in Milliseconds The elapsed time in milliseconds for the call to

complete. In order to measure the CPU time spent

processing the call you need to run the method server in

a profiler.


Using the wt.method.methodSummaryInterval Property

When the wt.method.methodSummaryInterval property is set to true, the call

summary line is periodically written to the method server log file. The default

interval for activity reporting is ten minutes. The summary shows the number of

RMI calls completed, the average duration of the calls, and the maximum and

average number of active calls:

MethodSummaryWriter: SUMMARY: 10.0 min, calls = 6 (0.6/min), av

dur=492 ms, mx/av act = 1/1.0

Note: The call completion count and average durations reported do not include

SOAP or Info*Engine calls completed by the Windchill adapter.

Redirect Count Client requests may be redirected between method

servers as part of load balancing. The redirect count

field indicates the number of times each call was

redirected prior to execution. This count is always 0

when using a single method server or when load

balancing has not been configured correctly.

Active Context Count The active context count shows how many other active

calls were in progress in the method server when the

call completed. The count only applies to the method

server where the call was processed. Note that the

active context count includes calls being redirected.

Target Method The target method name comprises the fully qualified

identity of the method invoked.

Results Class Shows the class name of the result object returned to

the caller.

Detail If the call is received from the HTTPGatewayServlet

the detail field contains the PATH_INFO from the

requested URL.

UserName The last field in each line is the client’s authenticated

user name. This can be useful when monitoring user

activity patterns and capacity planning.

Field Description


Each summary line comprised of the fields described in the following table:

Server-side SOAP and Info*Engine Call Logging

The following sections describe SOAP and Info*Engine logging that is available

on the server.

Field Description

Summary Interval The first field in the summary line shows the summary

interval, for example, 10 minutes. The summary line is

only written when the method server has completed one

or more client RMI requests in the interval.

Calls The calls field shows how many client RMI requests were

completed in the interval. A call is defined as a remote

method invocation typically from the HTTPGateway or

remote applet/application. Included in the call count field

is also a throughput figure in terms of calls over time.

Average Duration Average duration provides an indication of elapsed times

experienced by clients (not inclusive of network latency

and rendering). The average duration is expressed in

milliseconds and is derived from the accumulated

elapsed time for all calls completed in the interval over

the number of calls completed. Average durations are

influenced by transaction complexity, result size and

system utilization. Primarily, the number and size of

database accesses made by a transaction affect its

duration. Transactions which make use of data cached in

the method server or thread will generally complete much

sooner than those that require database accesses.

Maximum/Average

Active Calls

The average number of active calls shows how many

other transactions were active when calls completed.

The active call counts are inclusive of SOAP and

Info*Engine requests. It is a useful measure of how

many client requests were concurrently active during an

interval. When viewed in combination with server

resource utilization it can be used to predict server

capacity.

The active call count includes requests that have been

received by the method server and are in the process of

being redirected due to server load balancing.


Using the Windchill Adapter Loggers

The following Windchill adapter log4j loggers that can be used to gather

information:

Note: Both the SimpleTaskDispatcher service and SimpleTaskDispatcher servlet

make use of the Windchill log4j wt.adapter.verbose and wt.adapter.exception

loggers to enable their logging. No additional loggers are needed to get this

logging.

An example of using adapter logging is to log the elapsed time spent executing

webjects in the method server. To log this time, set the wt.adapter.verbose logger

to INFO. This can be done in the log4jMethodServer.properties file by setting the

log4j.logger.wt.adapter.verbose property. The following log extract shows the

time spent executing webjects when a user was performing a basic search in

Windchill PDMLink:

2007-09-05 10:14:04,920 INFO [SocketThread3] wt.adapter.verbose - WTAdapter

received trusted username demo


/com/ptc/windchill/enterprise/search/search-SystemWideSearch.xml processing

authenticated request as demo


/com/ptc/windchill/enterprise/search/search-SystemWideSearch.xml setup time 0 msec

Logger Description

wt.adapter.verbose Include information about adapter operations

that do not pertain to any specific webject.

This includes general information about

execution of tasks, information about time to

execute webjects and tasks, information about

user authentication, and so on.

wt.adapter.attribute Include information about the processing of

attributes on objects. Include statistics

associated with the retrieval and translation of

attribute values.

wt.adapter.exception Include stack traces associated with

exceptions that are thrown during execution

of Info*Engine tasks and webjects.

wt.adapter.webject Include detailed information about individual

webject parameters and internal webject

operations.

wt.adapter.trace.timing Include information pertaining to how long

specific actions during webject invocation

take to perform. Most messages issued to this

logger require a log level of TRACE.



invoking task /com/ptc/windchill/enterprise/search/search-SystemWideSearch.xml




Apply-Service processing authenticated request as demo


Apply-Service setup time 0 msec


invoking webject Apply-Service

2007-09-05 10:14:04,920 INFO [SocketThread3] wt.adapter.verbose - Webject delegate

for logical type is com.ptc.core.adapter.server.impl.ApplyServiceWebjectDelegate


Apply-Service complete, 0 msec


Apply-Service request complete, total time 0 msec
































Indexed-Search processing authenticated request as demo


Indexed-Search setup time 0 msec


invoking webject Indexed-Search


for logical type wt.query.template.ReportTemplate is

com.ptc.core.adapter.server.impl.IndexedSearchWebjectDelegate


Indexed-Search complete, 0 msec



Indexed-Search request complete, total time 0 msec




Search-Objects processing authenticated request as demo


Search-Objects setup time 0 msec


invoking webject Search-Objects


for logical type wt.query.template.ReportTemplate is

com.ptc.core.adapter.server.impl.SearchObjectsWebjectDelegate


Search-Objects complete, 6188 msec


Search-Objects request complete, total time 6188 msec




Search-Results processing authenticated request as demo


Search-Results setup time 78 msec


invoking webject Search-Results


for logical type is

com.ptc.windchill.enterprise.search.server.impl.SearchResultsWebjectDelegate


Search-Results complete, 31 msec


Search-Results request complete, total time 109 msec


/com/ptc/windchill/enterprise/search/search-SystemWideSearch.xml complete, 6329

msec


/com/ptc/windchill/enterprise/search/search-SystemWideSearch.xml request complete,

total time 6345 msec


Get-Model complete, 6470 msec


Get-Model request complete, total time 6470 msec

Note: Turning on this type of logging creates very large log files and slows down

the system. Use this method of collecting data for the shortest amount of time

possible.

Viewing Statistics from the Info*Engine Property Administrator

The number of active threads in a Windchill adapter is one of the statistics that can

be viewed from the Info*Engine Property Administrator.

To view the statistics, select the ‘i’ icon next to a Windchill adapter. The statistics

include Active Threads, Handled Requests and Average Response Time. These

statistics are of limited value, however, as they are specific to the adapter socket

(Info*Engine IPC).


Setting Info*Engine Logging

Use the Info*Engine log4j loggers to set the log levels for general logging

purposes.

The following sections provide examples of the log entries that can be generated.

Note: The Info*Engine logs should not normally be enabled; however, when

generating properly scoped resource profiles, it may be useful to record activity in

finer detail.

Info Level Logging

Turning on logging using the com.infoengine.log.info logger generates a large

number of log messages such as the following:

2007-09-12 15:54:40,227 INFO [SocketThread10] com.infoengine.log.info -

Request.validateSignature: request is trusted (super)


SocketAccess.SocketThread.run: processing webject processor request

2007-09-12 15:54:40,352 INFO [SocketThread10] com.infoengine.log.info - invoke

compiled task /wt/federation/QueryPrincipals.xml


JNDIAdapterImpl: Elapsed time to get previously created JNDI context: 0 msec

2007-09-12 15:54:40,352 INFO [SocketThread10] com.infoengine.log.info - Elapsed

time to build directory request: 0 msec


time to search directory: 0 msec


time to process results: 0 msec


com.infoengine.au.delegateprovider.CommandDelegateProvider.getCommandDelegateEntry(

) - commandName: <search-SystemWideSearch>, wcTypeIdentifier:

<WCTYPE|wt.doc.WTDocument>, targetRepository: <jdoe.ptcnet.ptc.com>,

directorySearchBaseURL: <ldap://cn=Manager:[email protected]/o=Application

Services,o=ptc>


com.infoengine.au.delegateprovider.DirectoryBasedCmdDelegateProviderService() -

directorySearchBaseURL: <ldap://cn=Manager:[email protected]/o=Application

Services,o=ptc>


getRepositoryEntry():

<ldap://cn=Manager:[email protected]/dc=jdoe,dc=ptcnet,dc=ptc,dc=com,

o=Application Services,o=ptc??base>

...


getCommandDelegateLDAPEntry():

<ldap://cn=Manager:[email protected]/ptcCommandDelegateName=search-

SystemWideSearch,ptcWindchillTypeId=WCTYPE|wt.fc.Persistable,ptcRepositoryType=

windchill,dc=ptc,dc=com,o=Application Services,o=ptc??base>

2007-09-12 15:54:40,508 INFO [SocketThread10] com.infoengine.log.info - service

"ptcServiceName=com.ptc.ptcnet.jdoe.Windchill,dc=jdoe,dc=ptcnet,dc=ptc,dc=com,

o=Application Services,o=ptc" is a local service


ObjectDestination Host=jdoe.ptcnet.ptc.com, Port=18001,

ClassName=wt.method.WTAdapterImpl,

DN=[ptcServiceName=com.ptc.ptcnet.jdoe.Windchill,dc=jdoe,dc=ptcnet,dc=ptc,dc=com,o=


Application Services,o=ptc], RuntimeName=com.ptc.ptcnet.jdoe.Windchill,

ContentType=null, TTL=15, Expire=1189631380508, Now=1189630480508


compiled task /com/ptc/windchill/enterprise/search/search-SystemWideSearch.xml


compiled task /com/ptc/windchill/enterprise/search/search-getTypeContainer.xml


compiled task /com/ptc/windchill/enterprise/search/search-IndexSearch.xml


compiled task /com/ptc/windchill/enterprise/search/search-Search.xml


compiled task /com/ptc/windchill/enterprise/search/search-SearchResults.xml


SocketAccess.SocketThread.run: sending response


SocketAccess.SocketThread.run: completed request

Statistic Level Logging

Turning on logging using the com.infoengine.log.stat logger produces messages

such as the following:

2007-09-12 15:54:40,164 INFO [RMI TCP Connection(741)-132.253.49.121]

com.infoengine.log.stat - [timestamp: 2007/09/12-15:54:40.164] [client:

132.253.49.121] [duration: 15] [redirects: 0] [active: 1] [invoked:

wt.preference.PreferenceService2Fwd.getValue] [result: java.lang.String] [detail: ]

[user: demo]

2007-09-12 15:54:40,352 INFO [SocketThread10] com.infoengine.log.stat - processing

time, webject=Map-Credentials, msec=0


time, webject=Query-Objects, msec=0






time, webject=Apply-Service, msec=0






time, webject=Call-Task, msec=47


time, webject=Create-Group, msec=0




time, webject=Indexed-Search, msec=0






time, webject=Search-Objects, msec=578







time, webject=Search-Results, msec=16




time, webject=Dispatch-Tasks, msec=813




wt.preference.PreferenceService2Fwd.getValue] [result: java.lang.String] [detail: ]

[user: demo]

2007-09-12 15:54:41,727 INFO [SocketThread10] com.infoengine.log.stat - [timestamp:

2007/09/12-15:54:41.727] [client: 132.253.49.121] [duration: 1500] [redirects: 0]

[active: 0] [invoked: ] [result: com.infoengine.object.IeCollection] [detail:

com.infoengine.object.factory.Group@ce2250] [user: demo]




wt.preference.PreferenceService2Fwd.getValue] [result: java.lang.Boolean] [detail:

] [user: demo]

As can be seen from the examples, info and statistic level logging are highly

verbose. The statistic logging also includes RMI calls (handled by the standard

Windchill remote method server), Info*Engine IPC, and SOAP calls.

Note: Info*Engine statistic logging does not log any information about RMI, it

logs only Info*Engine related statistical messages.

Windchill Queue Logging

By using queues, the background method server carries out operations without

being directly connected to an end user. It executes periodic (time-based)

activities, as well as operations that are triggered by a user operation, but for

which the user does not wait. For example, an action is performed that promotes

an object to a new life cycle state. The change to this life cycle state may trigger

additional processing that is not directly related to the user’s actions. These

activities should be carried out in the background.

The Windchill background method server is essentially identical to a regular

method server except that the server manager does not forward RMI clients to it.

All the diagnostic properties described for the method server apply equally to the

background method server.

Additionally, the following Windchill log4j loggers can be helpful in monitoring

throughput in a background method server:

wt.queue.ProcessingQueue.<queue_name>

wt.queue.ScheduleQueue.<queue_name>

where <queue_name> is the name of the queue that is of interest. You can set

these loggers to logger values such as DEBUG, TRACE, and so on. The different


logging levels provide different amounts of detail about a queue, with the TRACE

value producing the most detail.

Windchill Method Server Service Diagnostics

The diagnostics available for low-level activity within the method server includes

logging for the Persistence Manager, as described in the following section.

Persistence Manager (POM) Logging

By far the most frequent cause of unacceptable performance has been inefficient

database access. Such problems are generally the responsibility of the application

programmer or the database administrator to resolve. However, in some cases

there are opportunities to resolve such problems by tuning application properties.

This can occur when a fixed size application data cache has been sized too small.

There are two types of cache to consider:

• JDBC Statement Cache at the Persistence Manager

• Application Services Data Cache (CacheManager)

The following sections describe these types of cache, and describes the Windchill

log4j loggers and properties that can be used to manage them.

JDBC Statement Cache

The wt.pom.statementCache.summaryInterval property controls the reporting

frequency of the JDBC statement cache metrics. When being used, these metrics

are logged to the method server log file by default. Additionally, using the

Windchill log4j wt.pom.statementCache logger enables you to configure the log

file, format, and so on.

The size of the JDBC cache can influence Windchill performance due to the

overhead of preparing versus reusing cached JDBC statements. It is a fixed sized

cache using a least recently used algorithm when replacing entries due to

overflow. The statement cache summary shows the hit/miss statistics and is useful

in determining its efficiency. Ideally the ratio of hits to misses should be 90% or

more.

The wt.pom.statementCache.summaryInterval value specifies the number of

cache lookups between each summary. The default is 2000. A value of 0 for this

property will disable the summary.

Be aware that there is a separate statementCache for each of the pooled database

connections in a method server. The cache objects are identified by a unique

string resembling ‘wt.pom.StatementCache@3f5841’.

For example the following StatementCache summary tells us that the cache is

sized for 25 PreparedStatements, and all 25 slots are currently filled. Of the total

cache lookups (71396) only 3452 matches were found and 67854 lookups failed


to find suitable cached statements. The efficiency of this cache is (3452/71396) *

100 ~= 5%. The cache is clearly undersized.

StatementCache: wt.pom.StatementCache@3f5841[size=25, count=25, hits=3452,

misses=67854, aged=65854]

The StatementCache size is governed by property wt.pom.statementCacheSize in

db.properties, as described in the Properties Related to the JDBC Statement Cache

section of the Application Tuning chapter.

When analyzing a method server log file, look for groups of StatementCache

summary lines that have the same thread name and StatementCache id.

Remember that each time a summary line is written for a StatementCache it

means that 2000 JDBC statements were executed. If multiple consecutive

summaries for a single cache show the same thread name it means that thread

executed many thousands of database accesses. Such transactions can be

problematic as they not only require significant CPU time but also can require

excessive heap space. Having multiple such transactions can lead to server

saturation or OutOfMemoryErrors thereby increasing average response times for

all method calls.

Additional SQL Statement Logging

To enable diagnostic logging on the StatmentCache, use the Windchill log4j

wt.pom.sql logger. Be aware that this will generate a large volume of log entries.

Stack Trace Profiling

Since JDBC statement execution is so frequently the major component of both

CPU and elapsed time, it is often useful to profile the SQL statements and the

associated Java call stacks. The Windchill Profiler can be used for this purpose by

enabling profiling on the SQL operation. Use of the Windchill Profiler is

described in the Windchill Customizer’s Guide.

Windchill CacheManager

The primary method employed to minimize database queries is the use of data

caches in the method server. In order to guarantee cache consistency across

multiple method servers the Windchill CacheManager mechanism is used.

There are essentially two types of data managed by the CacheManager:

• The first type is data that are modeled as extending

wt.fc.CachedObjectReference. Data of this type are managed by

wt.fc.cache.StandardObjReferenceCacheService.

• All other types are maintained by separate subclasses of CacheManager.

The objective of each CacheManager instance is to maintain frequently accessed

data in the method server to minimize database access. The caches are not

generally used to hold all instances of a given class; only what is called the

working set is cached. The working set is the subset of the most recently accessed


data items. The assumption being that recently accessed data are likely to be

needed again in the near future.

The goal is to ensure that the caches are sized for maximum efficiency. This

requires that they be large enough to maintain the working set without consuming

too much heap.

In order to monitor cache efficiency it is necessary to monitor the hit and miss

ratios through logging activity. The following sections provide information about

what properties to use and how to monitor the logging activity.

Cache Summaries

Reporting cache summaries for all subclasses of wt.cache.CacheManager is

possible by setting the wt.cache.CacheManager.summaryInterval property to a

non-zero value in wt.properties. A non-zero value specifies the number of cache

lookups in each cache instance between summaries. PTC suggests that the interval

be set no less than 10000 to minimize the logging overhead.

Alternatively, specific subclasses of CacheManager can be configured for

logging. For example to monitor the WTPrincipalCache activity, add the

following property to wt.properties:

wt.org.WTPrincipalCache.summaryInterval=1000.

For a list of CacheManager subclasses and their corresponding logging and tuning

options, see wt.properties in the Application Tuning chapter.

Object Reference Cache

Object references that are modeled as subclasses of CachedObjectReference

automatically utilize wt.fc.cacheReferenceCache when the reference needs to be

inflated. The ReferenceCache implementation allows the configuration of a

separate cache for each such referenced class.

For example, the following extract from service.properties shows that the

ReferenceCache is subdivided into separate caches for the following:

• wt.admin.AdministrativeDomain

• wt.inf.container.WTContainer

• wt.inf.team.ContainerTeam

• wt.workflow.engine.WfProcess

• wt.Folder.Cabinet

• wt.Folder.SubFolder

• one additional cache for all the other classes

The default size for all caches is specified as 200 except for the WfProcessCache

(which is set at 50) and the SubFolderCache (which is set at 500).

<Resource context="default" name="ObjectReferenceCacheTable">


<Option requestor="wt.fc.Persistable" resource="DefaultCache" selector="null"/>

<Option requestor="wt.admin.AdministrativeDomain" resource="DomainCache"

selector="null"/>

<Option requestor="wt.inf.container.WTContainer" resource="ContainerCache"

selector="null" order="5"/>

<Option requestor="wt.inf.team.ContainerTeam" resource="ContainerTeamCache"

selector="null"/>

<Option requestor="wt.workflow.engine.WfProcess" resource="WfProcessCache"

selector="null"/>

<Option requestor="wt.folder.Cabinet" resource="CabinetCache" selector="null"/>

<Option requestor="wt.folder.SubFolder" resource="SubFolderCache"

selector="null"/>

<Option selector="Size" requestor="null" resource="200"/>

<Option selector="WfProcessCache.Size" requestor="null" resource="50"/>

<Option selector="SubFolderCache.Size" requestor="null" resource="500"/>

<Option selector="ReportInterval" requestor="null" resource="0"/>

</Resource>

Periodic reporting of these caches may be enabled globally or individually. In

order to set the reporting interval for all caches, find the selector=”ReportInterval”

and set the corresponding entries resource to a non zero value.

Similarly, if you want to collect statistics for an individual cache, add the

following:

<Option selector="WfProcessCache.ReportInterval" requestor="null" resource="50"/>

The list of ObjectReferences that are modeled as subclasses of

CachedObjectReference are:

wt.inf.container.WTContainerRef

wt.inf.container.WTContainerTemplateRef

wt.inf.template.WTContainerTemplateMasterReference

wt.inf.team.ContainerTeamReference

wt.admin.AdminDomainRef

wt.project.ProjectReference

wt.team.TeamTemplateReference

wt.team.TeamDistributionListReference

wt.lifecycle.LifeCycleTemplateReference

wt.lifecycle.LifeCycleTemplateMasterReference


wt.content.DataFormatReference

wt.folder.CabinetReference

wt.folder.SubFolderReference

wt.epm.EPMAuthAppVersionRef

wt.vc.views.ViewReference

wt.workflow.definer.WfProcessTemplateMasterReference

wt.workflow.definer.WfNodeTemplateReference

wt.workflow.definer.WfContainerTemplateReference

wt.workflow.engine.WfContainerReference

wt.workflow.templates.TaskFormTemplateMasterReference

wt.workflow.templates.TaskFormTemplateRef

Oracle Diagnostics

The Oracle database server has many tools for gathering performance diagnostics.

At a minimum the performance analyst should collect the CPU time consumed by

the Oracle process as reported by the operating system. Once a high level resource

profile has been collected it may reveal that I/O is a significant component of the

response time. Oracle I/O can be a major bottleneck and so it is essential to

understand how to enable and collect Oracle’s diagnostic data to determine which

I/O operations, if any, can be tuned.

Oracle Tracing

Copy and paste the following script to a file called trace_on.sql. Replace the user

name (MyUserName) with the value of property wt.pom.dbUser from

db.properties.

trace_on.sql

set pagesize 0

set linesize 150

set verify off

spool on.sql

select 'execute dbms_system.set_ev('||sid||','|| serial#||',

10046, 8, ' || ''''''|| ');' from v$session where

username='MyUserName';

spool off

@on


Copy and paste the following script to a file called trace_off.sql. Replace the user

name (MyUserName) with the value of property wt.pom.dbUser from

db.properties.

trace_off.sql

set pagesize 0

set linesize 150

set verify off

spool off.sql

select 'execute dbms_system.set_ev('||sid||','|| serial#||',

10046, 0, ' || ''''''|| ');' from v$session where

username='MyUserName';

spool off

@off

To enable SQL tracing with the method server already running, execute the

trace_on script as the sys user. You will need the sys password to execute. For

example:

>sqlplus /nolog

SQL*Plus: Release 10.2.0.2.0 - Production on Wed Apr 25 13:17:56 2007

Copyright (c) 1982, 2002, 2005, Oracle. All rights reserved.

SQL> connect sys/<sys_password> as sysdba;

Connected.

SQL> @trace_on

execute dbms_system.set_ev(13,39621, 10046, 8, '');

etc, etc

SQL>quit

To disable SQL tracing execute the trace_off script. For example:

> sqlplus /nolog

SQL*Plus: Release 10.2.0.2.0 - Production on Wed Apr 20 13:26:21 2007

Copyright (c) 1982, 2002, 2005, Oracle. All rights reserved.

SQL> connect sys/<sys_password> as sysdba

Connected.

SQL> @trace_off

execute dbms_system.set_ev(13,39621, 10046, 0, '');

etc, etc

SQL> quit

Locate the directory that contains the trace files. This directory can be found by

using the query:

select NAME,VALUE from v$parameter where name='user_dump_dest';


Use tkprof to interpret the output file:

tkprof <tracefile> <outputfile> explain=username/password sys=no sort = exeqry,

fchqry, execu, fchcu

Where:

<tracefile> is the name of the trace file Oracle generated.

<outputfile> is the name of the file in which the results of the analysis should

be placed.

explain=username/password uses the user name and password of the

wt.pom.dbUser user.

Aphelion Diagnostics

By default, Aphelion is configured so that the requests it processes are not logged.

If you encounter problems, you can change the configuration of Aphelion to log

all requests and responses.

Changing the loglevel in <Aphelion>/usr/var/lde/PTCLdap_lde.conf from 0 to

256 causes Aphelion to log all requests and responses to the following file:

<Aphelion>/usr/var/lde/PTCLdap/lde.log.requests

where <Aphelion> is the Aphelion installation directory.

You can use this log to determine the number of LDAP requests, the time taken to

execute each request, and the response to the request.

The following example shows two log entries for a single request when the log

level is set to 256. The first entry is a search (SRCH), the second entry is the

associated result (RESULT). Use the timestamps on the two log entries to

measure elapsed time spent processing the request.

2007/06/05 00:17:18.801-0600 R (84fd08c0/1448/1/2) conn=157 op=305 SRCH

base="CN=WINDCHILL_8.0,CN=APPLICATION SERVICES,O=PTC" scope=2

filter="(objectClass=PTCAPPLICATIONPROPERTIES)"

2007/06/05 00:17:18.816-0600 R (84fd08c0/1448/1/2) conn=157 op=305 RESULT err=0

tag=101 nentries=8 searched=720 dereferenced=0 bases=1 index1=objectClass/eq/0

For a full description of the log format, see the Aphelion Administration Guide.

Note: Unless you are actively collecting Aphelion diagnostic data, PTC

recommends that the log level be set to 0.

The log level can be set using the Aphelion Web Tools or by manually modifying

the loglevel property in the PTCLdap_lde.conf file that is in the Aphelion

installation directory. Be aware that any changes that are made to an installed

Aphelion are overwritten if Aphelion is reinstalled.

After changing the property, Aphelion must be stopped and restarted for the

property to take effect.



4Application Tuning

This chapter contains information about the various tuning properties in each tier

of the application.

Topic Page

HTML Browser Tuning.......................................................................................4-2

Java Plug-in and Java Application Tuning..........................................................4-2

Web Server Tuning for Apache 2........................................................................4-4

Servlet Engine Tuning.........................................................................................4-5

Windchill Servlet Tuning ....................................................................................4-7

Windchill Method Server Tuning......................................................................4-12

Background Method Server Tuning ..................................................................4-28

4-1

HTML Browser Tuning

Windchill uses HTTP to upload content. Some versions of the Microsoft Internet

Explorer browser exhibit low bulk HTTP upload performance. This issue occurs

because the default Winsock Send buffer is 8 kilobytes (KB), and, therefore,

Internet Explorer supplies the data in 8-KB chunks. On an average network, this

equals approximately 80 KB per second (KBps), regardless of network

bandwidth.

For Windows clients using Microsoft Internet Explorer 6.0, PTC suggests that the

Windows registry value for SocketSendBufferLength be set to 16384 (16-KB

Buffer) as described in the following Microsoft Knowledge Base article:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;329781

Browser Cache Settings

Ensure that the client browser cache is configured to read objects from the local

disk where appropriate.

For Microsoft Internet Explorer 6.0 and 7.0, select Tools > Internet Options.

From the General tab, click the Settings button under Temporary Internet Files.

Then select Automatically for when to check for newer versions of stored pages.

For Mozilla 1.7 browsers, select Edit > Preferences. Then expand the Advanced

category and then click Cache. From the Cache settings on the right, select the

appropriate setting, such as When the page is out of date.

Note: To use the Aphelion Web tools, the required browser setting is not the

same as the setting recommended for general Windchill use. Browsers used for

the Aphelion Web tools must be configured such that a fresh copy of the Web

page is obtained from the server at each reference.

Java Plug-in and Java Application Tuning

The following sections describe the tuning that is recommended.

TCP/IP Tuning

Use the following properties in the wt.properties file for TCP/IP tuning:

wt.rmi.socketSendBufferSize

wt.rmi.clientSocketFactory

wt.rmi.socketReceiveBufferSize

Java clients that communicate with a Windchill method server over a high

bandwidth, high latency network (or Long Fat Network) may not make efficient

use of the available bandwidth. A symptom of inefficient bandwidth use is when

Java clients seem slow when they are uploading content files to the server.

Network packet analysis can reveal that the client sends data in blocks of 8KB


http://support.microsoft.com/default.aspx?scid=kb;EN-US;329781

even when the receiving socket window will accommodate several such blocks.

This generally happens when the client operating system default send buffer is

8KB.

By configuring the Java client to use the wt.util.WrappedRMISocketFactory, it is

possible to override the client’s socket send buffer size to use the available

bandwidth on a high latency network more effectively.

For example, to set the client socket send/receive buffer sizes to 64KB, add the

following properties to wt.properties:

wt.rmi.clientSocketFactory=wt.util.WrappedRMISocketFactory

wt.rmi.socketSendBufferSize=65535

wt.rmi.socketReceiveBufferSize=65535

In some cases, however, the plug-in throws an access exception when it tries to set

the socket factory. When this is the case, the only way to increase the client socket

send buffer size is to edit the operating system default.

64KB is generally the maximum recommended socket send/receive buffer size.

RFC 1323 describes the TCP Window Scaling feature that enables larger

send/receive windows.

The RMI server socket receive buffer size can be increased beyond 64KB, if

required, using this property:

wt.rmi.serverSocketReceiveBufferSize

Refer to the RFC and relevant client and server operating system documentation

for more information on configuring TCP Window Scaling.

JAR File Tuning

During applet startup, the Plug-in JRE tries to load classes from the client JAR

files from the local JAR cache. However, for resources that are not found in the

JAR cache, the JRE attempts to load over the network. Loading over the network

can potentially incur significant delays. For information on optimizing the client

JAR files, see the Windchill Customizer’s Guide.

Plug-in Heap Settings

With applets that are used to display large amounts of data such as large

assemblies, it is likely that performance is affected by excessive garbage

collection. In such cases, PTC recommends that you use the Plug-in control panel

to configure a larger heap. This is achieved by adding the –Xms and –Xmx

command line options to the Java Runtime Parameters tab.

The verbosegc command line option can also be added to monitor garbage

collection activity.

The Plug-in Java Console can also be used to track heap size and garbage

collection activity.

Application Tuning 4-3

Web Server Tuning for Apache 2

The following sections describe compression information and directives relevant

to tuning Apache 2.

Compressing File Content

The PTC-supplied version of the mod_deflate file for Apache enables

compression of all MIME types except the following:

GIF

JPEG

JAR

ZIP

GZ

PDF

This list of exceptions can be modified if desired; however, be aware that some

popular browsers do not handle the compressed content for these MIME types.

For example, compressing PDFs can actually cause PDF readers to fail; therefore,

you should always exclude compression for .pdf files.

Additionally, the version of mod_deflate supplied by PTC includes a special patch

that allows the code to dynamically exclude some Windchill solution responses

from compression. This allows some Windchill pages to have greater control over

when they flush portions of the response, for instance in pages with lengthy

computations.

The Apache version shipped by Hewlett Packard includes the special PTC patch.

Note: Some proxy servers can negate the compression advantage provided by

mod_deflate. In many cases, the Web server should be capable of determining if

the user can accept compressed content; however, some proxy servers are not

aware of handling compressed content and, as a result, the content sent through

the proxy server is not compressed. This can lead to users experiencing

performance related problems, especially on a WAN.

To verify whether or not they can receive the compressed content, users can run

the <Windchill>/infoengine/jsp/examples/EchoRequest.jsp page. In the request

information from this page, a header called Accept-Encoding should be listed that

is set to "gzip, deflate". If this header is missing or empty on the server, it is

highly likely that the proxy cache is disabling the compression feature for clients.

Additionally, the response header Content-Encoding identifies if the page was

actually compressed.

You can also validate that compression is taking place by viewing the

compression ratio at the end of lines in the deflate.log file. By default, PTC does

not enable this logging. You can turn on the logging by including additional lines

in the Apache deflate.conf file as described in the Apache mod_deflate Logging

section.


Of interest are any HTML, JSP, CSS, JS files and the associated compressed size.

The software does not compress images, ZIP, TAR, or JAR files because their

native format is already compressed.

For information on enabling compression for MIME types, see the Apache

documentation at:

http://httpd.apache.org/docs-2.2/mod/mod_deflate.html

Tuning Directives

Use the following directives for tuning Apache:

Servlet Engine Tuning

This section has information about Tomcat and WebSphere settings that can be

useful in tuning.

Tomcat 5.5 Tuning

This section describes the properties used to limit the number of concurrent client

requests executed by Tomcat through the server.xml file. This can limit

transaction throughput and help prevent server saturation.

Additionally, the section has information about changing the session timeout

value and how to monitor garbage collection to ensure that the Tomcat heap size

is set correctly.

Directive Description

EnableMMAP Controls whether memory-mapping is used to deliver

files (assuming that the underlying Operating System

supports it). The default is on; turn this off Windchill is

running from NFS-mounted file systems. On some

systems, turning it off (regardless of file system) can

improve performance; for details, see:

http://httpd.apache.org/docs-2.2/mod/core.html#ena

blemmap

EnableSendfile Controls whether the sendfile kernel support is used to

deliver files (assuming that the Operating System

supports it). The default is on for UNIX and off for

Windows. Turn this directive off Windchill is running

from NFS-mounted file systems.





Modifying server.xml to Limit Concurrent Client Request

The Tomcat Coyote/JK2 AJP 1.3 connector is used by default. You can edit the

properties for this connector in <Tomcat>/conf/server.xml to throttle client

requests.

The following block in the server.xml file controls the properties of this

connector:





<Connector port="8010"

minSpareThreads="16" maxSpareThreads="40" maxThreads="320" acceptCount="0"

tomcatAuthentication="false" useBodyEncodingForURI="true" URIEncoding="UTF-8"

enableLookups="false" redirectPort="8443"

protocol="AJP/1.3" />

This allows a maximum of 75 requests to be executing concurrently and a further

100 requests to be queued. After the queue is full, newly arriving requests will be

returned to the client with a 503 (Out of Resources) status code.

The following table has details about the connector properties:

If you believe that there is a single-process bottleneck that could be improved, you

can pursue the possibility of using multiple Tomcat servlet engines to improve

performance; however, the testing that PTC has done does not confirm that setting

Thread Pool

Properties Description Default

maxThreads The maximum number of request processing threads to

be created by this connector, which therefore

determines the maximum number of simultaneous

requests that can be handled.

320

minSpareThreads The number of request processing threads that will be

created when this connector is first started. The

connector also makes sure it has the specified number

of idle processing threads available. This attribute

should be set to a value smaller than that set for

maxThreads.

16

maxSpareThreads The maximum number of unused request processing

threads that will be allowed to exist until the thread

pool starts stopping the unnecessary threads.

40

acceptCount The maximum queue length for incoming connection

requests when all possible request processing threads

are in use. Any requests received when the queue is full

are refused. The default value is 10.

0


up multiple Tomcat servlet engines will improve performance. For additional

information, consult the documentation that is available with Tomcat.

Modifying web.xml for Session Timeout

The session timeout allows you to specify how long a session can remain inactive

before it is timed out. The default session timeout is 30 minutes.

You can modify the session-timeout value in the <Tomcat>/conf/web.xml file to

change the default.

Modifying Servlet Engine Heap Size

The servlet engine default Java heap size may need to be increased. The default

maximum heap size is set at 128MB. It is likely that 128MB will not be sufficient

for production systems. For additional information about setting the heap size, see

the Info*Engine Installation and Configuration Guide.

If the CPU time for the Tomcat process is consistently high, PTC recommends

that either the verbose:gc or the -Xlog:gc command line modifiers are added to

<Tomcat>/bin/wttomcat_start script so that the frequency and duration of garbage

collection can be monitored and tuned. For information about garbage collections,

see Java Garbage Collector Tuning.

WebSphere and Embedded HTTP Server

Refer to the online documentation for the WebSphere performance tuning at:

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com

.ibm.websphere.base.doc/info/aes/ae/welc6toptuning.html

Windchill Servlet Tuning

The following properties can be used for tuning the Windchill servlet.

com.ptc.netmarkets.clientCacheLimit

The clientCacheLimit affects how many UI models are cached per user session in

the servlet engine. When a user goes to a page for the first time, the page’s table

model is cached so that the next time that page needs to be rendered by either the

user coming back to it from another page, or by invoking an action on the page

such as Delete, Copy, Paste, or Cut, it can be recalled without accessing the

method server. Response times may be greatly improved. The cache may update

itself with the result of user actions.

The property is read from wt.properties and the default value is 3.

com.ptc.netmarkets.clientTabCacheLimit

The clientTabCacheLimit specifies the number of tab models cached in the servlet

engine's user session, per user. These are pretty light weight so a higher/lower

number will not effect memory too much. Each page has one tab model so it will

cache the last 5 pages worth of tabs.


http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.base.doc/info/aes/ae/welc6toptuning.html

The property is read from wt.properties and its default value is 6.

com.ptc.netmarkets.clientCacheTimeOut

The clientCacheTimeOut affects how long a UI model cached in the servlet

engine's user session will last before it is considered stale.

The property is read from wt.properties and its default is 10 minutes (600000 ms)

com.ptc.core.ca.co.common.prefs.session.cache

The DCA tier can cache user preferences per servlet session. This property

controls whether this cache is enabled or not. The default value is true (cache is

enabled). It only affects DCA based UIs.

The memory footprint in the servlet engine VM for the preference cache might be

significant.

com.infoengine.getRemoteHost

When using the Info*Engine taglib directive embedded in JSP, an Info*Engine

ServerGroup object is added to the servlet session. One of the fields on the

ServerGroup object is the name of the remote host where the request originated.

This causes the servlet engine to perform IP address to host name lookup using

DNS (or some other lookup service). The execution of the name lookup can cause

a bottleneck in the system if the name server fails to respond quickly.

This property can be set to false to skip host name lookup. The default value for

the property is true. The best way to diagnose this problem is to generate thread

dumps in Tomcat and look for threads that show the following method at the top

of their call stacks:

java.net.InetAddressImpl.getHostByAddr(Native Method)

If several consecutive thread dumps show threads waiting in getHostByAddr and

also com.infoengine.jsp.taglibs.IeTagBase.initInfoEngine appears lower in the

call stack, then set getRemoteHost to false.

To set this property to false:

1. From the Info*Engine Property Administrator and from the list of services,

select the service that has the suffix .servlet (the Info*Engine Servlet).

2. In the property editor for the service, scroll to the ‘Additional Properties’

section.

3. In the text field labeled Property, specify the property name as <runtime

service name of servlet>.getRemoteHost (the runtime service name is found

near the top of the property editor). Do not include the string

‘com.infoengine’ in the property name. In the ‘Value’ text field type false.

4. When finished, click Add and then OK.


com.infoengine.maxConnectionCacheSize

Info*Engine maintains a client side cache of Info*Engine IPC connections to the

relevant task/webject processors. Cached connections allow efficient reuse of

resources across multiple webject/task invocations and servlet requests. The

default cache size is 50. Because the client side pools connections, a client will

hold onto a server side thread as long as it is still using it. The server side thread

will continue processing requests until the client closes the connections or an IO

Exception occurs.

The cache does not act as a throttle on requests. If the cache is full of busy

connections and a further connection is required, then the connection will be

opened. However, as connections are closed they may be discarded instead of

being placed in the cache if it is full.

This property can be added via the Info*Engine Property Administrator to the

Info*Engine servlet. Ensure that the property name entered comprises the

runtime_service_name as a prefix, for example:

com.ptc.ptcnet.jdoe3l.servlet.maxConnectionCacheSize

com.infoengine.maxConnectionAge

The maxConnectionAge property is closely related to the

maxConnectionCacheSize. It is used to close down cached client connections a

configurable number of seconds after being put in the connection cache. The

default value is 60 seconds.

Info*Engine only looks for "stale" client connections when requesting a free

connection. As there is no polling thread, connections may remain in the pool

longer than the maximum age, up until the time the next connection is requested

for a particular service name.

This property can be added via the Info*Engine property administrator to the

Info*Engine servlet. Ensure that the Property name entered comprises the

runtime_service_name as a prefix, for example:

com.ptc.ptcnet.jdoe3l.servlet.maxConnectionAge

<runtime service name>.taskProcessor.taskFileTimeToLive

Sets the time to live on compiled tasks to avoid checking file timestamps for task

invocation. The value is interpreted as a number of minutes. Set it to a negative

value to skip the check entirely causing it only to occur the first time the task is

invoked (task modification/recompilation requires a restart). Set to another value

will cause the task compiler to see if a task needs to be recompiled based on the

property value. If the property is not set then a task compiler will check the

timestamps on each invocation.

This property can be added via the Info*Engine property administrator to the

Info*Engine servlet. Ensure that the Property name entered comprises the

runtime_service_name as a prefix , for example:

com.ptc.ptcnet.jdoe3l.servlet.taskProcessor.taskFileTimeToLive


com.ptc.core.ca.co.common.prefs.session.cache

DCA can either cache user preferences in the servlet engine session cache or

request them from the method server repeatedly. This property governs whether

the preferences are cached for the duration of a servlet session. The default value

is true. There is a potential that preference values could get out of sync with the

values in the RDBMS. If this happens, the user should close and reopen a new

browser session to ensure that the preferences are up to date.

com.ptc.core.ca.web.client.element.factory.maxFrameCount

Determines the size of the frame cache per user session. (default is 10)

com.ptc.core.ca.web.client.gw.sessionTime

Overrides the servlet container session timeout for DCA pages. Each servlet

engine provides a property setting that you can use to set the default session

timeout which defines when to time out inactive sessions.

The default value for this property is 3600 seconds; you can change this value by

setting a value for the property in wt.properties.

PTC recommends that you set the value to the value you have set for the servlet

engine session timeout. By default, the Tomcat session timeout is 1800. For

Tomcat details, see Modifying web.xml for Session Timeout.

Tomcat Servlet Session Activation/Passivation

By default Tomcat uses its "StandardManager" to manage servlet sessions. This

manager provides basic handling of servlet sessions including session expiration

after a configurable period of inactivity, saving sessions to disk upon a normal

shutdown and restoration of such sessions upon startup. The save/restore handling

allows Tomcat to be briefly taken offline without session state loss.

Tomcat also provides a "PersistentManager" which allows more sophisticated

handling of servlet sessions. The PersistentManager allows less active servlet

sessions to be swapped from memory to disk when a configurable number of

active, in-memory sessions is exceeded. This is referred to as "passivation". Such

sessions can then be swapped back into memory if required by a later request

made by the same session. This is referred to as "activation". The

PersistentManager can also force sessions to be passivated strictly on the basis of

inactivity time regardless of the number sessions in memory. It can be useful in a

cluster to passivate to a shared disk and thus reduce the session affinity time

period required by the cluster load balancer.

Note: PTC has modified the standard Tomcat distribution to enhance

passivation/activation performance. It is also worth noting that the Tomcat

PersistentManager is still considered ‘experimental’ and so may not be totally

stable in a production environment.

To use the PersistentManager, edit the following file:

<Tomcat>/conf/Catalina/localhost/app-<WebAppName>.xml


Change the Manager element as shown in bold text:

<?xml version="1.0" encoding="UTF-8"?>

<Context path="/WebAppName" docBase="WebAppName"

debug="0" reloadable="false">

<Resources className="com.ptc.tomcat5.WebAppWithDocBaseDirContext"/>

<Loader className="com.ptc.tomcat5.WebAppWithDocBaseLoader"

loaderClass="com.ptc.tomcat5.ExtendedWebAppClassLoader"/>

<Logger className="org.apache.catalina.logger.FileLogger"

prefix="localhost_WebAppName_log." suffix=".txt"

timestamp="true"/>

<Manager className="org.apache.catalina.session.PersistentManager"

maxActiveSessions="150" minIdleSwap="90" maxIdleSwap="480">

<Store className="org.apache.catalina.session.FileStore"

directory="<mount_point>/persistent-manager/Windchill”

debug=”1” />

</Manager>

</Context>

To ensure that all Windchill web applications installed against the given Tomcat

always use the PersistentManager, edit the following file and add the Manager

element described in the previous app-<WebAppName>.xml update:

<Tomcat>/webAppTemplate.xml

The attributes used in the previous example have the following meanings:

Attribute Meaning

maxActiveSessions The maximum number of active, in-memory sessions

allowed before the session manager starts to attempt to

passivate sessions on this basis.

minIdleSwap The minimum idle time (in seconds) before a session can

be passivated to satisfy the maxActiveSessions

constraint.

maxIdleSwap The idle time (in seconds) after which a session will be

passivated purely for being too old. Note that session

passivation is done in a periodic background thread and

thus sessions will not be passivated precisely after

maxIdleSwap seconds of inactivity. Thus it is advisable

that cluster affinity still be at least 75 seconds more than

maxIdleSwap even when the maxIdleSwap plus shared

disk approach is used.

debug Setting the debug flag on the FileStore class causes a one

line log message to be written by the FileLogger

whenever a session is saved or reloaded.


The following is an example log message that is returned when you set debug="1"

on FileStore class:

2007-04-12 13:45:05 fileStore[/Windchill]: Saving Session

1B744686373C81FD24E67BEE324F05DA to file

z:\tomcat5\webapps\persistent-manager\Windchill\1B744686373C81FD24E67BEE324F05DA.se

ssion

2007-04-12 13:48:47 fileStore[/Windchill]: Loading Session

1B744686373C81FD24E67BEE324F05DA from file

z:\tomcat5\webapps\persistent-manager\Windchill\1B744686373C81FD24E67BEE324F05DA.se

ssion

Windchill Method Server Tuning

Tuning the method server can involve setting appropriate property values in the

following property files:

wt.properties

service.properties

db.properties

Note: Use the xconfmanager utility when modifying property files. For

information about using this utility, see the Windchill System Administrator’s

Guide.

The following sections describe general information about setting cache sizes and

specific information for the properties related to tuning the method server in the

property files. Additionally, you may want to change values in the Windchill

adapter to tune the method server. Windchill adapter properties are described in

the Windchill Adapter Properties section.

Setting Cache Sizes

The various Windchill data caches should be sized large enough to avoid repeated

RDBMS queries.

Some of the caches support periodic summaries that show the cumulative number

of hits and misses on cache lookups. A high ratio of misses to hits generally

means the cache is sized too small. Use the properties described in the next

section to turn on periodic logging.

Note: The maximum size for any single cache is 715827882. However, you

should size each cache to handle the only the working set.

The working set comprises recently accessed persistent data. Such data is

maintained in memory cache with the expectation that it will be accessed again

shortly. It is often impractical to cache all instances of persistent classes;

therefore, fixed sized caches are used to maintain just the most recently used data.

For example, you can consider the set of users that have accessed Windchill in the


past 10 minutes to be in the working set since they are more likely to use

Windchill services than users who have not used Windchill in several hours.

wt.properties

The relevant method server tuning properties in the wt.properties file include the

following:

wt.cache.size.IBAModelImplementation$DefaultIBATypeCache

Default size is 500.

The type cache should be sized to the number of soft type and soft attribute (IBA)

definitions in the working set. The total number of type definitions can be found

by querying the following tables in the RDBMS

sql> select count(*) from TimestampDefinition

sql> select count(*) from IntegerDefinition

sql> select count(*) from RatioDefinition

sql> select count(*) from UnitDefinition

sql> select count(*) from URLDefinition

sql> select count(*) from ReferenceDefinition

sql> select count(*) from FloatDefinition

sql> select count(*) from StringDefinition

sql> select count(*) from BooleanDefinition

Periodic logging is available by setting the following property to a value greater

than 0 (for example, 10000):

com.ptc.core.meta.server.impl.IBAModelImplementation$DefaultIBATypeCache.

summaryInterval

wt.cache.size.TypeBasedCompositeRuleSelector$Cache

The number of Type Based Composite Rules that are likely to be in the working

set can be estimated from the number of Object Types, Rule Types, for example,

INIT, COPY, and the number of Containers (Projects, Products, Libraries) in use

at one time (see Object Initialization Rules Administrator).


Periodic logging is controlled by the property:

com.ptc.core.rule.server.delegate.selector.TypeBasedCompositeRuleSelector$Cache.

summaryInterval


wt.cache.size.AclCache

The number of Policy based access control lists that can be cached in the servers.

The default is 200.

The total number of Policy access control lists can be found with the following

SQL statement:

sql> select count(*) from policyacl


wt.access.AclCache.summaryInterval

wt.cache.size.RoleAccessCache

This cache maintains com.ptc.netmarkets.roleAccess.UIAccess objects that are

used when determining the visibility of UI objects based on the user’s role

assignments.

The default value is 1000. PTC recommends increasing this value to 3000.


com.ptc.netmarkets.roleAccess.UIAccess.summaryInterval

wt.admin.cache.maxDomains

This specifies the number of Administrative Domains cached in the method

server.

The default is 2000.

Which is probably adequate for most systems.

The total number of Administrative Domains can be found with the following

SQL statement:

sql> select count(*) from administrativedomain

No logging is available. Monitor frequency of SQL queries against the

AdministrativeDomain table to determine if cache is sized appropriately.

wt.cache.size.WTCalendarCache

This specifies the number of WTCalendar entries cached in the method server.

The default is 100.

Optimal sizing for this cache is difficult to estimate since it contains both

persistent and non-persistent values.

The WTCalendarCache has been found to significantly influence performance,

especially in a production environment. This is especially true for sites running

Windchill ProjectLink.

The optimal size for the cache depends on the value for property

wt.calendar.calculateDefaults. If your site does not require each Windchill user to

maintain a separate calendar (separate calendars are often required to track


working days from non-working days), you can enforce a system-wide calendar.

You can enforce a system-wide calendar by setting wt.calendar.calculateDefaults

to true in wt.properties (the default value is false).

If you enforce a system-wide calendar, the default cache size should be sufficient.

To tune the cache size when you allow user-specific calendars, first monitor the

cache efficiency by setting the following property to a non-zero value:

wt.calendar.cache.summaryInterval

Additionally, this property controls periodic logging.

wt.folder.cache.containersToCabinetsSize

Caches sets of Cabinets by Container. No logging is available.

Default value is 100.

wt.folder.cache.namesToCabinetsSize

Caches Cabinets by name. No logging is available.


wt.folder.cache.namesToSubFoldersSize

Caches subfolders by parent folder name or cabinet name. No logging is available.


wt.folder.cache.parentsToSubFoldersSize

Caches subfolders by parent folder object identifier. No logging is available.


wt.folder.cache.subFoldersToParentsSize

Caches parent subFolders by child subfolder object identifier. No logging is

available.


wt.folder.cache.usersToCabinetsSize

Caches user personal cabinets by user object identifier. No logging is available.


wt.folder.oneLevel

Determines whether the folder browser should recursively display all children

under the current displayed folder or just the direct children. Setting the value to

true displays only the direct children. For large pages, setting the value to true

results in small and fast pages, but requires the user to navigate to get to nested

objects.

Default value is false.


wt.cache.size.FvPolicyItemCache

Caches FvPolicyItems by wt.admin.Selector.

Sql> select count(*) from fvpolicyitem



wt.fv.FvPolicyItemCache.summaryInterval

wt.cache.size.StandardFvService$FvFolderCache

Caches FvFolder by ObjectIdentifier.



wt.fv. StandardFvService$FvFolderCache.summaryInterval

wt.cache.size.StandardFvService$FvMountCache

Caches FvMounts by FvFolder ObjectIdentifier.



wt.fv.StandardFvService$FvMountCache.summaryInterval

wt.cache.size.ConfigCache

Caches replica HostConfig by hostname + masterURL.



wt.fv.replica.ConfigCache.summaryInterval

wt.cache.size.IBADefinitionDBService$DefaultViewbyPathCache

Caches Attribute Hierarchies by hierarchy identifier.



wt.iba.definition.service.IBADefinitionDBService.summaryInterval

wt.cache.size.IndexListCache

The number of index lists that can be cached in the servers.

The default is 200.

The number of index lists in the database can be found with the following SQL

statement:

sql> select count(*) from indexpolicylist;



wt.index.IndexListCache.summaryInterval

wt.cache.size.AdHocAclSpecCache

Caches AdHocAclSpec by PhaseTemplate.

Default size 100.


wt.lifecycle.AdHocAclSpecCache.summaryInterval

wt.cache.size.CriterionCache

Caches Life Cycle Criterion by PhaseTemplate

Default size 100.


wt.lifecycle. CriterionCache.summaryInterval

wt.cache.size.InitialPhaseCache

Caches initial PhaseTemplate by LifecycleTemplate.

Default size 100.


wt.lifecycle. InitialPhaseCache.summaryInterval

wt.cache.size.LifeCycleTemplateCache

Caches Life Cycle Query Results by LifeCycleTemplateMaster.

Default size 100.


wt.lifecycle. LifeCycleTemplateCache.summaryInterval

wt.cache.size.LifeCycleTemplateNameCache

Caches Life Cycle Template by LifeCycleTemplate Name + ContainerReference.

Default size 100.

No logging available.

wt.cache.size.PhaseTemplateCache

Caches Vector of Phase Templates by LifecycleTemplate.

Default size 100.


wt.lifecycle. PhaseTemplateCache.summaryInterval


wt.cache.size.NotificationListCache

The number of notification lists that can be cached in the servers.

The default is 200.

The number of notification lists in the database can be found with the following

SQL statement:

sql> select count(*) from notificationlist;


wt.notify. NotificationListCache.summaryInterval

wt.cache.size.DirectoryInfrastructureNodeCache

Caches Directory Infrastructure Nodes by distinguished name.



wt.principal.cache.summaryInterval

wt.cache.size.WTPrincipalCache

The number of principals (users and groups) that can be cached in the servers.

The default is 1000.

The principal cache should be sized for the expected peak active user count.


wt.principal.cache.summaryInterval

wt.cache.size.PagingSessionCache

Caches paged query results by session.



wt.pom.PagingSessionCache.summaryInterval

wt.cache.size.PrefEntryCache

This specifies the number of DBPrefEntries held in the PrefEntryCache.

The default value is 3000.

Note: In earlier releases, PrefEntryCache was sized by property

wt.prefs.PrefEntryCache.size.

All PrefEntyCache calls can be logged with the property:

wt.prefs.PrefEntryCache.verbose


wt.cache.size.StandardInitRuleEvalService$Cache

Caches Rule Attribute Values by CompositeRule or PersistentRule



wt.rule.init.StandardInitRuleEvalService$Cache.summaryInterval

wt.cache.size.SessionCache

The number of client sessions for which authentication information is cached in

the servers.

The default is 500.

The Session Cache should be sized for the expected peak active user count.

Windchill PDMLink uses the cache-managed Session Cache to maintain product

structure information keyed by *servlet* session. When the session gets timed out

of the servlet engine we need to ensure the corresponding key in the Session

Cache is removed otherwise it will sit in the cache until it’s removed by the LRU

algorithm when the cache overflows. This is the responsibility of the

wt.session.SessionContextDestroyer which is executed by the servlet engine when

sessions age out.


wt.session.SessionCache.summaryInterval

wt.cache.size.TeamTemplateCache

The number of Team Template objects that can be cached in the servers.

The default is 200.

The number of Team Templates in the database can be found with the following

SQL statement:

sql> select count(*) from TeamTemplate

No logging is available.

wt.ufid.FederatableServerHelper$RepositoryCache

Caches Repository objects by guid and by object id.



wt.ufid.FederatableServerHelper$RepositoryCache.summaryInterval

wt.cache.size.WfProcessTemplateCache

Caches a query result of WfProcessTemplates by WfProcessTemplateMaster.



Periodic logging is controlled by property:

wt.workflow.definier.WfProcessTemplateCache.summaryInterval

com.ptc.netmarkets. serverCacheLimit

The serverCacheLimit affects how many project models (the folder structure of

folder/parts/docs) are cached in the method server. This cache is shared among all

users. The cached folder structures can consume significant portion of the heap.

Due to the potential for excessive heap utilization, it is highly recommended that

the cache be sized to accommodate just the working set of

Project/Product/Libraries only. See also wt.folder.ResultsLimit below.

The default size is 10.

To monitor the hit/miss ratios of the folder cache set property:

com.ptc.netmarkets.verboseCache=true

wt.folder.ResultsLimit

To avoid caching excessively large folder structures in the method server, the

property wt.folder.ResultsLimit imposes a limit to the number of Foldered objects

cached per Container. Examples of Foldered objects include, WTPart,

WTDocuments, and EPMDocuments.


If Containers are likely to contain large numbers of objects, it is recommended

that content be arranged in a hierarchy of SubFolders and then clients should use

the folders-only view and folder details pages.

com.ptc.netmarkets.projmgmt.serverCacheLimit

The project (plan page) is cached for running projects. This has a potential of

being a large consumer of memory.


To monitor the hit/miss ratios of the plan page cache set the property:

com.ptc.netmarkets.projmgmt.serverCacheVerbose=true


service.properties

In addition to the cache settings that can be made in wt.properties, you can also set

some generic cache settings using properties in the service.properties file.

The ReferenceCache maintains a table of caches rather than a single cache.

ObjectReferences that are modeled as subclasses of CachedObjectReference

automatically utilize the ReferenceCache when the reference needs to be inflated.

The ReferenceCache implementation allows the configuration of a separate cache

for each such referenced class.

The following extract from service.properties shows that the ReferenceCache is

subdivided into separate caches. In the extract, <service_path> is

wt.services/rsc/default/ObjectReferenceCacheTable:

<service_path>/null/wt.admin.AdministrativeDomain/0=DomainCache

<service_path>/null/wt.fc.Persistable/0=DefaultCache

<service_path>/null/wt.folder.Cabinet/0=CabinetCache

<service_path>/null/wt.folder.SubFolder/0=SubFolderCache

<service_path>/null/wt.inf.container.WTContainer/5=ContainerCache

<service_path>/null/wt.inf.team.ContainerTeam/0=ContainerTeamCache

<service_path>/null/wt.workflow.engine.WfProcess/0=WfProcessCache

<service_path>/ReportInterval/null/0=0

<service_path>/Size/null/0=200

<service_path>/SubFolderCache.Size/null/0=500

<service_path>/WfProcessCache.Size/null/0=50

The extract sets up caches for the following classes:

wt.admin.AdministrativeDomain

wt.inf.container.WTContainer

wt.inf.team.ContainerTeam

wt.workflow.engine.WfProcess

wt.folder.Cabinet

wt.folder.SubFolder

Additionally, there is one cache for all the other classes (based on

wt.fc.Persistable).

The default size for all caches is specified as 200 except for the SubFolderCache

(which is sized for 500) and the WfProcessCache (which is set at 50).

In the extract, periodic reporting is shown as globally disabled in the following

line:

<service_path>/ReportInterval/null/0=0


Periodic reporting of these caches can be enabled globally or individually. In

order to set the reporting interval for all caches, find the ReportInterval items

associated with ObjectReferenceCacheTable (as shown in the extract) and set the

corresponding entry resource to a non zero value. For example, to report all

cached tables every 10000 accesses, set the following line in service.properties:

wt.services/rsc/default/ObjectReferenceCacheTable/ReportInterval/null/0=10000

Similarly, if you want to collect statistics for an individual cache, such as the

ContainerCache, set the following:

wt.services/rsc/default/ObjectReferenceCacheTable/ContainerCache.ReportInterval/

null/0=10000

db.properties

This section contains descriptions of properties that can be tuned relating to the

JDBC statement cache as well as other tuning properties.

Properties Related to the JDBC Statement Cache

Note: The JDBC statement cache is a fixed size collection of reusable prepared

JDBC statements. Before executing most SQL statements, Windchill checks to

see if the statement already exists in the JDBC cache. Since significant overhead

is required to create JDBC statements, the efficiency of this cache has a major

influence on system performance. The JDBC statement cache can be monitored

with negligible overhead.

Use the following properties from db.properties when tuning the JDBC statement

cache:

wt.pom.statementCacheSize

wt.pom.cachedStatementReuseLimit

wt.pom.maxDbConnections

wt.pom.maxIdleStatementCaches

wt.pom.refreshCache.size

wt.pom.statementCacheSize

This property specifies how many cached statements may be held by each

database connection.

The default is 50.

Try to size the cache to minimize the number of misses reported by the periodic

summary. Measure the effect of increased statementCache size on CPU utilization

and heap usage.

wt.pom.cachedStatementReuseLimit

In addition to setting the statement cache size, you can control the number of

times each cached statement may be executed before being removed from the

cache.


For example, in db.properties specify:

wt.pom.cachedStatementReuseLimit=32000

If you want to trace individual accesses to the JDBC statement cache, you can set

the following property:

wt.pom.log.statementCaching=true

However, setting this property to true causes a large number of messages to be

written the MethodServer.log file.

wt.pom.maxDbConnections

This property controls the number of database connections each method server

holds open.


Having multiple connections open to the database increases throughput since

there may be multiple concurrent JDBC statements executing in parallel (in

separate threads).

When transaction concurrency is high (for example, above maxDbConnections),

threads will block waiting for database connections to be freed. If the average

number of active method contexts (see Using the

wt.method.methodSummaryInterval Property) is consistently above the

maxDbConnections parameter and server resource utilization is not saturated, you

should consider increasing this property. This will allow additional connections to

be opened to meet demand.

When a database connection is released, the connection may be closed depending

on the number of outstanding client requests and the value of property

wt.pom.minDbConnections. If the number of outstanding requests is below the

current number of open connections and there are at least minDbConnections still

open, then the connection is closed.

wt.pom.maxIdleStatementCaches

Another property to consider is wt.pom.maxIdleStatementCaches. This property

is designed to minimize the heap usage of cached JDBC Statements. It governs

how many database connections maintain their statement caches when they are

returned to the connection pool.

At release 8.0 the default value was changed from 5 to 0. Therefore all cached

statements are freed when the database connection is released.

Check the RDBMS’ statement parse counts and elapsed times to weigh the

benefits of fewer parses versus increased method server memory footprint.

Note: After increasing either the number of database connections or method

servers, you may need to re-evaluate the load balancing parameters (if you have

multiple method servers).


wt.pom.refreshCache.size

When a user request requires transaction isolation (for example, to provide for

rollback/commit of changes), the persistence manager uses a cache of objects that

have been locked or modified.

The default size for this cache is 100.

It is likely that transactions that modify large collections of objects could benefit

from a larger value for the refreshCache.

Other Tuning Properties

The following are descriptions of other important tuning properties in

db.properties.

wt.pom.chunk.defaultSize

Default size to use for SQL value lists that need to be executed as separate

statements. For example if the application generates a SQL value list containing

1000 identifiers, the pom subsystem sends the value list in chunks of

wt.pom.chunk.defaultSize.

As the default value is 10, 10 separate queries would be performed, for example,

the application tier passes 100 values at a time (as bind parameters).

In some cases (perhaps when network latency between the Application and

Database tiers is significant), improved performance has been observed with

larger values as this causes fewer SQL executions.

wt.pom.inClauseUseBindOptimization

The performance of queries that pass large lists of identifiers to Oracle can benefit

from the bindOptimization feature. By default, this feature is turned on for Oracle

and takes advantage of the Oracle Array types. When this feature is enabled, the

implicit ‘chunking’ of large value lists is disabled.

By setting this property to false, you can turn off this feature.

It is imperative that the Oracle statistics be up to date for this feature to work

effectively.

wt.pom.inClauseBindOptimizationCardinality

This property is used in conjunction with wt.pom.useBindOptimization; it is only

relevant when useBindOptimiztion is true.

In order to work around bug 4235962 in Oracle 9.2.0.5, this property can be used

to set a cardinality hint contained in the SQL. When the query has a subquery

using a virtual table using TABLE() and CAST() functions, CBO calculates

wrong cardinality and the execution plan using HASH SEMI-JOIN generates a

bad execution plan.

The default value is -1.



effectively.

wt.pom.cardinalityValueFixedSize

This property is also only relevant when useBindOptimization is set to true;

however, this property only takes effect if

wt.pom.inClauseBindOptimizationCardinality is set to a negative value.

The objective for this property is to optimize the reuse of cached statements while

providing approximations to Oracle of the actual cardinalities. Essentially this

causes the cardinality hint to increase in steps.



effectively.

wt.pom.queryLimit

This property can be added to db.properties to limit the number of rows in every

result set. This is a work around for run away queries. Set the value to some

arbitrarily high value that is large enough to satisfy all realistic result set sizes (for

example, 20,000).

By default its value is 0 or unlimited. Once the limit is exceeded Windchill returns

a truncated result set to the caller (wrapped in an Exception).

wt.pom.dbConnectionPropertiesNameList &

wt.pom.dbConnectionPropertiesValueList

When connecting to an Oracle database via the 9.2.0.5 (or later) JDBC driver, it is

possible to specify additional property name/values pairs. One such property

governs whether the socket data sends use the Nagle algorithm. The Nagle

algorithm can inject significant latency on network traffic in order to lower

utilization. Symptoms of network latency on JDBC traffic are the wait events

‘SQL*net more data to client’ and ‘SQL*net more data from client’. These events

suggest that data is not flowing freely between the application and database tiers.

In order to minimize the Nagle effect, set the TCP.NODELAY property to ‘YES’

as follows (in db.properties):

wt.pom.dbConnectionPropertiesNameList=TCP.NODELAY

wt.pom.dbConnectionPropertiesValueList=YES

Disabling the NAGLE algorithm can result in more packets on the network. If the

network utilization is of concern, or if the quantity of data being transferred is

significant, it may be more efficient to adjust the Oracle Session Data Unit (SDU)

on the connection. The SDU effects the application level send buffer sizes and,

when set too small, can limit network throughput. The default Oracle SDU is

2KB. To increase the SDU to 16KB on all Windchill database connections, the

wt.pom.serviceName should be defined in the form:

wt.pom.serviceName=(DESCRIPTION=(SDU=16384)(ADDRESS=(PROTOCOL=tcp)(PORT=1521)

(HOST=localhost))(CONNECT_DATA=(SERVICE_NAME=foggy) ))


wt.query.singleWildCard

Certain characters are treated as wildcards by Windchill and SQL. Characters '*'

and '%' are used as multi-character wildcards. The single character wildcard is '_'

(underscore). Customer data names or numbers using any of the wildcard

characters may cause the Local Search processor to return more data than desired.

To disable the single wildcard character altogether, set the following:

wt.query.singleWildCard=e

Note: This property is not used by Info*Engine-based search clients such as

DCA.

wt.pom.paging.snapshotQueryLimit

Use this property to limit the results that are processed as the result of a search.

Note: The property limits all queries that use paging. This includes search

queries, but is not limited to them.

By default, all results that match a particular criteria are returned to the method

server. Then, access control is applied and results are inserted into a temporary

Oracle table for later use. With a moderate number of results (a few thousand), the

overhead should be acceptable; however, the greater the number of results

returned the higher the resource usage.

To prevent accidental excessive resource usage, PTC recommends that you set

this parameter to a value between 10000 and 20000.

Windchill Adapter Properties

The Info*Engine Windchill adapter tuning properties include the following:

Note: The following properties are Info*Engine properties and you need to set

them in the appropriate LDAP service using the Info*Engine Property

Administrator. Ensure that each property name entered has the runtime service

name as a prefix.

<runtime service name>.socketAccess.maxThreadCount

This property limits the number of server side request threads that are available

for an out of process adapter.


It is currently only defined on the standalone task processor and the standalone

task processor is not used when Windchill is installed. However, one can set this

on the Windchill adapter.

If the max thread count is exceeded then the server will stop accepting requests

until there is a thread available.


With "info" logging enabled for the Windchill adapter, the log contains messages

such as the following:

<…>#SocketAccess.run: waiting for a thread to finish...

<runtime service name>.taskProcessor.taskFileTimeToLive

Sets the time to live on compiled tasks to avoid checking file timestamps for task

invocation. The value is interpreted as number of minutes. Set it to a negative

value to skip the check entirely causing it only to occur the first time the task is

invoked (task modification/recompilation requires a restart). Set to another value

will cause the task compiler to see if a task needs to be recompiled based on the

property value. If the property is not set then a task compiler will check the

timestamps on each invocation.

<runtime service name>.credentialsTimeToLive

Time To Live for mapped credentials. The value is a number of seconds that

cached mapped credentials for a particular user should be held onto before

re-invoking the credentials mapping task. Without it set, the task will be invoked

once for each Info*Engine request.

<runtime service name>.taskDelegateTimeToLive

Time to live for cached task delegate entries used by Dispatch-Tasks.

The default is 15 minutes.

It governs how long a cached task delegate entry will be held onto by the webject

before going back to LDAP to get a fresh copy.

<runtime service name of naming service>.cacheTTL

Time to live for Naming Service Object Destinations.

The default value is 15 minutes.

It governs how long a cached service will be held onto by the Naming Service

before going back to LDAP to get a fresh copy.

<runtime service name>.properties.timeToLive

How long the properties object lives before being refreshed.

The default value is 15 minutes.

It specifies the time that elapses before the properties for a service or adapter are

automatically reloaded. The configuration information is reloaded while the

service or adapter is running without requiring it to be restarted. The properties

are only reloaded if they are being accessed. For example, if the time to live is set

at 15 minutes, and the properties are not used for an hour, the properties will not

be reloaded until the first request is made after the time to live has expired.

Note: Setting to a negative value disables dynamic properties refresh.


Webject Optimization

To minimize the number of round trips between the servlet engine and the

WTAdapter when executing multiple webjects, it is optimal to encapsulate the

logic in a task and specify a task processor name. The following example task

shows the syntax to use:

<ie:task uri="/com/ext.../QueryModifiableProjects.xml"

processor="<%=System.getProperty(com.infoengine.au.NamingService.getVMName()+"

.ieServerName")%>">

<ie:param ... />

</ie:task>

For more information on using tasks, see the Info*Engine User’s Guide.

Background Method Server Tuning

Providing multiple background method servers can improve performance by

providing better queue processing.

Information about configuring multiple background method servers and

associated queues can be found in the Windchill Advanced Deployment Guide.

For queue logging information, see Windchill Queue Logging in the Server-side

Diagnostic Logging chapter.

For information on queue pooling, see Workflow Queue Tuning.

The following property could be useful in tuning background method servers.

wt.queue.execEntriesCount

The wt.queue.execEntriesCount property can be added to the wt.properties file. Its

value specifies the number of queue entries returned for processing every time a

call is made to the Windchill database.


Increasing this value results in fewer database calls and improves queue

performance, especially in situations where the queue load is heavy. To improve

queue throughput, test the effect of increasing the value by 100% or 200%.


Setting Unique Background Method Server Properties

In some cases it can be advantageous to configure the background method server

to use a different set of Persistence Manager properties from other method servers

running on the same server. This can be achieved by overriding the

wt.pom.properties property on the background method server startup command,

for example, in wt.properties:

wt.manager.cmd.BackgroundMethodServer=$(wt.manager.cmd.MethodSe

rver) wt.method.serviceName\=BackgroundMethodServer

wt.queue.executeQueues\=true wt.queue.queueGroup\=default

wt.adapter.enabled\=false wt.method.minPort\=3000

wt.pom.properties=$(wt.home)$(dir.sep)db$(dir.sep)db_bgms.prope

rties

By creating a copy of the db.properties file (db_bgms.properties) like this, you

can allocate more database connections to queue processing than to foreground

activities.



5Java Garbage Collector Tuning

The preceding chapters described how to build a resource profile and gather

diagnostic data for a Windchill client request. This chapter focuses on measuring

performance of the Java Garbage Collector. The chapter describes tools used in

garbage collection and some properties that can be set relating to memory that are

shared by all Windchill application JVMs, including the server manager, method

server, servlet engine and the Java Plug-in.

Topic Page

Garbage Collection..............................................................................................5-2

Managing System Memory .................................................................................5-8

Balancing System Memory .................................................................................5-9

5-1

Garbage Collection

The Java programming language is object-oriented and includes automatic

garbage collection. Garbage collection is the process of reclaiming memory taken

up by unreferenced objects.

A comprehensive discussion on Garbage Collection can be found at:

http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html

The Windchill method server and servlet engine experience two problems with

default VM default heap parameters:

• One is slow startup, because the default initial heap is small and must be

resized over many major collections. The default initial heap size for a

method server has been increased to 128MB.

• A more pressing problem is that the default maximum heap size is

unreasonably small. The default maximum heap size for the method server is

set at 256MB.

PTC highly recommends that the maximum heap size be further increased based

on the available RAM of your application server by adjusting the

wt.method.minHeap and wt.method.maxHeap values in wt.properties.

Young Generation Guarantee

As described in the hotspot document referenced above, a minor collection is

where the live objects are copied from one part of the young generation (the eden

space plus the first survivor space) to another part of the young generation (the

second survivor space). Since the survivor spaces are smaller than eden there is no

guarantee that all the live objects will fit into the second survivor space.

Therefore, in order to ensure that the minor collection can complete even if all the

objects are live, enough free memory must be reserved in the tenured generation

to accommodate all the live objects. If there isn’t enough free memory in the old

generation then a major collection is performed. This is called the Young

Generation Guarantee. When sizing the generations you should try to ensure that

there is sufficient free memory in the tenured generation to fit the young

generation.

By default, the young generation size is controlled by NewRatio. For example,

setting:

-XX:NewRatio=3

means that the ratio between the young and tenured generation is 1:3. In other

words, the combined size of the eden and survivor spaces will be one fourth of the

total heap size.

If desired, the parameter SurvivorRatio can be used to tune the size of the survivor

spaces, but this is often not as important for performance. For example:

-XX:SurvivorRatio=6



sets the ratio between each survivor space and eden to be 1:6. In other words, each

survivor space will be one eighth of the young generation (not one seventh,

because there are two survivor spaces).

If survivor spaces are too small, copying collection overflows directly into the

tenured generation. If survivor spaces are too large, they will be uselessly empty.

A SurvivorRatio of 8 has proven optimal.

The maximum size of the young generation is calculated from the maximum size

of the total heap and NewRatio. The "unlimited" default value for MaxNewSize

means that the calculated value is not limited by MaxNewSize unless a value for

MaxNewSize is specified on the command line.

The default values for the supported JVMs are as follows:

A description of other virtual machine options can be found at:

http://java.sun.com/javase/technologies/hotspot/VMoptions.jsp

Windows Solaris HP-UX

NewRatio 12 2 (client JVM: 8) 3

NewSize 640K 2228k 1/3rd of initial heap

(ms)

SurvivorRatio 8 32 8

Java Garbage Collector Tuning 5-3

http://java.sun.com/javase/technologies/hotspot/VMoptions.jsp

Monitoring Garbage Collection Duration & Frequency

Each vendor provides its own tools for monitoring garbage collection. This

section describes some tools available for Windows and Solaris platforms.

For additional information on garbage collection, see the following sites:

Sun:


HP-UX:

http://www.hp.com/products1/unix/java/infolibrary/prog_guide/hotspot.html

HPjtune

HP-UX provides a garbage collection log analysis tool called HPjtune that plots

garbage collection activity graphically.

jvmstat

For VMs on Windows and Solaris platforms, download a copy of the jvmstat tool

from java.sun.com (http://java.sun.com/performance/jvmstat/).

From jvmstat, you can run jvmps, jvmsnap and visualgc.

jvmps

From the command line, run the jvmps command to obtain a list of running JVM

processes that may be monitored. The process identifier (pid) and main class are

displayed for each such process. The following example shows the version 2 of

jvmstat:

D:\jvmstat\bat>jvmps

9040 wt.method.MethodServerMain

8764 wt.method.MethodServerMain

3176 org.apache.catalina.startup.Bootstrap

8688 wt.manager.ServerManagerMain

It shows two method servers, one server manager and one Tomcat process. After

the process ID (pid) is known, you can obtain more detailed statistics using

jvmsnap.

jvmsnap

Running the jvmsnap tool with a JVM process ID causes that VM to dump a

number of statistics. Among the most valuable data that can be collected is the

current size and amount used of each of the three generations: new (0), old (1) and

perm (2).

The jvmsnap 2.0 tool generates text output in the following format:

D:\jvmstat\bat>jvmsnap 9040

<cut>


http://java.sun.com/performance/jvmstat/


http://www.hp.com/products1/unix/java/infolibrary/prog_guide/hotspot.html

hotspot.gc.generation.0.capacity.current 10813440

hotspot.gc.generation.0.capacity.max 14876672

hotspot.gc.generation.0.capacity.min 7405568

hotspot.gc.generation.0.name "new"

hotspot.gc.generation.0.space.0.capacity 8716288

hotspot.gc.generation.0.space.0.name "eden"

hotspot.gc.generation.0.space.0.size 11993088

hotspot.gc.generation.0.space.0.used 15128


hotspot.gc.generation.0.space.1.name "s0"




hotspot.gc.generation.0.space.2.name "s1"



hotspot.gc.generation.0.spaces 3




hotspot.gc.generation.1.name "old"


hotspot.gc.generation.1.space.0.name "old"







hotspot.gc.generation.2.name "perm"


hotspot.gc.generation.2.space.0.name "perm"




<cut>

In this example, the new generation has a maximum capacity of 14876672 bytes,

and the current size is 10813440. The new generation is further subdivided into 3

regions or spaces:

Region 0 (for example, eden) is sized at 8MB of which 15128 bytes are used.

Regions 1 and 2 are the survivor spaces and are both sized at 1MB.

The old generation has a maximum capacity of 119341056 bytes, and the current

size is 86142976 of which 50467376 bytes are used.

The perm generation has a maximum capacity of 100663296 bytes, the current

size is 40894464 of which 40752928 are used.

Tip: With some programming effort, the collection of the jvmsnap output can be

automated and thus heap utilization can be trended over an extended period of

time.


visualgc

The same information that you can get from jvmsnap is available graphically

using the visualgc tool. For example, enter the following for a visual display:

D:\jvmstat\bat>visualgc 9040

The following picture shows a sample wt.method.MethodServerMain display

taken at a different point in time from the previous example:

The left window shows the current sizes of the Perm, Old, Eden and survivor

spaces (S0 and S1) in the heap. The right window also shows timings for

significant JVM events such as garbage collections.

The right window shows sizes of these same spaces in the heap as strip charts.

Through the strip charts, some history is available for spotting trends.

Unfortunately, the visualgc tool does not support logging of garbage collection

activity to file.

Java Command Line

The java command accepts the directive -Xloggc that specifies a file name where

the garbage collection diagnostic data is written.


Details about the garbage collection activity, such as size of the young and old

generation before and after garbage collection, size of total heap, elapsed time it

takes for a garbage collection to happen in young and old generation, and size of

objects promoted at every garbage collection, and other data, can be recorded by

using the XX:+PrintGCDetails argument.

Distributed Garbage Collection

The next two properties specify how often the distributed garbage collection is

performed. The example below changes the default value for both properties

(60000 ms) to one hour. You can specify both property overrides as Java

command line options on the method server, server manager, and Tomcat.

-Dsun.rmi.dgc.server.gcinterval=3600000

-Dsun.rmi.dgc.client.gcinterval=3600000

More information is available at:

http://java.sun.com/j2se/1.5.0/docs/guide/rmi/sunrmiproperties.html

wt.method.MemoryMonitor Class

The MemoryMonitor class can be used to detect when the method server is short

of available heap and recognize and interrupt the client request with the most live

references to the most WTObjects.

Note: Tomcat has properties that control heap size. See Tomcat 5.5 Tuning.

When MemoryMonitor is enabled, each thread checks the heap availability every

time it has instantiated 100 WTObjects (configured by property

wt.util.WTObjectCounter.allocCheckPeriod). Heap availability is determined

using java.lang.Runtime.freeMemory and totalMemory(). Only when the value of

totalMemory() minus freeMemory() is above the property

wt.fc.MemoryMonitor.maxHeadRoom does the MemoryMonitor see which

thread has accumulated most WTObject references.

To enable the MemoryMonitor, set properties:

wt.fc.WTObjectCounter.enabled=true (default is false)

wt.method.MemoryMonitor.maxHeadRoom=<available heap threshold> (default is

Long.MAX_VALUE bytes)

The maxHeadRoom property is the "heap used" threshold which triggers thread

termination. For example if the method server’s maximum heap size is specified

as 512MB, setting this value to 508MB causes the MemoryMonitor to perform

selective thread termination when 508MB of heap is utilized. maxHeadRoom may

be specified in bytes, Kilobyte, Megabytes or Gigabytes. For example, all the

following values are equivalent:

1G, 1g

1024M, 1024m


http://java.sun.com/j2se/1.5.0/docs/guide/rmi/sunrmiproperties.html

1048576K, 1048576k

1073741824

The frequency of the heap check mechanism is controlled by

wt.fc.WTObjectCounter.allocCheckPeriod. By default the heap is checked after

100 WTObjects have been created by a Thread (and every 100 objects thereafter)

wt.fc.WTObjectCounter.allocCheckPeriod (default 100)

Tip: The MemoryMonitor tool can be run from a command line in order to report

all MethodContexts in all method servers.

Managing System Memory

An integral part of optimizing Windchill performance is proper memory

management. The frequency and duration of Java garbage collection (heap

management) is greatly influenced by transaction load and available memory.

Both the Windchill method server and the database server can efficiently cache

persistent data in memory to minimize disk reads and thus increase transaction

throughput. In addition, the Web server, servlet engine and operating system

require significant amounts of memory. The goal is to balance all memory

requirements with physical memory and avoid excessive virtual memory paging.


Balancing System Memory

Use this section as a starting point when determining memory allocation on your

initial installation of a Windchill system. The information provided assumes that

the servers involved are dedicated to running your Windchill solution. The

information should not be taken as fixed rules that must be followed; there can be

many site specific reasons to use a different allocation scheme.

Note: After you have your production system running, use the performance

analysis techniques described in this guide to arrive at the memory allocation

scheme that best meets your production system.

Use the information in the following Memory Allocation Guidelines table as a set

of guidelines for memory allocation. The first column lists the types of processes

needed in a Windchill installation and columns two through four indicate the

percentage of total memory to be allocated for the type of process.

The second column of the table gives percentages for a single server system

(Windchill, Oracle, Web server, and servlet engine all on one system). The third

and fourth columns give percentages for a split Windchill server / Oracle server

configuration.

Memory Allocation Guidelines

Note: The recommended total memory allocation (as noted in the last row of the

table) is less than 100%. This allows memory for other processes that are a part of

normal system operation.

Application / Database

Process Type Single Server

Split Servers /

Windchill Server

Split Servers /

Oracle Server

Windchill 21.00% 30.00%

Oracle 21.00% 70.00%

Servlet Engine 21.00% 30.00%

Operating System 12.50% 12.50% 12.50%

Web Server 5.00% 5.00%

Search Engine 5.00% 5.00%

Total Used Memory 85.50% 85.50% 85.50%


The following table shows a sample memory allocation for a single server

configuration that has 8 GB of memory:

The following table shows a sample memory allocation for a split server

configuration that has 4 GB of memory for each server:


Process Type Single Server

Total Memory Available 8 GB

Windchill 1.68 GB

Oracle 1.68 GB

Servlet Engine 1.68 GB

Operating System 1 GB

Web Server 400 MB

Search Engine 400 MB

Total Used Memory 6.84 GB


Process Type

Split Servers /

Windchill Server

Split Servers /

Oracle Server

Total Memory Available 4 GB 4 GB

Windchill 1.2 GB

Oracle 2.8 GB

Servlet Engine 1.2 GB

Operating System 500 MB 500 MB

Web Server 500 MB

Search Engine 200 MB

Total Used Memory 3.3 GB 3.3 GB


6Performance Checklist

This chapter contains a checklist for troubleshooting common Windchill

performance problems and flowcharts that you can use to help diagnose

performance problems.

Topic Page

Performance Checklist ........................................................................................6-2

Troubleshooting Flowcharts................................................................................6-6

6-1

Performance Checklist

When preparing to investigate a performance issue, it is usually worthwhile to

first check for a few configuration issues. The following checklist describes some

of the more common issues that may be resolved by tuning:

• Oracle statistics.

Ensure that the schema statistics are up to date.

PTC recommends that the schema statistics be updated on a regular basis.

PTC also recommends that the operating system statistics be gathered on the

server where the Oracle database resides. The Oracle 10g Tuner can perform

these tasks. For details on installing and using this tuner, see Oracle 10g

Tuner for Windchill Solutions Installation and Configuration Guide. You can

access this guide from the Reference Documents link of the PTC Web site.

See Documentation for PTC Products.

If you decide not to use the tuner, consult the Oracle Tuning Guidelines

appendix and the Oracle 10g Database Performance Tuning Guide and

Reference guide for examples on how to gather statistics.

• Oracle SGA or PGA is sized too small.

The Oracle 10g Tuner can be used to adjust the main Oracle 10g caches. For

details on installing and using this tuner, see Oracle 10g Tuner for Windchill

Solutions Installation and Configuration Guide.

If you decide not to use the tuner, you can use Oracle Enterprise Manager and

Automatic Database Diagnostic Monitor reports to monitor SGA/PGA sizes

and adjust as necessary. For additional inforamtion see, Approximating the

Initial Instance Memory Size.

• Oracle Cost Based Optimizer chooses wrong execution plan.

This can be caused by factors such as missing indexes, skewed data,

inefficient application SQL.

Use Oracle Enterprise Manager, SQL tracing, and the Windchill Profiler (for

customized code) to identify poorly performing SQL. Determine if SQL can

be tuned onsite or open Technical Support call if necessary. Use of the

Windchill Profiler is described in the Windchill Customizer’s Guide.

• SQL operations for large lists are too slow.

If you are using SQL operations that pass large 'IN' lists (for example., bulk

create, bulk checkout, so on), ensure the following:

– The property wt.pom.inClauseUseBindOptimization is true.

– The property wt.pom.inClauseBindOptimizationCardinality is set to -1.

– The Oracle initialization parameter _always_semi_join=off.


• Method server configuration is incorrect.

Configure a minimum of one background method server and one method

server. For details on configuring method servers, see the Windchill System

Administrator’s Guide.

• The number of Windchill adapter service LDAP entries defined in the

Info*Engine Property Administrator is incorrect.

If there are more Windchill adapters defined than are actually running, then

users can experience longer response times. Verify that the number of

Windchill adapters defined matches the actual number of running Windchill

adapters. For details on the Windchill adapter settings, see the Windchill

Adapter Guide.

• Method server database connection pool is too small.

Monitor the MethodSummary lines in the method server log file to see if the

average number of active contexts is greater than the maximum number of

database connections. Increase maximum number of database connections if

CPU capacity is available on both Oracle and Windchill servers. For

additional information, see wt.pom.maxDbConnections in the Properties

Related to the JDBC Statement Cache section of the Application Tuning

chapter.

• Method server JDBC statement cache is too small.

Monitor the StatementCache summary lines in the method server log file. A

low hit to miss ratio as reported by the StatementCache can indicate an

undersized cache. For additional information, see

wt.pom.statementCacheSize in the Properties Related to the JDBC Statement

Cache section of the Application Tuning chapter.

• Use of BLOB Oracle tablespace versus file vaulting.

For optimal content upload and download performance, PTC recommends

storing file content in a file vault rather than as BLOB data files.

• There is excessive garbage collection frequency or duration.

Check to see if the method server or Tomcat heap are too small or generations

are sized incorrectly. For additional information, see Garbage Collection and

Tomcat 5.5 Tuning.

• Method server or server manager log tee is set true when the processes are not

attached to terminals and the stdout/stderr have not been redirected.

For information on setting the wt.manager.log.tee and wt.method.log.tee

properties, see the properties.html file.

Performance Checklist 6-3

• Missing resources in client jar files.

There may be missing resources if the start time for applets is greatly affected

by network latency. If an applet has to load many class files over a high

latency connection, a significant delay is often encountered.

Ensure that all appropriate language and locales have been installed. Monitor

the Web server log file to identify classes being loaded over the network. Add

the classes to the appropriate client jar configuration files.

• Excessive database result set size.

Wildcard or open-ended queries against RDBMS or LDAP can consume

significant CPU time and thus make the system appear unresponsive.

Monitor Web server logs to identify such requests. Consider implementing

result set limits. See wt.pom.paging.snapshotQueryLimit and

wt.pom.queryLimit in the Other Tuning Properties section of the Application

Tuning chapter.

• There is excessive JDBC chatter.

Monitor the StatementCache summary lines. A large number of such

summary lines associated with a single thread can be due to inefficient code.

It can also be an indicator of an undersized service cache. To check this,

enable cache summary reporting (see

wt.cache.CacheManager.summaryInterval in the Windchill CacheManager

section of the Server-side Diagnostic Logging chapter. Use the logs to

identify troublesome transactions and open a Technical Support call if

necessary.

• There is excessive JNDI chatter.

Monitor the JNDI call frequency in the LDAP request log and CPU utilization

of the LDAP server process. High CPU utilization combined with high call

frequency can indicate configuration issues. To check this, enable periodic

logging on the WTPrincipalCache as frequent JNDI lookups can mean an

undersized WTPrincipalCache. Use the logs to identify troublesome

transactions and open a Technical Support call if necessary.

• There is excessive RMI chatter.

Monitor the MethodSummary entries in the method server log to measure call

frequency. To check this, set property wt.method.verboseServer to log each

RMI call in the method server log. A chatty RMI client will likely experience

poor performance over a wide area network. Use the logs to identify such

transactions and open a Technical Support call if necessary.

• Missing or inappropriate indexing in Oracle or LDAP.

For information on indexing, see the Windchill Installation and Configuration

Guide - Advanced.


• Method server Cache Manager cache sizing.

To check sizing, enable the following property:

wt.cache.CacheManager.summaryInterval

and monitor the method server log.

• DNS latency.

Ensure DNS lookups complete quickly. Use the

wt.tools.hostname.TestHostName tool as described in the Resolving Domain

Names section of the CPU, Memory, Disk, Network Metrics chapter.

• CPU saturation.

Add hardware or check load balancing.

• Network latency.

Enable compression in Web server. Check latency between application and

database tiers.

• Oracle database disk I/O.

Ensure that data files are distributed across multiple physical disks or striped

across multiple spindles. Check that file system mount options are optimal

(for example, use directio).

• File vault disk I/O.

Ensure that data files are distributed across multiple physical disks or striped

across multiple spindles. Check that file system mount options are optimal for

file vaulting. For operating system specific recommendations, see the

Operating System Tuning appendix.

• Windchill diagnostic logging.

Be sure to disable verbose diagnostic logging such as wt.pom.log.stackTrace

and wt.pom.log.SQLStatements after generating a profile. Also, do not leave

the Windchill Profiler running for more than a few minutes at a time.

• Hotspot compilation disabled.

Ensure the –Xint flag is not present as a command line option for any

Windchill JVM.

• Client/Server TCP stack not tuned for high latency high bandwidth network

(long fat network).

Ensure client operating system TCP send buffer parameters are optimized for

bulk transfers over high latency connections. For operating system specific

recommendations, see the Operating System Tuning appendix.


Troubleshooting Flowcharts

The following sections provide steps to help you diagnose user response time and

general system performance problems.

Response Time Diagnosis

If you have determined that there is a performance problem with user response

times, use the following steps to diagnose the problem:

1. Is the problem isolated to a specific user operation?

If system appears generally unresponsive when executing a variety of user

actions go to the System Performance Diagnosis section later in this chapter.

2. Is the user operation a slow applet startup?

If so, refer to the client JAR tuning section in the Windchill Customizer’s

Guide. Also, check client TCP settings.

3. Generate a resource profile for the user action.

Collect the CPU times for each tier (client process, servlet engine, method

server, Oracle). Does the sum of all CPU times account for the majority of the

elapsed time? If yes, go to Step 6.

4. There is a high probability that the user transaction is I/O bound or queued on

some resource.

Determine which tier in the technology stack spends most time waiting for

I/O. Use the tools described in the CPU, Memory, Disk, Network Metrics

chapter to collect I/O measurements while exercising the transaction.

5. Locate I/O bottleneck. Client disk I/O, client/server network I/O, application

server disk I/O, application/database network I/O, database disk I/O.

See the CPU, Memory, Disk, Network Metrics chapter for information on

measuring disk and network performance.

If necessary, follow the directions in the Tuning Oracle for Customized

Windchill Applications section of the Oracle Tuning Guidelines appendix to

identify Oracle internal bottlenecks.

6. User action is CPU bound.

Is Oracle the top CPU time component? If not, go to step 8.

7. User action is CPU bound in Oracle.

See the Oracle Tuning Guidelines appendix for details on tracing and tuning

Oracle.


8. Is top CPU time method server?

See the CPU, Memory, Disk, Network Metrics chapter for steps to identify

which java process is consuming CPU resources. If not, go to Step 10.

9. User Action is CPU bound in method server.

Check MethodServer.log. Look for CacheManager summaries with low hit to

miss ratio.

Configure POM level logging as described in Server-side Diagnostic Logging

chapter or use the Windchill Profiler (see Windchill Customizer’s Guide).

Collect SQL and stack traces. Does the user action cause the method server to

execute a large volume of SQL? A high SQL round trip count is the most

common cause of poor performance. If you determine that the method server

application logic executes an excessive number of queries for the user

operation, then contact PTC technical support and supply the corresponding

Oracle and POM logs.

Do the timestamps between SQL statements suggest that distinct queries take

longer than a second or two to execute? If so then see the Oracle Tuning

Guidelines appendix for details on tracing and tuning Oracle.

10. Is top CPU time in servlet engine? If not, go to Step 12.

11. User Action is CPU bound in servlet engine.

Follow the procedure described in the Java Garbage Collector Tuning chapter

to determine frequency and duration of Garbage Collection.

Follow the procedure in the CPU, Memory, Disk, Network Metrics chapter to

identify CPU intensive threads and generate a thread dump.

12. Is top CPU time in client? If not go to Step 14.

13. User action is CPU bound in client.

14. User Action is CPU bound in other application such as Aphelion.


System Performance Diagnosis

If you have determined that there is a performance problem with general system

performance, use the following steps to diagnose the problem:

1. Check to see if the system is hung.

Does the Web server respond to requests for static resources (for example,

Windchill/wt.properties)? If no, then restart Web server and repeat Step 1.

2. Does the servlet engine respond to a request for a dummy servlet for example,

/Windchill/servlet/dummy?

The servlet engine should respond with an error. If instead the Web server

responds with an error, then restart the servlet engine and go to Step 1.

3. Do the Windchill server manager and method server respond to a command

line client? Open a command shell on the application server and issue the

following two commands:

windchill wt.method.RemoteMethodServer

windchill wt.manager.RemoteServerManager

In both cases the server should respond with a list of metrics name/value

pairs.

4. If the response to either request indicates an error for example, “Connection

Refused: connect”, then restart Windchill and go to Step 1.

5. Monitor CPU utilization on the application and database tiers.

Is the method server or servlet engine process accumulating CPU time? How

about Oracle or Aphelion?

If no processes appear active, the method server could be hung. If so, go to

Step 15.

6. Determine percent CPU time spent in garbage collection.

Follow the procedure in the Java Garbage Collector Tuning chapter to use

visualgc (or jvmsnap or loggc) to measure time spent in garbage collection. If

the time spent executing garbage collection is significant (10% or more), then

tune the generations as described in the Application Tuning chapter.

7. If Oracle is the primary consumer of CPU time, see the Oracle Tuning

Guidelines appendix for tracing and tuning information.

8. If the method server is the primary consumer of CPU time, then check

MethodServer.log.

Look for Cache Manager summary with low hit to miss ratio. Tune properties

as appropriate. See the Application Tuning chapter for more information.


9. Is the database and/or application server short on physical memory?

Look for virtual memory paging activity. Use the tools described in the CPU,

Memory, Disk, Network Metrics chapter to check for memory bottlenecks.

10. The server could be under heavy load and garbage collection is not excessive.

Analyze the corresponding MethodServer.log file; look for recent

MethodSummary and/or StatementCache summaries. Examine the

timestamps reported on each summary to check if any calls have recently

completed.

If there have been no recent MethodSummary or StatementCache log

messages written recently, it is possible that the method server is hung. If this

is the case, go to Step 15.

11. The method server is busy executing client requests. Is the number of active

contexts greater than the value for property wt.pom.maxDbConnections?

If no, go to Step 12.

If yes and there is spare CPU capacity, consider increasing the maximum

number of database connections. If that resource is saturated, consider adding

CPU resources.

Consider throttling simultaneous client requests that the servlet engine will

accept. See the Servlet Engine Tuning section of the Application Tuning

chapter.

12. Method server is busy but active contexts are below maxDbConnections.

If the CPU is not saturated, the method server could be I/O bound. Monitor

Aphelion and Oracle CPU time. Excessive Aphelion CPU time can be caused

by an insufficient size for wt.cache.WTPrincipalCache.

Monitor Oracle internal wait events. Look for excessive time spent in ‘db file

scattered read’. For details, see the Oracle Tuning Guidelines appendix.

13. High method server CPU time can be caused by an errant native thread. Does

method server process continue to consume CPU time even when there are no

active client requests?

If not, go to Step 15.


14. Check for runaway native thread.

Use pstat (Windows), pstack/ps (Solaris), glance (HP-UX) to determine the

ID of the CPU consuming thread. Capture a Java thread dump of the Java

process. See the CPU, Memory, Disk, Network Metrics chapter to learn how

to correlate native thread identifiers with Java threads. If you cannot find a

Java thread corresponding with the CPU consuming thread then it is most

likely a native thread. Check your Java Virtual Machine is at the latest patch

level.

If you have installed Windchill Index Search, check the method server logs

for errors. Temporarily disable Windchill Index Search and restart Windchill

to see if the thread is related to index search.

15. Method server is alive but not responsive.

Check wt.method.log.tee is set to false if the method server is running in the

background (for example, not attached to an xterm or DOS window). It will

be necessary to restart Windchill. Prior to restarting, collect thread dumps

from the running system as described in the Generating Thread Dumps

section in the CPU, Memory, Disk, Network Metrics chapter.


7CPU, Memory, Disk, Network

Metrics

This chapter describes various tools for monitoring CPU, memory, disk, and

network utilization.

Note: The tools described are intended to be examples of what is available for

your use. You can use other tools or other methods of monitoring.

Topic Page

CPU Analysis ......................................................................................................7-2

Memory Analysis ................................................................................................7-8

Disk Analysis ......................................................................................................7-9

Network Analysis ..............................................................................................7-12

7-1

CPU Analysis

The following sections provide information about analyzing the CPU usage for

Windchill.

Distinguishing Windchill Processes By Executable Name

When gathering CPU statistics for a set of Java processes it is useful to be able to

distinguish between method server and server manager processes. In order to

make this easier, PTC suggests that each Windchill process be assigned its own

copy of the Java executable as follows:

• On Windows, copy and rename the default java.exe as, for example, java_sm,

java_ms and java_bgms.

• On UNIX, construct symbolic links to the java executable using a similar

naming convention.

After renaming the Java executable, edit the appropriate properties in

wt.properties to reference the corresponding Java executable. For example, to

configure the server manager to use java_sm.exe, set the following property

values:

wt.java.smcmd=C\:\\jdk1.5.0\\jre\\bin\\java_sm.exe

wt.java.smcmd.quoted="$(wt.java.smcmd)"

wt.manager.cmd.ServerManager.java.command=$(wt.java.smcmd.quoted) ...

To configure the method server to use java_ms.exe, set the following property

values:

wt.java.mscmd=C\:\\jdk1.5.0\\jre\\bin\\java_ms.exe

wt.java.mscmd.quoted="$(wt.java.mscmd)"

wt.manager.cmd.MethodServer.java.command=$(wt.java.mscmd.quoted) ...

To configure the background method server to use java_bgms.exe, set the

following property values:

wt.java.bgmscmd=C\:\\jdk1.5.0\\jre\\bin\\java_bgms.exe

wt.java.bgmscmd.quoted="$(wt.java.bgmscmd)"

wt.manager.cmd.BGMethodServer.java.command=$(wt.java.bgmscmd.quoted) ...

wt.manager.cmd.BGMethodServer=cmd.exe /C start "BGMethodServer" /MIN

$(wt.manager.cmd.BGMethodServer.java.command)

wt.manager.cmd.BackgroundMethodServer=$(wt.manager.cmd.BGMethodServer) ...

CPU Statistic Snapshots

It is often useful to collect two or more CPU time snapshots for running processes.

This can reveal how much CPU time was consumed by each process in a given

interval. This is particularly useful when building a resource profile for a specific

user action. By collecting two snapshots – one immediately before and another

immediately after exercising the user action, you can measure how much of the

elapsed time was spent waiting because the CPU was busy versus time spent

waiting for I/O.


The following sections describe platform specific processes and tools for

collecting CPU statistics.

Windows Process CPU Statistics

On Windows platforms the Task Manager tool provides a high level view of

processes that are running. The processes may be sorted by CPU utilization to

show which process is consuming most CPU time at any instant. Unfortunately

the Task Manager cannot write the process data to file so it is difficult to view a

trend in utilization per process over a period of several hours. The tool also does

not report CPU time per thread.

In order to gather process data that includes per thread CPU time and that can be

written to a file, download a tool called pstat from Microsoft. For information on

pstat, see the Microsoft Web site.

Run the pstat from the command line or from a .bat script to capture information

on the running processes. There are two sections of interest in the resulting report.

The first section at the top of the report is where all process level statistics are

written. For each process we see User and Kernel CPU time, process id and

process name. The following extract shows the key statistics for oracle, server

manager, method server and background method server:

D:\tools>pstat

Pstat version 0.3: memory: 2095188 kb uptime: 27 7:21:38.381

PageFile: \??\D:\pagefile.sys

Current Size: 2095104 kb Total Used: 266564 kb Peak Used 543128 kb

Memory:2095188K Avail: 834932K TotalWs:1189548K InRam Kernel: 2344K P:86272K

Commit:1406708K/1238644K Limit:4037644K Peak:2374020K Pool N:51572K P:92200K

User Time Kernel Time Ws Faults Commit Pri Hnd Thd Pid Name

191664 22816490 File Cache

0:00:00.000 14:11:17.968 16 0 0 0 0 2 0 Idle Process

0:00:00.000 0:12:24.421 232 64607 28 8 584 64 4 System

<cut>

0:13:02.453 0:01:28.218519780 4277043 540040 8 213 11 340 oracle.exe

0:00:06.156 0:00:00.546 28748 21878 39216 8 544 30 10124 java_sm.exe

0:00:43.046 0:00:03.375112456 115256 110788 8 1078 23 8728 java_ms.exe

0:00:38.875 0:00:02.968115416 106121 113976 8 1134 48 9652 java_bgms.exe

The second section of interest lists the User and Kernel CPU for each of the

process’ threads. The following extract shows two of the threads for the method

server. Note that the value for the pid in this section is in hexadecimal (2218 hex

== 8728 decimal).

pid:2218 pri: 8 Hnd: 1248 Pf: 230043 Ws: 152052K java_ms.exe

CPU, Memory, Disk, Network Metrics 7-3

tid pri Ctx Swtch StrtAddr User Time Kernel Time State

1a88 9 4735 77E813F2 0:00:10.406 0:00:01.859 Wait:UserRequest

<cut>

24c8 15 3 77E7D295 0:00:00.000 0:00:00.000 Wait:UserRequest

Taking this one step further, it is usually possible to correlate a thread id (tid)

listed by pstat with thread info generated by a VM thread dump (Ctrl>Break in

this case). The following extract from a VM thread dump shows the thread with

nid=24c8 (nid == tid) is currently sleeping

Full thread dump Java HotSpot(TM) Server VM (mixed mode):

"RMI ConnectionExpiration-[JDOE:5001]" daemon prio=10 tid=0x04aa8e90 nid=0x24c8

waiting on condition [3ebf000..3ebfdb4]

at java.lang.Thread.sleep(Native Method)

at sun.rmi.transport.tcp.TCPChannel$Reaper.run(TCPChannel.java:447)

at java.lang.Thread.run(Thread.java:534)

Note: The VM thread dump only includes threads that have Java call stacks.

Native (non Java) threads started by the VM itself (or spawned by JNI) are not

included.

Solaris Process CPU Statistics

The procedure for collecting process CPU times on Solaris is similar. The

simplest way to measure a process’ CPU time is to use the ps command.

nansen$ /usr/ucb/ps auxw | head

USER PID %CPU %MEM SZ RSS TT S START TIME COMMAND

wtadmin 6033 20.0 4.71704216184400 pts/4 O 10:33:15 1:33

/usr/j2se/jre/bin/java_ms -server -classpath /mnt/disk2/Windchill80/co

wtadmin 6029 3.7 2.338231289296 pts/3 S 10:33:12 0:22

/usr/j2se/jre/bin/java_sm -server -classpath /mnt/disk2/Windchill80/co

root 898 1.4 9.8544640388600 ? S Feb 21 3572:01

/usr/j2se/bin/java_tomcat -server -Xms64M -Xmx1024M -Djava.endorsed.di

This reveals that the method server process (java has been copied to java_ms) has

a pid of 6033 and has consumed 1 minute 33 seconds of CPU time. In order to list

the CPU time consumed by each running thread in the method server use ps –Lp

<pid>. For example:

nansen$ ps -Lp 6033

PID LWP TTY LTIME CMD

6033 1 pts/4 0:58 java_ms

6033 2 pts/4 1:11 java_ms


<cut>

6033 97 pts/4 0:02 java_ms

On Solaris threads are mapped to Lightweight Processes (lwp). In this example

threads are distinguished by the LWP number. The LWP ids are shown in

decimal. To find the corresponding thread in a VM thread dump look for an nid

with the hexadecimal equivalent – for example, LWP 97 is nid=0x61

"RMI TCP Connection(15)-132.253.9.26" daemon prio=6 tid=0x00d2a770 nid=0x61 runnable

[90c7d000..90c7fc28]

HP-UX Process CPU Time

Like most UNIX variants, HP-UX has the ps command that reports process CPU

time. Use ps –efl to gather CPU time for all running processes.

HP-UX does not have a command line tool that will list per-thread CPU time.

This data is available with the HP glance tool. Refer to the glance man page for

more information.

On HP-UX, use the glance tool to identify per thread CPU time. Thread

identification and correlation between Glance and thread dump can be performed

in a manner similar to what you would do for Solaris and Windows.

CPU Resource Profile

By running either pstat or ps commands immediately before and after running a

user action, it is possible to measure per process CPU time. This is achieved

simply by subtracting each process CPU time gathered in the first sample from the

second sample.

In order to express the CPU time for a user operation as a percentage of elapsed

time, calculate the sum of CPU times for all processes divided by the elapsed time

multiplied by 100. For example, the following table lists CPU times by process for

a hypothetical user operation that has a response time of 15 seconds:

CPU time accounts for 88% of the elapsed time ((13200/15000)*100) and over

50% of the elapsed time is consumed by the method server and Oracle.

Process Name CPU Time (ms)

Client browser 4000

Apache 200

Tomcat 2000

Method Server 5000

Oracle 2000

13200


Detecting CPU Bottlenecks

To monitor system level CPU utilization (for example, all processes) over a

longer period of time use a tool such as perfmon or sar.

In the case of perfmon, PTC recommends that you collect the following

object/counter combinations and monitor the data over several intervals.

On Solaris, use the uptime or top command to monitor the load average. The load

average is the sum of the run queue and the number of jobs currently running on

CPUs. See the corresponding man pages for more information.

Generating Thread Dumps

If a system performance monitor indicates high level of CPU consumption due to

a Java process, a thread dump from the offending process will help with

troubleshooting. The following sections describe how to generate thread dumps.

Object \ Counter

Suggested

Threshold Comments

Processor \ % Processor

Time

95% Upgrade to a processor with a larger L2 cache, a

faster processor, or install an additional processor.

Processor \

Interrupts/sec

Depends on

processor

A dramatic increase in this counter value without a

corresponding increase in system activity indicates a

hardware problem. Identify the network adapter

causing the interrupts. Use the affinity tool to

balance interrupts in a multiprocessor system.

Processor \ % Interrupt

Time

Depends on

processor.

An indirect indicator of the activity of disk drivers,

network adapters, and other devices that generate

interrupts.

Server Work Queues \

Queue Length

4 Tracks the current length of the server work queue

for the computer. If the value reaches this threshold,

there may be a processor bottleneck. This is an

instantaneous counter; observe its value over several

intervals.

System \ Processor

Queue Length

2 This is an instantaneous counter; observe its value

over several intervals. A queue of two or more items

indicates a bottleneck. If more than a few program

processes are contending for most of the processor's

time, installing a faster processor or one with a larger

L2 cache will improve throughput. An additional

processor can help if you are running multithreaded

processes, but be aware that scaling to additional

processors may have limited benefits.


Solaris and HP-UX Thread Dumps

To record a thread dump on Solaris or HP-UX where the method servers are

running in terminal windows (xterm), use the following steps:

1. Type ps -ef | grep java at a command line to find the process id (PID).

2. After you know the process id, type kill –3 pid to kill the process, where pid is

the process id number.

If the method servers are not configured to run in xterm windows, you need to

redirect the ‘standard error’ of the shell running the method servers. This can be

done by modifying the wt.manager.cmd.MethodServer property to launch the

method server in a shell script. See the Windchill System Administrator’s Guide,

for a description of how you edit Windchill properties files.

wt.manager.cmd.MethodServer=/opt/windchill/scripts/launch.ksh

Where the launch.ksh script is simply:

#!/bin/ksh

/opt/java1.5/jre/bin/java –server -Xms128m -Xmx256m -Xnoclassgc

wt.method.MethodServerMain > /opt/ptc/threads.log 2>&1

When the kill –3 is sent to the JVM, the thread dump will be written to the file

/opt/ptc/threads.log (along with any other System.stderr errors which would

normally appear in a method server window).

Windows Thread Dumps

On a Windows operating system, a thread dump can be generated by entering

CTRL->BREAK in the command window in which the Java VM is running.

How to Fix CPU Bottlenecks

After performing other tuning actions (as described in earlier chapters) and

verifying that there is a CPU bottleneck, consider doing one or more of the

following:

• Switch to CPUs with a larger L2 cache.

• Switch to faster CPUs.

• For multiprocessor systems, add more CPUs.

• On multiprocessor computers, manage the processor affinity with respect to

process threads and interrupts.

• Configure a load balanced hardware cluster as described in the Windchill

Advanced Deployment Guide.

• Throttle back the number of concurrent requests in the servlet engine.

Contact PTC for help in determining a recommended approach to fixing CPU

bottlenecks.


Memory Analysis

The following sections provide information about analyzing the memory usage

for Windchill.

Memory Statistic Snapshots

In order to make optimal use of available RAM, you must monitor the RAM

footprint of each of the running Java Virtual Machines. Your goal should be to

size each JVM to make use of available physical RAM while leaving sufficient

RAM available to the operating system and minimizing virtual memory paging.

Using a 32bit JVM, it is possible for a process to address up to 4GB of memory.

However, due to certain operating system limitations, code pages, shared libraries

and the like, the practical limit is somewhat lower:

• On 32bit Windows platforms, a maximum of 2GB of memory is allocated to

all user processes while remaining memory (up to 2GB) is reserved for the

operating system. However, in order to accommodate both executable and

data in the 2GB address space, the maximum JVM heap size is 1.6GB.

• On Solaris and HP-UX, the 32bit JVMs can support a heap size up to 3.8 GB.

Depending on the operating system and hardware platform it may be possible to

run multiple 32bit JVMs, each with a heap sized up to 3.8GB. See your operating

system and hardware vendor for more information.

To measure the amount of memory in use by each JVM, use operating system

specific tools:

• On Windows, use TaskManager with the Memory Usage column selected.

• On Solaris, use the pmap tool to report on the various memory regions

allocated by a process. See the man page for pmap for more information.

• On HP-UX, use the Glance tool to monitor a process' memory regions.

Detecting Memory Bottlenecks

Memory can become a bottleneck when there is not enough physical RAM to

maintain all the application data.


On Windows, use the perfmon tool to collect the objects and counters shown in

the following table.

On Solaris, use the vmstat command and monitor the ‘scan rate’(sr) column . Non

zero values indicate that the page scanner is hunting for pages to reclaim. This can

be a sign that the system is running short of available physical memory. If the

value stays above 200 pages per seconds for long periods then the system is short

of memory.

On HP-UX, use the sar and Hpjconfig tools to monitor and tune memory

allocation. For more information, see the following topic on the HP Java

Technology Web site:

http://www.hp.com/products1/.../prog_guide/measuring_sys_performance.html

How to Fix Memory Bottlenecks


verifying that there is a memory bottleneck, consider doing one or more of the

following:

• Increase physical memory above the minimum required.

• For monolithic configurations, move Oracle or Aphelion (or both) to a

separate server.

• Reduce the maximum heap size of one or more JVMs.

• Reduce the number of method server processes.

Note: Changing the heap size can create additional problems such as CPU

bottlenecks.

Disk Analysis

The following sections provide information about analyzing the disk usage for

Windchill.

Object \ Counter Suggested Threshold Comments

Memory \ Available Bytes

Memory \ Pages/sec

64 MB If the Available Bytes counter stays

below the system-defined minimum

level and the value for Pages/sec

counter peaks continuously, you

probably need to add memory to your

computer.

Server \ Pool Paged Peak Amount of physical RAM This value is an indicator of the

maximum paging file size and the

amount of physical memory.


http://www.hp.com/products1/unix/java/infolibrary/prog_guide/measuring_sys_performance.html

Detecting Disk Bottlenecks

The following section describe platform-specific tools for detecting disk

bottlenecks.

Windows

Measuring and recording disk I/O on Windows may be accomplished with the

perfmon tool (Control Panel->Administrative Tools->Performance. Use the

perfmon tool to collect the Objects and Counters listed in the following table.

Using perfmon, select the PhysicalDisk from the list of Performance Objects.

There are a variety of useful statistics that can be collected. We suggest at a

minimum %Disk Time, Current Disk Queue Length and Split I/O per sec. After

selecting each counter press the Add button. Click Explain for more information

on each of the available statistics.

UNIX

Disk I/O can be measured and collected with the iostat command. The iostat –x

command provides extended statistics and is easy to read when there are a large

number of disks to monitor. The values reported are the number of transfers and

kilobytes per second (reads and writes are shown separately); the average number

of queued commands; the average number of commands being processed; the I/O

service time; and the percentages of the time that commands were waiting in the

queue; and commands that were active on the drive. For example the following

command writes disk activity to stdout every 5 seconds for a total of 5 samples:

nansen$ iostat -x 5 5

extended device statistics

device r/s w/s kr/s kw/s wait actv svc_t %w %b

md3 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0

Object \ Counter Suggested Threshold Comments

PhysicalDisk \ % Disk Time 90% Add more disk drives and partition the

files among all of the drives.

PhysicalDisk \ Disk

Reads/sec, PhysicalDisk \

Disk Writes/sec

Depends on

manufacturer's

specifications

Check the specified transfer rate for

your disks to verify that this rate doesn't

exceed the specifications. In general,

Ultra Wide SCSI disks can handle 50

I/O operations per second.

Physical Disk \ Current Disk

Queue Length

Number of spindles

plus 2

This is an instantaneous counter;

observe its value over several intervals.

For an average over time, use Physical

Disk\ Avg. Disk Queue Length.


sd6 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0

sd9 0.0 0.0 0.0 0.0 0.0 24.0 0.0 0 100

sd10 2.0 0.0 10.0 0.0 0.0 0.0 9.4 0 2

Alternatively, use iostat -xpn to list activity on each of the partitions across all

disks. Then use the mount command to view the file systems mounted on the

partitions.

The iostat command on HP-UX reports I/O statistics for each active disk on the

system. The disk data is arranged in a four column format showing the device

name, Kilobytes transferred per second, number of seeks per second and

millisecond per average seek (msps is always 1.0). The glance tool provides more

detailed information about disk I/O.

tom$ iostat 5 5

device bps sps msps

c1t15d0 -0 -0.0 1.0

c3t15d0 -0 -0.0 1.0

c1t15d0 518 36.4 1.0

How to Fix Disk Bottlenecks

If the server uses a RAID, add more disk drives, using faster drives if possible,

and increase the memory cache size on the controller. If the server does not use a

RAID, switch to higher-speed disk drives.

Use Disk Defragmenter to optimize disk space.

If the busy disk holds Oracle data or index files, then you should profile the SQL

being executed. Use either the Oracle Enterprise Manager or the Automatic

Database Diagnostic Monitor reports to determine which Oracle data file is most

frequently accessed. It is possible that the high disk activity is caused by

inefficient execution plans that may be resolved by the creation of additional

indexes.

Also, follow directions in Tuning Oracle for Customized Windchill Applications

section of the Oracle Tuning Guidelines appendix to identify Oracle internal

bottlenecks.

You may need to stripe the file systems for the Oracle data files over multiple

disks. Alternatively, the data files associated with the BLOB and UNDO

tablespaces may be placed on a raw device or unbuffered file system.

If the busy file system is used to hold file vault folders, it is best to use a buffered

file system.


For client-side disk bottlenecks, look at disk fragmentation, the browser cache

sizing, and the browser policy that governs when the browser checks for newer

versions of Web resources. Consider installing a RAM-based browser cache (for

example, install a RAM disk utility).

Network Analysis

The following sections provide information about analyzing the network for

Windchill.

Measuring Network Traffic

To measure the amount of data transferred over RMI between the method server

and clients, you can use the wt.method.RemoteMethodServer command line tool.

For example:

> java wt.method.RemoteMethodServer

Start date = Fri Jun 08 13:29:27 CDT 2007

Total RMI invoke calls = 155

Total method contexts = 156

Active method contexts = 0

Current free memory = 98282168 bytes

Current total memory = 133955584 bytes

RMI client sockets = 3

RMI bytes in = 1959595

RMI bytes out = 2780382

Database connections = 5

This extract shows the number of bytes read and written on the network by an

individual method server.

Alternatively both commercial and freeware tools are available to collect the

network data. On Solaris, the snoop utility can be used to capture and analyze

network traffic. Web server log files can be useful for collecting data also.


Detecting Network Bottlenecks

A network bottleneck is frequently associated with a high latency or highly

utilized network segments in one or more tiers between client and server.

To determine which routers lie between the client and server, use tracert

(Windows) or traceroute (HP-UX and Solaris). Then use ping on each router to

measure round trip times. Round trip latencies between servers on local area

networks should generally be in the range 0-20 milliseconds. Wide area network

latencies frequently exhibit latencies in hundreds of milliseconds. High latencies

can significantly increase client response times for large data transfers.

To capture network packets, use network tracing tool netmon, windump

(Windows), snoop (Solaris), or tcpdump (HP-UX) .

Check that the network has adequate bandwidth between the Oracle server and

Windchill server or servers. Heavily utilized or misconfigured network interfaces

can significantly degrade performance.

One symptom of network problems is low CPU and disk utilization when the

server is under load. A rough estimate of network throughput can be made using

FTP. In theory, a 10Mbit/sec network is capable transferring 1.25Mbytes per

second. Similarly, a 100Mbit/sec network should transfer up to 12.5Mbytes per

second. Use FTP in binary mode to transfer a several megabyte file between

servers in the network. On completion, FTP will report how many bytes were

transferred per second. If the throughput reported by FTP is significantly different

from the rating of the network, it is likely that the method servers will be starved

of data.

Note: The performance of disks at either end of the transfer can affect the

throughput reported by FTP.

On Windows, use perfmon to collect the objects and counters listed below. To

analyze the statistics for your network segment, install Network Monitor.

Object \ Counter

Suggested

Threshold Comments

Network Segment \ %

Net Utilization

Depends on type

of network

For full-duplex, switched Ethernet networks, for

example, 80 percent can indicate a bottleneck.

Processor \

Interrupts/sec

Depends on

processor

A dramatic increase in this counter value without a

corresponding increase in system activity indicates

a hardware problem. Identify the network adapter

causing the interrupts. Use the affinity tool to

balance interrupts in a multiprocessor system.


On Solaris, use netstat –s:

TCP tcpRtoAlgorithm = 4 tcpRtoMin = 400

tcpRtoMax = 60000 tcpMaxConn = -1

tcpActiveOpens =268751 tcpPassiveOpens =762338

tcpAttemptFails = 52836 tcpEstabResets = 3538

tcpCurrEstab = 40 tcpOutSegs =158902249

tcpOutDataSegs =135077455 tcpOutDataBytes =3513185842

tcpRetransSegs = 15493 tcpRetransBytes =3075364

tcpOutAck =23773785 tcpOutAckDelayed =4631349

tcpOutUrg = 2 tcpOutWinUpdate =102660

tcpOutWinProbe = 3693 tcpOutControl =2066461

Server \ Work Item

Shortages

3 If the value reaches this threshold, consider tuning

InitWorkItems or MaxWorkItems in the registry

(under HKEY_LOCAL_MACHINE\SYSTEM\

CurrentControlSet\Services

\LanmanServer).

Server \ Bytes Total/sec If the sum of Bytes Total/sec is roughly equal to the

maximum transfer rates of your network, you may

need to segment the network.

Network Segment \

Broadcast frames

received/second

Depends on

network

Can be used to establish a baseline if monitored

over time. Large variations from the baseline can

be investigated to determine the cause of the

problem. Because each computer processes every

broadcast, high broadcast levels mean lower

performance.

Network Segment \

% Network utilization

Depends on

network

Indicates how close the network is to full capacity.

The threshold depends on your network

infrastructure and topology. If the value of the

counter is above 30 to 40 percent, collisions can

cause problems.

Network Segment \

Total frames

received/second

Depends on

network

Indicates when bridges and routers might be

flooded.

Object \ Counter

Suggested

Threshold Comments


tcpOutRsts = 59983 tcpOutFastRetrans = 1549

tcpInSegs =160269847

tcpInAckSegs =112714620 tcpInAckBytes =3510005295

tcpInDupAck =836924 tcpInAckUnsent = 0

tcpInInorderSegs =127944295 tcpInInorderBytes =1062963776

tcpInUnorderSegs = 9787 tcpInUnorderBytes =2875249

tcpInDupSegs = 16580 tcpInDupBytes =3782883

tcpInPartDupSegs = 29 tcpInPartDupBytes = 32770

tcpInPastWinSegs = 0 tcpInPastWinBytes = 0

tcpInWinProbe = 12119 tcpInWinUpdate = 3694

tcpInClosed = 208 tcpRttNoUpdate = 2346

tcpRttUpdate =112071038 tcpTimRetrans = 9670

tcpTimRetransDrop = 0 tcpTimKeepalive = 38614

tcpTimKeepaliveProbe= 11315 tcpTimKeepaliveDrop = 0

tcpListenDrop = 0 tcpListenDropQ0 = 0

tcpHalfOpenDrop = 0 tcpOutSackRetrans = 164

The number of currently established connections is reported by tcpCurrEstab.

The number of times that a connection was dropped because of a full listen queue

is reported by tcpListenDrop. The maximum listen backlog is set by the ndd

tunable tcp_conn_req_max.

Outgoing data is divided into segments with each segment corresponding to an

Ethernet packet. tcpOutSegs reports the total number of segments output

(comprising mostly tcpOutDataSegs and tcpOutAck). tcpOutDataBytes reports

the total number of bytes output. tcpRetransBytes counts the number of bytes that

required retransmission. If the percentage tcpRetransBytes is greater than around

30% of tcpOutDataBytes then there may be a bad or congested network.

Incoming data is reported by the various tcpIn* counters. Of most interest are the

counters for duplicated data (tcpInDupSegs, tcpInDupBytes, etc). Incoming

segments may be duplicated when an acknowledgement is lost or delayed and the

other end retransmits a segment that actually arrived correctly the first time. This

can be a sign that the remote end is retransmitting too quickly.


How To Fix Network Bottlenecks


verifying that there is a network bottleneck, consider doing one or more of the

following:

• Enable compression in the Web server.

• Prevent network bandwidth saturation by throttling the number of

simultaneous HTTP requests handled by the Web server or servlet engine.

• Configure replica vaults to store content files close to remote clients.

• Implement WAN optimization technology to reduce volume of data that is

transferred.

• Partition the network load so that it is balanced among all network adapters in

the server. For example, you can use VLANs in a switch connected to the

server.

• Use smart network adapters to take advantage of the advanced offloading

features in Windows 2003.

• Move source data close using technology such as replication.

• Add more network adapters to increase the available bandwidth, although

doing so will increase the interrupt load on the CPU if you use “dumb”

network adapters.

• Change to a higher-speed network, for example, upgrade to gigabit

networking from 100Base-TX.

• Unbind infrequently used network adapters.

Resolving Domain Names

Problems with TCP name resolution can appear as serious performance problems.

The servlet engine may perform a reverse name lookup using the client IP

address. To measure name lookup performance, run the command:

java wt.tools.hostname.TestHostName client_ip_address

Ideally, the name resolution service will return a result in no more than 400

milliseconds and should be less than 20 milliseconds. Any results that are

consistently several seconds long indicate name look-up problems.


AOracle Tuning Guidelines

This appendix provides information about Oracle tuning guidelines.

Topic Page

Improving Oracle Database Performance ..........................................................A-2

Approximating the Initial Instance Memory Size ..............................................A-2

Further Memory Size Redistribution and Tuning ..............................................A-6

Gathering and Maintaining System Performance and Data Distribution Statistics .

A-7

Oracle Database Performance Baselines............................................................A-8

Tuning Oracle for Customized Windchill Applications...................................A-11

Oracle Tools to Collect Database Performance Statistics ................................A-13

Reporting Performance Problems to PTC........................................................A-13

A-1

Improving Oracle Database Performance

Oracle tuning has a substantial impact on performance. Recommended Oracle

tuning activities include the following:

• Tune SGA that governs various caches - DB Buffer Cache, Shared Pool,

Large Pool, Log Buffer, and so on.

• Tune PGA.

• Tune undo and redo activities.

• Gather and tune both data and system statistics.

• Analyze and improve CPU and I/O intensive queries (and possibly queries of

other resource types).

• Identify and index sets of columns that are often used in condition clauses.

• Identify and remove indexes that are heavy or too scattered, and do not

provide significant performance improvement.

• Merge or split indexes.

The sections in this appendix provide introductory information relating to Oracle

tuning. See the Oracle Database Performance Tuning Guide for detailed

information.

For help in tuning your Oracle 10g database for Windchill activities, consider

using the Oracle 10g Tuner provided by PTC. For details, see the Oracle 10g

Tuner for Windchill Solutions Installation and Configuration Guide. You can

access this guide from the Reference Documents link of the PTC Web site. See

Documentation for PTC Products.

If you are using the Oracle 10g Tuner, do not manually tune the database.

Approximating the Initial Instance Memory Size

This section outlines some basic tuning information that you can use to help

achieve the advertised performance of the Oracle database. It assumes that the

hardware for the Oracle server will sustain the required load in accordance with

the sizing guidelines provided by PTC. Documents containing the sizing

guidelines are available from the Reference Documents section of the PTC Web

site at the following URL:


Browse for the Hardware Sizing Guidelines for your server by selecting the

Windchill product, 9.0 release, Installation and Configuration Guide document

type, and the Administrator user role.

A-2 Windchill Performance Tuning Guide


The following Oracle parameters and terms are used in the initial configuration:

• SGA - The System Global Area is a combination of memory structures

including different types of caches or pools. The structures include: DB buffer

cache, Shared Pool, Large Pool, Java Pool, Log Buffer. SGA effective size is

derived from the size of its content.

SGA_MAX_SIZE - Provides the upper size boundary that limits SGA size

during dynamic configuration. This value is fixed; if you change it, you must

reboot the database.

SGA_TARGET - Specifies the desired amount of memory that governs

following SGA caches:

DB Buffer Cache?

Shared Pool

Large Pool

Java Pool

Stream Pool

If automatic memory management (AMM) is turned on by setting

SGA_TARGET to a value greater than 0, then the Oracle engine dynamically

redistributes memory among the mentioned pools and caches. Any explicit

size settings are then overridden by AMM subroutines.

If the SGA_TARGET value is greater than the value of SGA_MAX_SIZE,

then the SGA_TARGET value supersedes the SGA_MAX_SIZE value.

Automatic memory management is disabled if the SGA_TARGET value is 0.

A value of 0 cannot be changed without a restart.

• DB Buffer Cache - Is designed to cache the most recently used table and

index data. It is a combination of the standard cache and several auxiliary

(non-standard) caches.

DB_CACHE_SIZE - Sets the size of the DB Buffer Cache. This value is

dynamic; it can be increased or reduced provided that the combined size of

other components is inside the limit of SGA_MAX_SIZE.

Note: Out of the box, Windchill does not require or benefit from

non-standard DB buffer caches. Their respective size is by default 0 and their

description is out of scope of this appendix. All further references to the DB

Buffer Cache are limited to the default cache.

• Shared Pool - The main purpose of the Shared Pool structure is to cache SQL

requests to the database as well as associated object, dependencies, and

security definitions.

SHARED_POOL_SIZE - Determines the size of the Shared Pool. This value

is dynamic; it can be shrunk or extended the same as DB_CACHE_SIZE.

However, sometimes the shrinking of the Shared Pool cannot be

accomplished.

Oracle Tuning Guidelines A-3

Note: Currently, the Oracle server makes decreasing the Shared Pool cache

size dynamically virtually impossible if that cache is heavily used and has

become fragmented. If the Shared Pool cache is found to be under used, the

database administrator can decrease its size by changing the

SHARED_POOL_SIZE parameter value in the SPFILE or init.ora file. After

changing the SHARED_POOL_SIZE parameter value, you must restart the

database.

• Large Pool - Is reserved for specific types of memory allocation. For instance,

allocation from this pool can serve message buffers during parallel execution,

or can be used to process private data when a shared server is configured. The

Backup and Restore Manager, RMAN, also allocates memory from the Large

Pool.

LARGE_POOL_SIZE - Determines the size of Large Pool. This parameter

can be changed dynamically in the boundaries of available space under

SGA_MAX_SIZE.

• Java Pool - Is used to serve Oracle JVM allocations during calls to Java stored

procedures. Although the out-of-the-box Windchill functionality does not call

Java stored procedures, certain Oracle database actions that are used

internally or by Oracle Enterprise Manager make calls to

DBMS_METADATA, DBMS_XML, and others that require this pool.

JAVA_POOL_SIZE - Sets the size of the Java Pool. This parameter can be

changed dynamically in the boundaries of available space under

SGA_MAX_SIZE.

• Log Buffer - Almost every action in the database generates information that is

used to recover data from several types of crashes. This information is called

redo records or change vectors. The information is permanently stored in

online redo logs. A pool is used to cache and synchronize write requests to

redo logs.

LOG_BUFFER - Sets the size of the redo buffer cache. This parameter is

fixed and cannot be changed dynamically.

• PGA - The Program Global Area is a portion of an Oracle server process that

performs actions in the database on behalf of a session. This portion contains

private information of a single server process and is not shared between

different sessions. PGA is allocated from heap memory dynamically and is

returned to the heap upon completion of an operation.

PGA_AGGREGATE_TARGET - Roughly outlines the cumulative

boundaries of the private areas. It can be changed dynamically.

• Streams Pool - Caches Oracle Streams data. Oracle Streams is a feature that

manages and propagates data, transactions, or events within one database or

between several databases.

STREAMS_POOL_SIZE - Sets the size of the Streams Pool.


The first step during sizing of an Oracle instance is to determine capacity of the

system and, specifically, the size of available memory dedicated to the Oracle

database.

• The total Oracle memory should not be more than what is available. If any

memory portion of Oracle instance or server process that serves client

requests is swapping, performance of the whole system is severely damaged.

• If the database is the only application running on the server, then using 80%

of the server RAM is a good starting point. Initially, you should not set the

available memory of an Oracle instance to more than 80% of the available

RAM.

• If there are other applications running on the server, determine how much

memory is already being used by the other applications and then determine

how much of the remaining memory can be allocated for use by the database.

The available memory should serve as starting point for planning

SGA_MAX_SIZE and its contributors, as well as the

PGA_AGGREGATE_TARGET. To plan distribution of maximum available

memory between all required components use the following formulas:

• Sum of SGA components should be equal or less than SGA_MAX_SIZE:

SGA_MAX_SIZE >= SGA_TARGET + LOG_BUFFER

Note: If SGA_MAX_SIZE is less than SGA_TARGET at startup, then

SGA_MAX_SIZE becomes equal to SGA_TARGET.

• Sum of SGA_MAX_SIZE and PGA_AGGREGATE_TARGET should be

equal to or less than the maximum available memory.

Any attempt to exceed maximum available memory limit will most probably

result in memory swapping or out of memory errors. When initially setting

these parameters, remember that SGA_MAX_SIZE is a static parameter

whereas PGA_AGGREGATE_TARGET and SGA_TARGET can be

changed dynamically without restarting the database.

MAX AV. MEM >= SGA_MAX_SIZE or SGA_TARGET +

PGA_AGGREGATE_TARGET


Following provides rough initial sizing of individual components in the above

formulas:

When using manual configuration (for example, when Automatic Memory

Management is disabled), Streams Pool Size can initially be set to 0, in which

case, it automatically subtracts 10% of the effective SGA size from

DB_CACHE_SIZE upon a new request to the Oracle Streams. If Oracle Streams

functionality is not utilized, this pool is kept un-initialized.

Further Memory Size Redistribution and Tuning

Maintenance activities that are outlined in this section should be performed after

initial deployment and after any changes to the environment including system

load profile, hardware, SGA_MAX_SIZE changes, and

PGA_AGGREGATE_TARGET changes.

When you are not using Automatic Memory Management, the tuning of the DB

Buffer Cache, Shared Pool and Java Pool in most cases requires consulting with

the advisories that can be enabled by using parameter

STATISTICS_LEVEL=TYPICAL (default value) or ALL.

Using the advisories for DB Buffer Cache, Java Pool and Shared Pool tuning is

described in the "Memory Configuration and Use" chapter of the Oracle

Performance Tuning Guide.

Tuning Large Pool is based on other Oracle performance views as described in the

"Memory Configuration and Use" chapter of the Oracle Performance Tuning

Guide.

Parameter1

1. DB_CACHE_SIZE, SHARED_POOL_SIZE, LARGE_POOL_SIZE, JAVA_POOL_SIZE become ineffective if Automatic Memory Management is chosen by setting SGA_TARGET to a non 0 value and STATISTICS_LEVEL to TYPYCAL (default) or ALL. These pools usually do not require individual tuning under supervision of automatic tuning. Their combined size is determined by parameter SGA_TARGET.

Initial Value

DB_CACHE_SIZE 256M

LOG_BUFFER 20971520

SHARED_POOL_SIZE 128M

LARGE_POOL_SIZE 16M

JAVA_POOL_SIZE 16M

SGA_TARGET 416M

PGA_AGGREGATE_TARGET WT Connections *5M

SGA_MAX_SIZE 80% RAM -

PGA_AGGREGATE_TARGET


Process of monitoring tuning PGA is described in the "Memory Configuration

and Use" chapter of the Oracle Performance Tuning Guide.

In addition to the manual tuning of SGA components, Automatic Shared

Memory Management can be used to manage SGA memory (specifically, the

combination of DB Buffer Cache, Shared Pool, Large Pool, Java Pool, and

Streams Pool). To use Automatic Shared Memory Management, set the

SGA_TARGET parameter to a non 0 value as well as STATISTICS_LEVEL to

TYPICAL (default) or ALL.

Gathering and Maintaining System Performance and Data

Distribution Statistics

Performance of an application is very dependant on the amount of time spent in

Oracle serving SQL statements, and the performance of most SQL statements

depends on how well the statements are optimized. Optimization of SQL

statements is done by Cost Based Optimizer (CBO).

CBO bases its optimization activities on auxiliary information including the

statistics about current operating system and data distribution in the application

tables. It also considers cost of executing SQL statements using indexes.

Quality and freshness of this auxiliary information significantly affects the

accuracy of CBO optimization and, subsequently, time required to complete SQL

statements. Inaccurate, stale, or missing statistics can make even simple SQL

statements run for hours.

Note: The performance of some SQL queries can fluctuate slightly from the

advertised numbers, depending on the rate of growth of the data in the beginning

of the life cycle of the system and rate at which statistics are updated. This can

also be apparent during data migration process. After the system has grown to a

certain point (data maturity time depends on the activity rate and data flow

amount,) such fluctuations should stop. To proactively troubleshoot this problem

for less volatile tables, the rate of data distribution statistics should be increased

for the stabilization period. For very volatile tables, statistics should be locked.

Oracle 10g gathers basic data distribution statistics and no-workload system

performance statistics.

If you are using the Oracle 10g Tuner, all of the statistics that are required for

good performance statistics are automatically gathered and updated; you can skip

the following section. For more information, see the Oracle 10g Tuner for

Windchill Solutions Installation and Configuration Guide.

For information on types and customization of system performance and data

distribution statistics, see to the Oracle Performance Tuning Guide.


Gathering and Updating System Performance Statistics

To gather system performance statistics, complete following steps during peak

loads when the performance is believed to be stable.

1. Start gathering system statistics by executing the following:

>sqlplus <system>/<passwd>

SQL> exec dbms_stats.gather_system_stats('Start');

2. Wait for one to two hours.

3. Stop gathering the statistics:

SQL> exec dbms_stats.gather_system_stats('Stop');

Note: Use these same steps to recalculate system performance statistics at any

time in the future.

Oracle Database Performance Baselines

First and most important step to ensure good and stable performance of your

system is capturing Oracle database performance statistics (different from system

performance statistics) at peak loads for a definite time frame when the system is

believed to be in good condition. A preserved range of snapshots of performance

statistics captured during specific time frame is called the performance statistics

baseline for that time frame.

Any particular system may require more than one performance baseline to

describe different types of load on the system. For example, establish a baseline

for normal online request operation during day and establish another baseline for

batch processing or reporting functionality at night. To capture a fluctuating load,

you might need to gather and store baselines for wider periods in addition to short

term baselines.

Baselines should be initially established for any unique process or time frame

during which peak load on the system is observed. At the beginning of the life

cycle of the system or after significant reconfiguration or customization, establish

a baseline based on a range of snapshots for at least a week of system operation.

Database performance snapshots that will be used for baselines should be

captured at a higher detail level than the default to gather more information that

can be used to diagnose performance issues in future.

Baselines should be based only on snapshots gathered when the system

performance appears to be stable. Bad or jumpy performance will make baselines

unusable.

Future performance fluctuations can be diagnosed by comparing current database

performance statistics to a corresponding baseline. This can help to identify one or

a set of degraded performance statistics.


Administrators are advised to reestablish performance baselines as soon as

possible after the system is altered in any way. The alteration can be changes in

software or hardware configuration, software or hardware customization, or the

load profile.

Oracle 10g, by default, gathers performance statistics and stores them in

Automatic Workload Repository.

For information on manual performance statistics gathering or working with

performance baselines in Oracle 10g see the Oracle 10g Database Performance

Tuning Guide and Reference.

Oracle 10g provides exceptional reporting functionality which should be used to

troubleshoot problems as well as, on a regular basis, to verify short and long term

performance trends.

Note: These reports, based on snapshots pertaining to performance degradation

time frame and corresponding baselines, must be submitted when opening

performance technical support calls.

Establishing Performance Baselines

Use the following information to capture performance snapshots and store

baselines.

Before monitored activity is started, increase the snapshot detail level and number

of statistics collected.

Enter:

connect system/manager

alter system set statistics_level=all;

exec dbms_workload_repository.create_snapshot();

Keep track of the times when the profiled load started and when it finished. You

will use this information later.

The Automatic Workload Repository has a reporting script that can be used to

find snapshots that are present in the system.

As system user, enter:

@?/rdbms/admin/awrrpt

Each performance statistics snapshot assigned an ID and it is mapped to the time

the snapshot was taken. Using the times that the profiled load started and finished,

look through the generated report and identify the ID of the snapshot that precedes

the profiled load time and the ID of the snapshot that follows the profiled load

time. The range of snapshot IDs between beginning and ending snapshots denotes

a baseline. You will use this ID information when you create, backup, or restore

baselines and during troubleshooting.


Create a baseline by entering the following:


exec dbms_workload_repository.create_baseline( -

start_snap_id => <beginning snapshot id>, -

end_snap_id => <ending snapshot id>, -

base_line_name => '<name of the baseline>');

When you have finished establishing baselines or diagnosing issues, you can reset

snapshot and statistics level back to their defaults. Increased detail level of

snapshots and statistics can adversely affect performance.

Enter:


alter system set statistics_level= typical;

Preserving, Purging, and Managing Performance Statistics Snapshots

You should always keep a range of recent database performance snapshots

available in your database. Historical snapshots are necessary for many purposes.

One of them is tracking down time when any specific issue began. Even though

some problems might not be visible for time being, in most cases they will change

performance profile which is captured in the database performance statistics

snapshots. Keep and back up snapshots constituting the performance baselines.

Preserved database performance statistics snapshots are valuable for further

reference or postmortem diagnosis.

The back up of Automatic Workload Repository snapshots can be done under

guidance of PTC Technical Support or Oracle Technical Support.

Manual purging of snapshots in Oracle 10g is not required. All snapshots that are

older then two weeks and are not part of any baseline or a preserved set are

deleted automatically. This period can be configured using

DBMS_WORKLOAD_REPOSITORY API. For more information on

configuring Automatic Workload Repository defaults in Oracle 10g, see the

Oracle 10g Database Performance Tuning Guide and Reference.

Deleted performance statistics snapshots can be restored from backup copies. To

restore snapshots, contact PTC Technical Support or Oracle Technical Support.

Generating Reports and Analyzing Database Performance Statistics

To analyze database performance and diagnose problems, you first need to

generate reports from captured Automatic Workload Repository snapshots.

Reporting functionality requires at least two snapshots to be captured. One of the

simplest forms of diagnosis is to compare reports generated from analyzed

snapshots to the corresponding baseline reports.

Generate reports using following script:


@?/rdbms/admin/awrrpt


Provide the starting and ending snapshot IDs and the report name. Additionally,

the reports can be generated in the HTML format.

Reports consist of multiple sub-categories that describe different aspects of

database performance, but are tightly connected to each other. The basic aspects

and corresponding areas of reports are "load profile", "top wait events", and "top

SQL statements".

When comparing reports, pay attention to ratios in "load profile"; a changed load

profile of the database can indicate significant change in database usage. For

example, there could be an increased in the number of online users or the

application could have been reconfigured. Changes in the "top wait event" list can

indicate inefficient SQL optimization or concurrency issues. New or promoted

SQL statements in the "top SQL statement" list can indicate inefficient SQL

optimization of new or old SQL statements. To properly identify a performance

issue, all sub-categories should be carefully analyzed.

For more information about advanced methods of analysis and tuning SQL

queries, see the Oracle Database Performance Tuning Guide and Reference.

Tuning Oracle for Customized Windchill Applications

When your site has customized the code in a Windchill solution, you may need to

tune the performance of your system. When tuning the performance of an Oracle

system there are two fundamental things to consider:

• The first is the SQL code being run against the database. If this code is

inefficient, poorly indexed or accesses large amounts of data, the database

performance may suffer.

• The other main area is the database internal memory and processes. Generally

the memory areas and processes result in performance degradation as the

result of small memory areas and interference between internal processes,

both of which are usually the result of database requests (SQL) to perform

more work than the machine/Oracle setup will allow.

Before starting to tune Oracle, characterize the CPU usage on the server machine.

There are two possibilities:

• If poor performance accompanied by moderate to high CPU consumption, it

is likely the SQL being run against the database is inefficient and should be

changed. See the Identifying and Tuning SQL Statements section below.

• If poor performance accompanied by low to moderate CPU consumption,

there are three possibilities:

– There is internal database contention.

– Some memory areas are too small.

– There is not enough server utilization to generate high CPU usage.


Identifying and Tuning SQL Statements

Automatic Workload Repository reports contain top SQL queries in four

categories:

Buffer Gets

Disk Reads

Executions

Parses

For most cost effective tuning, concentrate on SQL statements that take

significant resources. Usually, these SQL statements will appear in at least two or

three of the categories.

By looking at the reports, find the hash value of subject query on the right and use

this value to fetch the full query text and execution plan for chosen SQL statement

by running the following script:


@?/rdbms/admin/awrsqrpt

Provide snapshot IDs from the main report. Additionally provide hash value of the

SQL statement.

Determining if the Columns in the Where Clause are Indexed

Determine if all of the columns used in each of the Where clauses from the SQL

statements returned from above have indexes defined for them. The following

query prompts for the table and column names and will return indexes defined for

the entered criteria.

col TABLE_OWNER for a10

col TABLE_NAME for a25

col COLUMN_NAME for a25

set linesize 150

select

a.INDEX_NAME,a.TABLE_OWNER,a.TABLE_NAME,a.COLUMN_NAME,a.COLUMN_POS

ITION, b.UNIQUENESS

from dba_ind_columns a, dba_indexes b where a.index_name in (

select index_name from dba_ind_columns where column_name =

upper('&enter_column_name') and

table_name = upper('&enter_table_name') ) and

a.index_name = b.index_name

order by column_position;


The following code may be used to create indexes:

Non-unique single column:

create index owner.index_name on owner.table_name (column)

tablespace index_tablespace_name;

Non-unique multiple column:

create index owner.index_name on owner.table_name (column1,

column2, column3 etc..) tablespace index_tablespace_name;

Unique single column:

create unique index owner.index_name on owner.table_name (column)

tablespace index_tablespace_name;

Unique multiple column:

create unique index owner.index_name on owner.table_name (column1,

column2, column3 etc..) tablespace index_tablespace_name;

See the Oracle documentation for more information about creating indexes.

Oracle Tools to Collect Database Performance Statistics

Effective data collection and analysis is essential for identifying and collecting

system performance problems.

The ADDM (Automatic Database Diagnostic Monitor) automatically gathers and

performs analysis of the database performance. It also has many advisors build in

that you can take advantage of when tuning the Oracle database. For more

information, see the Oracle Database Performance Tuning Guide and Oracle

Enterprise Manager Install and Configure Guide.

Reporting Performance Problems to PTC

If a performance issue requires the attention of PTC Technical Support, perform

following steps and supply the results when you make the contact:

• Exercise the degraded operation several times to magnify the symptom or

perform regular activities for at least a day if the source of a problem is not

clear.

• Provide an Automatic Database Diagnostic Monitor report. See Generating

Reports and Analyzing Database Performance Statistics.

• Upon a request from PTC Technical Support, provide additional Automatic

Database Diagnostic Monitor reports (see Generating Reports and Analyzing

Database Performance Statistics) and a full export.

For information about contacting PTC Technical Support, see Technical Support.

For details on how to generate the required data, see Gathering and Maintaining

System Performance and Data Distribution Statistics, Oracle Database

Performance Baselines, and Oracle Tools to Collect Database Performance

Statistics.



BSQL Server Tuning Guidelines

This appendix provides information about SQL Server tuning guidelines.

Topic Page

SQL Server Recommendations .......................................................................... B-2

B-1

SQL Server Recommendations

As a result of testing Windchill with the SQL Server, PTC has compiled a set of

recommendations.

The recommendations can be categorized as follows:

• General

• Data loading

General Recommendations

Before using Windchill on an SQL Server database, consider the taking following

actions:

• Check the location of the temporary database (tempdb). SQL Server performs

better if tempdb is located on it’s own logical disk. If tempdb is on the same

disk as the system table spaces, move it to its own logical disk.

• Add at least three additional files to tempdb; each file should be about 400

megabytes. SQL Server performs better when it is able to spread I/O across

multiple files.

• When creating the Windchill database, spread the Windchill tables across

multiple files.

Data Loading Recommendations

Before doing any bulk data loading, consider doing the following:

• Increase the size of the Windchill database to accommodate the data. This

prevents the database from auto growing during the bulk loading process.

• Force statistics generation during the loading of data even when automatic

statistics generation is enabled. From SQL Server Manager Console, select

the appropriate database and execute the following commands:

use <dbname>;

go;

exec sp_updatestats 'resample';

• Limit the maximum amount of memory that SQL Server has available to it.

If Windchill and SQL Server are installed on the same database, limit SQL

Server to 1 gigabyte on a 4 gigabyte system. Limit SQL Server to 2-3

gigabytes of memory on 8 gigabyte system.

B-2 Windchill Performance Tuning Guide

• If loading instance-based attributes (IBAs), turn off row and page lock on the

following tables:

– BooleanValue

– FloatValue

– IntegerValue

– RatioValue

– ReferenceValue

– StringValue

– TimestampValue

– UnitValue

– URLValue

This can be done from the SQL Server Manager Console or using the sqlcmd line

option.

SQL Server Tuning Guidelines B-3

B-4 Windchill Performance Tuning Guide

COperating System Tuning

Properly tuning the operating system to deliver the best performance can have an

influence on how well Windchill performs. Operating system monitoring tools

should be used to help determine bottlenecks.

This appendix covers tuning tips for HP-UX , Solaris, and Windows.

Topic Page

HP-UX Tuning ................................................................................................... C-2

Solaris Tuning .................................................................................................... C-7

Windows Tuning ................................................................................................ C-8

C-1

HP-UX Tuning

The following sections describe various tuning options on an HP-UX platform.

Tuning the HP-UX Kernel

The HP-UX kernel should be configured to support the numerous processes and

threads that will execute simultaneously when running Windchill. The

/usr/sbin/sam tool is used to alter the machine and kernel configuration. The

kernel configuration suggested below is intended to support running Windchill,

HP-UX JVM 1.4, Oracle, and the Web server from one server. This kernel

configuration is intended to support hundreds of concurrent Windchill clients.

1. Select SAM > kernel-configuration > configurable-parameters.

2. Choose Actions from menu bar.

3. Select Apply tuned parameter set.

4. Select General OLTP/Database Monolithic System and check the settings

described in the following section:

Kernel Parameters

maxdsiz: address space for 32-bit applications (data space). Recommendation:

from 1 to 2.9GB depending on RAM installed on system.

For HP-UX 11.23 we recommend 4.0GB for MPAS (Mostly Private Address

Space).

maxdsiz_64bit: address space for 64-bit applications (data space).

Recommendation: 32GB or bigger (depending on the amount of RAM)

maxssiz: address space for 32-bit applications (stack space). Recommendation:

80MB

maxssiz_64bit: address space for 64-bit applications (stack space).

Recommendation: up to several hundred MB if needed.

shmmax: global shared memory space. For 64-bit Oracle set to 1 + 4*n GB where

n=1,2,3... The 1 GB is necessary for 32-bit applications. If shmmax is a multiple

of 4, 32-bit applications will see a shmmax of 0! Preferably, you want to have the

Oracle SGA to fit in one shared memory segment. You definitely want fewer than

6 shared memory segments on the system for performance reasons. Check with

the ipcs command. A 5GB value will be sufficient for an SGA of up to 4GB for

64-bit Oracle. NOTE: Always set shmmax lower than the actual amount of RAM

in the system!

shmseg: the maximum number of shared memory segments. Recommendation:

least 32x number of Oracle databases on the system

swapmem_on: enables utilization of memory without allocating swapspace.

Default=1. We recommend leaving it on. This avoids wasted file storage.

C-2 Windchill Performance Tuning Guide

swchunk: size of one ‘swap chunk’. Default=2048 (=2MB). Increase only if you

need more than 32GB of swap.

maxswapchunks: maximum number of ‘swap chunks’ in the kernel.

Max. swap space = swchunk * 1024 * maxswapchunks

Make sure that the maximum is at least equal to 25% of the size of physical

memory (RAM). Use the swapinfo command or glance to determine this.

dbc_min_pct and dbc_max_pct: sets the minimum and maximum percentage of

RAM reserved for the dynamic buffer cache. Should not have more than 200-

500MB.

nbuf and bufpages: set these to 0 and use dbc_min_pct and dbc_max_pct instead.

maxfiles: the soft limit for number of open files per process. Recommendation:

2048.

maxfiles_lim: the hard limit for number of open files per process.

Recommendation: 2048.

nfile: sets the maximum number of open files for the whole system.

Recommendation: 32K.

ninode: defines the maximum number of open inodes that can be in memory at

any given time. Only the boot partition /stand should use HFS. All of the other

filesystems should use VxFS. So set to 100.

vx_ncsize: the VxFS inode cache size 8000.

vps_ceiling: determines the maximum virtual page size assigned to a process by

the operating system. Set to 64 (KB).

vps_pagesize: set to 4(K).

vps_chatr_ceiling: sets the maximum virtual page size to be assigned by the

‘chatr’ program 1048576 (KB).

maxuprc: the maximum number of processes per user. Set it to 2K.

max_thread_proc: determines the maximum number of threads per process.

2048 should be OK.

nkthread: limits the number of threads allowed to run simultaneously. Should be

at least 8K for each for application server and database server (16K if monolithic).

nproc: controls the maximum number of processes for the whole system. Should

be half of nkthread.

TCP/IP Parameters

The parameters contained in the following file configure the TCP/IP networking

kernel:

/etc/rc.config.d/nddconf

Operating System Tuning C-3

Placing this file in /etc/rc.config.d causes the parameters to be set on reboot. To

set them immediately, you can use “ndd –c” as root to read the nddconf file and

set the parameters. They will be lost after reboot if file is not updated.

# nddconf: network tunable parameters for Streams TCP/IP

TRANSPORT_NAME[0]=tcp

NDD_NAME[0]=tcp_keepalive_interval

NDD_VALUE[0]=900000

TRANSPORT_NAME[1]=ip

NDD_NAME[1]=ip_forwarding

NDD_VALUE[1]=0

tcp_keepalive_interval: determines the amount of time that TCP waits for an idle

connection with no unacknowledged data before sending keepalive packets.

Default is 7200000, we recommend 900000 milliseconds.

ip_forwarding: should be disabled for security reasons. (set to 0). Unless you

need your machine to be a router.

VxFS Tuning

In Windchill there are two primary types of data stores:

Database: characterized by a random access pattern.

• Use 8K I/O block sizes, set in /etc/vx/tunefs (see below).

• Set buffercache to be ~5% of memory.

Content vault: (or file store depending on the application): characterized by a

sequential access pattern.

• Use 64K I/O block sizes, set in /etc/vx/tunefs (see below).

• Set buffercache to be _ 1GB

• Use an 8KB file system block size for both types.

• Set with SAM or newfs –b 8192 … (default is 1KB).

• Striping: We recommend striping with 64K or 256K

• Use lvcreate (or SAM).

Additionally, a small buffer cache (_1GB) is beneficial for write operations.

Oracle recommends no buffer cache since they buffer the I/O. This is correct for

read-bound loads. However, for write operations, the small buffer cache is very

helpful.


Example Settings

For random access 8KB blocks (Oracle database), set the following:

read_pref_io=8192

read_nstream=<approx. number of disks>

read_unit_io=8192

write_pref_io=8192

write_nstream=<approx. number of disks>

write_unit_io=8192

pref_strength=10

buf_breakup_size=131072

discovered_direct_iosz=4194304

max_direct_iosz=1048576

default_indir_size=8192

qio_cache_enable=0

max_diskq=1048576

initial_extent_size=8

max_seqio_extent_size=2048

max_buf_data_size=8192

For sequential access 64KB blocks (Content Vault/File Store), set the following:

read_pref_io=65536

read_nstream=<approx. number of disks>

read_unit_io=65536

write_pref_io=65536

write_nstream=<approx. number of disks>

write_unit_io=65536

pref_strength=30

buf_breakup_size=131072

discovered_direct_iosz=4194304

max_direct_iosz=1048576

default_indir_size=8192

qio_cache_enable=0

max_diskq=1048576

initial_extent_size=8


max_seqio_extent_size=2048

max_buf_data_size=65536

Note: You have to modify the setting to match the logical volume your file

system resides on.

Notes and Commands Used to Tune

Use the following information when tuning:

• Repeat for each file system.

• To set the parameters on the fly:

vxtunefs -s

• To print the parameters:

vxtunefs -p [filesystem mount point]

• Your average IO size reported by the storage subsystem (XP, EMC) and the

average IO size reported by glance should be approximately. 8K for the

random access and 64K for sequential.

• Create a new kernel and reboot the system.

Configuring Oracle Data Files with Raw Logical Volumes

The performance of the Oracle database, in particular the BLOB tablespace, can

be enhanced with the use of raw logical volumes and asynchronous I/O.

For example, use the following steps to create raw logical volumes:

1. Add the asyncdsk device to the kernel and reboot.

2. Create logical volumes using System tool SAM with 10% more storage than

planned for tablespaces.

3. Change owner/group to $ORACLE_USER:dba for all raw logical volumes.

4. Create links from the raw volume logical to the dbf files like:

ln –s /dev/vgdb/rlvusers /oracle/dbs/users.dbf

5. Bring up Oracle.

6. Verify that your database is in async mode. For example, use Glance to verify

that the /dev/async file is open by the ora_dbw0_[$ORACLE_SID] process.


Solaris Tuning

The following sections describe various tuning options on a Solaris platform.

Tuning the Solaris Kernel

The Solaris kernel should be configured to support the numerous processes and

threads that will execute simultaneously when running Windchill. The file

/etc/system is used to define the kernel configuration. The kernel configuration

suggested below is intended to support running Windchill, Solaris 2.8, 2.9 JVM,

Oracle, and Web server from one server. This kernel configuration is intended to

support hundreds of concurrent Windchill clients. These settings are meant for the

server configuration only.

/etc/system:

Set shmsys:shminfo_shmmax=0xffffffff

Set semsys:seminfo_semmns=600

Set symsys:seminfo_semmsl=200

Set rlim_fd_max=4096

Set rlim_fd_cur=1024

Set tcp:tcp_conn_hash_size=65536

Set fastscan=131072

Set maxpgio=65536

Further information on Java tuning is available at the Sun Web site:

http://java.sun.com/.

Configuring Oracle Data Files With Directio Filesystem

The performance of the Oracle database, in particular the BLOB tablespace, can

be enhanced with the use of either raw disk devices or filesystems with directio

enabled. However, raw disk access can be administratively inconvenient. One

alternative is to use a volume management tool such as Veritas to label and keep

track of raw disk space.

UFS directio is a feature added to Solaris 2.6 to provide unbuffered access to a file

in a normal file system. Significant performance improvements have been

measured when placing the BLOB datafiles on filesystems mounted in directio

mode.

For more information on directio, see the man page for mount_ufs.

Further performance improvements may be gained by creating a striped

filesystem for the BLOB data files.


Windows Tuning

The following sections describe various tuning options on a Windows platform.

Windows System Tuning

Use the following steps to tune a Windows system:

1. Install Windows on its own partition. Be sure to format the partition with the

NTFS file system. This should be a separate partition from your application

and data partitions

2. Set the Application Response to Optimize Performance for Applications on

the server. Do this by right-clicking the My Computer icon on the desktop and

selecting Properties. Then select the Advanced tab and click the Performance

Options button.

3. Set the File and Printer Sharing for Microsoft Networks to optimize

performance for applications. Do this by right-clicking My Network Places on

the desktop then right-clicking a network connection. Select File and Printer

Sharing for Microsoft Networks then click the Property button.

4. Set network adapter tuning (tuning may vary depending on the adapter and

driver you use).

5. If the server uses a RAID:

Put the RAID controller in the fastest bus slot available, ideally a bus without

network adapters or other controllers that generate many interrupts.

a. Set cache memory: as large as possible.

b. Set cache write policy: write back.

c. Set cache read policy: read ahead.

d. Set stripe size: 8 KB/16 KB for RAID 5 and 64 KB/128 KB or the

maximum supported for RAID 0; the optimal size may vary by controller.

NTFS Tuning

Consider the following when doing NTFS tuning:

• Use multiple logical NTFS partitions. This can be set up using the RAID

configuration software or logical disk manager in Windows.

• Use 16 KB allocation size for formatting the NTFS volumes (format <drive>:

/fs:ntfs /A:16K).

• Increase the NTFS log file size to 64 MB for large volumes (chkdsk

/L:65536). By default, this value is set dynamically based on the size of the

volume.


• If using separate SCSI disks, format them with an NTFS file system with a 16

KB allocation size and Increase the NTFS log file size to 64 MB for large

volumes (chkdsk /L:65536).

Application Server Disk I/O Tuning

If the Windchill server has any NFS mounted directories check the disk

performance of the host serving the mounted file systems. Mounted file vaults are

common in clustered Windchill environments.

Ensure that network bandwidth between the NFS server and the cluster is

sufficient. A 10MB Ethernet will be overloaded easily in such an environment.

Ideally, use a dedicated gigabit connection.

Migrating Data to a Single Vault

When performing a data migration with a large number of files that are migrated

to a single Windchill vault on a Windows server, the performance of the

FileTransfer loader may degrade as the number of files increases. This is a result

of Windows creating an "8.3" compliant file name for each file loaded in the

vault.

Since the vault file names are 14 characters long and start with a series of zeros,

the time it takes for Windows to formulate a unique "8.3" file name lengthens

considerably as it processes a large number of files, eventually taking several

seconds per file.

To improve the performance of the loading process, disable the creation of "8.3"

compliant file names. There is a utility in Windows 2003 called "fsutil" that can

be used to disable this behavior. The command line is as follows:

fsutil behavior set disable8dot3 1

You must reboot your system for this change to take effect.

Caution: This is a global change that affects every volume on the server. Before

making this change, ensure that no legacy applications that require 8.3 file names

will be accessing files on this server.

Network Adapter Tuning

Use the following steps to tune the network adapter:

1. Set network adapter receive buffers for optimal performance (see adapter’s

documentation).

2. Balance client I/O among network adapters.

3. Enable TCP checksum offloading support if network adapters support it.



DWorkflow Queue Tuning

This appendix has information about queue tuning for workflow tasks.

Topic Page

Queue Pooling ....................................................................................................D-2

Dedicated Queues...............................................................................................D-3

Combining Queue Pooling and Dedicated Queues ............................................D-5

D-1

Queue Pooling

There are two Windchill queues that are used primarily for processing workflow

tasks:

• WfUserWorkQueue for processing tasks related to workflow robots

• WfPropagationQueue for processing tasks related to workflow propagation

Both the queues are FIFO queues, and they each have a single thread processing

the jobs in the queue. This means that a single long running workflow task can

block either queue.

Queue pooling sets up a pool of WfUserWorkQueue and WfPropagationQueue

queues. The pools for these queues can be set through the following properties in

wt.properties. The default value for these properties is 1.

wt.workflow.engine.userWorkPoolSize

wt.workflow.engine.propagationPoolSize

Note: The total number of process queues (WfUserWorkQueue and

WfPropagationQueue are process queues) that Windchill has, should not exceed

the hard value defined in the following property:

wt.queue.max.processQueues

If this queue limit is reached, any process that tries to create a new queue will

throw an exception and fail to start. Adhering to this hard limit is very important.

The default value for wt.queue.max.processQueues is 18 but may be overridden in

wt.properties.

The WfPropagationQueue queues in the pool are named

WfSharedPropagationQueue<n> and WfUserWorkQueue queues in the pool are

named WfSharedUserQueue<n>, where <n> starts at 1 and increments by 1 for

each additional queue.

Once the queue pools are defined, tasks are put into these queues in a circular

manner, starting with the first and continuing through the queue and then starting

over with the first again. Since each queue has a thread associated with it, a single

long running workflow process will block only its own queue while allowing the

processing to continue in other process queues in the corresponding pool.

Note: The capacity of the server on which Windchill is running should also be

kept in mind while configuring these queue pools. If the server is bogged down

and cannot handle more threads, adding more queues will not result in any

performance improvement.

D-2 Windchill Performance Tuning Guide

Dedicated Queues

Although queue pooling should be used in lieu of dedicated queues were possible,

Windchill supports dedicated queues when they are needed.

Dedicated queues are queues that are tied to specific workflow templates. This

might be helpful in scenarios where particular workflow templates are being used

heavily or are using complex functionality resulting in generation of long running

queue entries.

In order to enforce dedicated queue processing on specific workflow templates,

first you have to enable dedicated queues in wt.properties and then set “has

dedicated queue” flag to true in the corresponding workflow template.

Enabling Dedicated Queues

Enable dedicated queue processing in wt.properties by setting the

wt.workflow.engine.dedicatedQueueMode property value as appropriate.

The following are possible values for this property:

none (default) – dedicated queue processing disabled

userWork – a dedicated WfUserWorkQueue for the workflow templates that have

the dedicated queue processing flag enabled

propagation – a dedicated WfPropagationQueue for workflow templates that have

the dedicated queue processing flag enabled

all – a dedicated WfUserWorkQueue and a dedicated WfPropagationQueue for

workflow templates that have the dedicated queue processing flag enabled

Note: After setting this property in wt.properties, method servers should be

restarted for this property to take effect.

Workflow Queue Tuning D-3

Setting “has dedicated queue” Flag to True

In order to set the ‘has dedicated queue’ flag for a specific process, check out the

workflow template, select the ‘Set dedicated queue’ checkbox in the template’s

Properties tab. Finally check in the template.

Setting Dedicated Queue Processing for all Newly Created Workflow Templates

If it is expected that every workflow process will require its own queue, then set

the following wt.properties property value to true.

wt.workflow.engine.dedicatedQueue=true

Note: All workflow templates that are created after this property has been set to

true will have “Has Dedicated Queue” flag set to true. Setting this property to true

will not retroactively set the “Has Dedicated Queue” flag to true for all the

workflow template that were already in existence.

Setting Dedicated Queue Processing per Workflow Process Initiated From a

Particular Workflow Template

Instead of forcing all the processes of a particular template to use the same

dedicated queue, it is possible to configure Windchill to spawn a new queue for

every instance of a process initiated from a template that has the “Has Dedicated

Queue” flag set to true. All the new queues that are initiated are process queues. In

order to achieve this, set the following property in wt.property file to true.


wt.workflow.engine.dedicatedQueuePerProcess=true

Note: This property is set globally; there is no way to set this property on a per

template basis. Therefore special attention has to be paid to the hard limit on

process queues; as was previously stated, once this limit is reached, any new

processes will throw an exception and fail to start. Given that the number of

workflow processes can change on the fly, special caution must be exercised in

use of this property.

Combining Queue Pooling and Dedicated Queues

If needed, a combination of queue pooling and dedicated queues could be used.

The following example illustrates this. Refer to the Windchill System

Administrator’s Guide for more information on finding the status of background

method server queues.

1. Increase the maximum number of queues in wt.properties:

wt.queue.max.processQueues=50

2. Set the wt.properties required to enable queue pooling:

wt.workflow.engine.userWorkPoolSize=10

wt.workflow.engine.propagationPoolSize=10

After this change, workflow processes will push jobs into WfUserWorkQueue or

WfPropagationQueue in a circular manner, starting with the first and continuing

through the queue and then starting over with the first again. Since each queue has

its own thread for processing its jobs, this change would create parallel processing

of workflow tasks.

3. Set the wt.properties value required to enable dedicated queues for both

WfUserWorkQueue and WfPropagationQueue queues:

wt.workflow.engine.dedicatedQueueMode=both

Workflow Queue Tuning D-5


Index

A

Aphelion diagnostics, 3-33

Application server disk tuning, C-9

Application tuning

Apache 2.0 Web servers, 4-4

background method server, 4-28

HTML browser, 4-2

Java, 4-2

Servlet Engines, 4-5

Windchill method server, 4-12

Windchill servlet, 4-7

B

Background method servers, 4-28

Browser cache, 4-2

C

Client-side diagnostic logging

desktop integration clients, 2-7

Java clients, 2-2

Web browsers, 2-1, 2-2

Client-side RMI call logging, 2-3

com.ptc.core.ca.web.client.gw.sessionTime, 4-10

Cost Based Optimizer, A-7

CPU analysis

CPU bottlenecks, 7-7

CPU resource profiles, 7-5

CPU statistics, 7-2

generating thread dumps, 7-6

Windchill processes, 7-2


D

db.properties

wt.pom.cachedStatementReuseLimit, 4-22

wt.pom.cardinalityValueFixedSize, 4-25

wt.pom.chunk.defaultSize, 4-24

wt.pom.dbConnectionPropertiesNameList, 4-25

wt.pom.dbConnectionPropertiesValueList, 4-25

wt.pom.inClauseBindOptimizationCardinality,

4-24

wt.pom.inClauseUseBindOptimization, 4-24

wt.pom.maxDbConnections, 4-23

wt.pom.maxIdleStatementCaches, 4-23

wt.pom.paging.snapshotQueryLimit, 4-26

wt.pom.queryLimit, 4-25

wt.pom.refreshCache.size, 4-24

wt.pom.statementCacheSize, 4-22

wt.query.singleWildCard, 4-26

DB_CACHE_SIZE, A-3

Detecting

disk bottlenecks, 7-10

memory bottlenecks, 7-8

network bottlenecks, 7-13

Disk bottlenecks, 7-10

G

Garbage collection tuning, 5-2

glance, 6-10, 7-5

H

How to fix





Index-1

HP-UX

configuring kernel, C-2


garbage collection, 5-3, 5-4

glance, 6-10



process CPU time, 7-5

statistic snapshots, 7-8

tcpdump, 7-13

thread dumps, 7-7

tuning, C-2

HTML generation

JSP with Info*Engine RPC model acquisition, 1-10

JSP with RMI acquisition, 1-8

Windchill template processor, 1-9

I

IE SAK (Info*Engine Service Access Kit), 1-3

Info*Engine Simple Task Dispatcher, 1-3

Info*Engine SOAP model acquisition, 1-11

J

Java applet, 2-2

Java application

direct RMI model acquisition, 1-12

tunneled RMI model acquisition, 1-13

Java clients, 2-2

Java garbage collector tuning

balancing system memory, 5-9

garbage collection, 5-2

managing system memory, 5-8

Java tuning properties

wt.rmi.clientSocketFactory, 4-2

wt.rmi.socketReceiveBufferSize, 4-2

wt.rmi.socketSendBufferSize, 4-2

JAVA_POOL_SIZE, A-4

K

Kernel parameters

bufpages, C-3

dbc_min_pct and dbc_max_pct, C-3

ip_forwarding, C-4

max_thread_proc, C-3

maxdsiz, C-2

maxdsiz_64bit, C-2

maxfiles, C-3

maxfiles_lim, C-3

maxssiz, C-2

maxssiz_64bit, C-2

maxswapchunks, C-3

maxuprc, C-3

nbuf, C-3

nfile, C-3

ninode, C-3

nkthread, C-3

nproc, C-3

shmmax, C-2

shmseg, C-2

swapmem_on, C-2

swchunk, C-3

tcp_keepalive_interval, C-4

vps_ceiling, C-3

vps_chatr_ceiling, C-3

vps_pagesize, C-3

vx_ncsize, C-3

L

LARGE_POOL_SIZE, A-4

LOG_BUFFER, A-4

M

Memory analysis

memory bottlenecks, 7-8, 7-9

memory statistics, 7-8

N

netstat, 7-14

Network adapter tuning, C-9

Network analysis


network traffic, 7-12

resolving domain names, 7-16

Network bottlenecks, 7-13

NTFS tuning, C-8

Index-2 Windchill Performance Tuning Guide

O

Object reference, 3-31

Object reference cache

wt.admin.AdminDomainRef, 3-30

wt.admin.AdministrativeDomain, 3-29

wt.content.DataFormatReference, 3-31

wt.epm.EPMAuthAppVersionRef, 3-31

wt.Folder.Cabinet, 3-29

wt.folder.CabinetReference, 3-31

wt.Folder.SubFolder, 3-29

wt.folder.SubFolderReference, 3-31

wt.inf.container.WTContainer, 3-29

wt.inf.container.WTContainerRef, 3-30

wt.inf.container.WTContainerTemplateRef, 3-30

wt.inf.team.ContainerTeam, 3-29

wt.inf.team.ContainerTeamReference, 3-30

wt.inf.template.WTContainerTemplateMasterRef-

erence, 3-30

wt.lifecycle.LifeCycleTemplateMasterReference,

3-30

wt.lifecycle.LifeCycleTemplateReference, 3-30

wt.project.ProjectReference, 3-30

wt.team.TeamDistributionListReference, 3-30

wt.team.TeamTemplateReference, 3-30

wt.vc.views.ViewReference, 3-31

wt.workflow.definer.WfContainerTemplateRefer-

ence, 3-31

wt.workflow.definer.WfNodeTemplateReference,

3-31

wt.workflow.definer.WfProcessTemplateMaster-

Reference, 3-31

wt.workflow.engine.WfContainerReference, 3-31

wt.workflow.engine.WfProcess, 3-29

Operating system

HP-UX tuning, C-2

Solaris tuning, C-7

VxFS tuning, C-4

Windows tuning, C-8

Oracle

Collecting database statistics, A-13

configuring with directio filesystems, C-7

configuring with raw logical volumes, C-6

Database performance, A-2

Database performance baselines, A-8

diagnostics, 3-31

directio filesystems, C-7

Improving database performance, A-2

Memory size, A-2

raw logical volumes, C-6

Snapshots, A-10

Tools for database statistics, A-13

Tuning customized applications, A-11

tuning scripts, B-1

Tuning SQL statements, A-12

P

Performance checklist, 6-2

PGA_AGGREGATE_TARGET, A-4

Pro/ENGINEER Wildfire

dm_cache_size, 2-7

dm_http_compression_level, 2-7

dm_network_request_size, 2-7

dm_network_threads, 2-7

Q

Queue pooling

wt.queue.max.processQueues, D-2

wt.workflow.engine.propagationPoolSize, D-2

wt.workflow.engine.userWorkPoolSize, D-2

Queue pooling and dedicated queues

wt.queue.max.processQueues, D-5

wt.workflow.engine.dedicatedQueueMode, D-5

wt.workflow.engine.propagationPoolSize, D-5

wt.workflow.engine.userWorkPoolSize, D-5

R

Remote Method Invocation. See RMI

RMI, 1-3, 1-8, 1-9, 1-10, 1-11, 1-12, 1-13

S

Server-side diagnostic logging

Aphelion, 3-33

Oracle, 3-31

servlet engine diagnostics, 3-5

Web server, 3-2

Windchill application server, 3-11

Service properties

wt.admin.AdministrativeDomain, 4-21

wt.folder.Cabinet, 4-21

wt.folder.SubFolder, 4-21

wt.inf.container.WTContainer, 4-21

wt.inf.team.ContainerTeam, 4-21

wt.workflow.engine.WfProcess, 4-21

Servlet engine tuning

acceptCount, 4-6

maxSpareThreads, 4-6

maxThreads, 4-6

minSpareThreads, 4-6

Session timeout, 4-7

SGA, A-3

Index-3

SGA_MAX_SIZE, A-3

SHARED_POOL_SIZE, A-3

snoop, 7-13

SOAP (Simple Object Access Protocol), 1-3

SOAP model acquisition, 1-11

Solaris

garbage collection, 5-3, 5-4

kernel, C-7


memory statistics snapshots, 7-8

netstat, 7-14


process CPU statistics, 7-4

pstack, 6-10

snoop, 7-12, 7-13

thread dumps, 7-7

tuning, C-7

uptime, 7-6

SQL operations for large lists, 6-2

SQL statement tuning, A-12

STREAMS_POOL_SIZE, A-4

T

tcpdump, 7-13

Technical support, xii

Tomcat servlet

debug, 4-11

maxActiveSessions, 4-11

maxIdleSwap, 4-11

minIdleSwap, 4-11

Tools

Aphelion, 3-33

browser cache settings, 4-2

garbage collection, 5-1

Oracle, 3-31

Oracle database statistics, A-13

Troubleshooting

response time, 6-6

system performance, 6-8

Tuning SQL statements, A-12

Tuning

application server disk I/O, C-9

HP-UX, C-2

network adapters, C-9

NTFS, C-8

operating systems, C-1

Oracle for customized Windchill applications, A-11

Oracle scripts, B-1

Solaris, C-7

SQL statements, A-12

Tomcat 5.0, 4-5

VxFS, C-4

Windows, C-8

U

User actions, 1-4

V

VxFS tuning, C-4

W

WfPropagationQueue, D-2

WfUserWorkQueue, D-2

Windchill, 1-2, 3-26

Windchill adapter, 1-3

Windchill adapter properties

.cacheTTL, 4-27

.credentialsTimeToLive, 4-27

.properties.timeToLive, 4-27

.socketAccess.maxThreadCount, 4-26

.taskDelegateTimeToLive, 4-27

.taskProcessor.taskFileTimeToLive, 4-27

Windchill architecture, 1-2

Servlet engine, 1-2

Web server, 1-2

Windchill method server call diagnostics, 3-12

Windchill method server diagnostics, 3-27

Windchill method server tuning

db.properties, 4-12

service.properties, 4-12

wt.properties, 4-12

Windchill queue logging, 3-26

Windchill server manager diagnostics, 3-12

Windchill servlet tuning

.taskProcessor.taskFileTimeToLive, 4-9

com.infoengine.getRemoteHost, 4-8

com.infoengine.maxConnectionAge, 4-9

com.ptc.core.ca.co.common.prefs.session.cache,

4-8, 4-10

com.ptc.core.ca.web.client.element.factory.maxFr-

ameCount, 4-10

com.ptc.netmarkets.clientCacheLimit, 4-7

com.ptc.netmarkets.clientCacheTimeOut, 4-8

com.ptc.netmarkets.clientTabCacheLimit, 4-7

Windchill tuning methodology, 1-4

windump, 7-13

wt.adapter.attribute logger, 3-21

wt.adapter.exception logger, 3-21

wt.adapter.verbose logger, 3-21

wt.adapter.webject logger, 3-21

Index-4 Windchill Performance Tuning Guide

wt.cache.CacheManager.summaryInterval, 6-5

wt.cache.size.RoleAccessCache, 4-14

wt.org.WTPrincipalCache.summaryInterval=1000,

3-29

wt.pom.sql logger, 3-28

wt.pom.statementCache logger, 3-27

wt.properties

com.ptc.netmarkets. serverCacheLimit, 4-20

com.ptc.netmarkets.projmgmt.serverCacheLimit,

4-20

wt.admin.cache.maxDomains, 4-14

wt.cache.size.AclCache, 4-14

wt.cache.size.AdHocAclSpecCache, 4-17

wt.cache.size.ConfigCache, 4-16

wt.cache.size.CriterionCache, 4-17

wt.cache.size.DirectoryInfrastructureNodeCache,

4-18

wt.cache.size.FvPolicyItemCache, 4-16

wt.cache.size.IBADefinitionDBService$Default-

ViewbyPathCache, 4-16

wt.cache.size.IBAModelImplementation$DefaultI-

BATypeCach, 4-13

wt.cache.size.IndexListCache, 4-16

wt.cache.size.InitialPhaseCache, 4-17

wt.cache.size.LifeCycleTemplateCache, 4-17

wt.cache.size.LifeCycleTemplateNameCache, 4-17

wt.cache.size.NotificationListCache, 4-18

wt.cache.size.PagingSessionCache, 4-18

wt.cache.size.PhaseTemplateCache, 4-17

wt.cache.size.PrefEntryCache, 4-18

wt.cache.size.SessionCache, 4-19

wt.cache.size.StandardFvService$FvFolderCache,

4-16

wt.cache.size.StandardFvService$FvMountCache,

4-16

wt.cache.size.StandardInitRuleEvalSer-

vice$Cache, 4-19

wt.cache.size.TeamTemplateCache, 4-19

wt.cache.size.TypeBasedCompositeRuleSelec-

tor$Cache, 4-13

wt.cache.size.WfProcessTemplateCache, 4-19

wt.cache.size.WTCalendarCache, 4-14

wt.cache.size.WTPrincipalCache, 4-18

wt.folder.cache.containersToCabinetsSize, 4-15

wt.folder.cache.namesToCabinetsSize, 4-15

wt.folder.cache.namesToSubFoldersSize, 4-15

wt.folder.cache.parentsToSubFoldersSize, 4-15

wt.folder.cache.subFoldersToParentsSize, 4-15

wt.folder.cache.usersToCabinetsSize, 4-15

wt.folder.oneLevel, 4-15

wt.folder.ResultsLimit, 4-20

wt.ufid.FederatableServerHelper$Repository-

Cache, 4-19

wt.queue.execEntriesCount, 4-28

wt.workflow.engine.dedicatedQueue, D-4

wt.workflow.engine.dedicatedQueuePerProcess, D-5

X

XML generation, 1-11

Index-5