Windchill Performance Tuning Guide

Windchill Performance Tuning Guide
Windchill 9.1 Pro/INTRALINK 9.1 Arbortext 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) (OCT95) or DFARS 227.7202-1(a) and 227.7202-3(a) (JUN95), 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 (OCT88) or Commercial Computer Software-Restricted Rights at FAR 52.227 19(c)(1)-(2) (JUN87), 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
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
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
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
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. Updated the Servlet Engine Diagnostics and Windchill Application Server Diagnostics to document log4j messaging capabilities. Appendix was removed as Oracle 9i is no longer supported. Updated content to provide useful information for tuning Oracle 10g Windchill databases. Appendix was removed as the scripts are not needed for Oracle 10g.
Server-side Diagnostic Logging
Oracle 9i Tuner Oracle Tuning Guidelines
Oracle Tuning Scripts
vii
Table 2 Changes for Windchill 8.0, Maintenance Release M040

Chapter Description
Chapter 4, Application Tuning
Removed indexing information from chapter as RetrievalWare is no longer used for Windchill Index Search. Updated Performance Checklist section to include the use of the Oracle 9i Tuner and reference a new guide for indexing information. Updated Detecting Memory Bottlenecks section with new threshold information. New appendix with information on installing and using the Oracle 9i Tuner. Updated content to provide useful information for tuning Oracle 9i and 10g Windchill databases. Added Oracle 9i Tuner reference. New appendix with information on SQL Server recommendations.
Chapter 6, Performance Checklist
Chapter 7, CPU, Memory, Disk, Network Metrics Appendix A, Oracle 9i Tuner
Appendix B, Oracle Tuning Guidelines Appendix C, Oracle Tuning Scripts Appendix D, SQL Server Tuning Guidelines
Table 3 Changes for Windchill 8.0, Maintenance Release M030

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
Chapter
Description
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.
Change Record
ix
Chapter
Description
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 Appendix B, Oracle Tuning Scripts Windchill Profiler appendix Appendix C, Operating System Tuning
Added Oracle 10g information. Minor update. Moved from this guide to the Windchill Customizers Guide. Reorganized the information in the appendix. Added Using Hyper-Threading Technology section.
Appendix D, Workflow Queue Tuning
Updated queue names and property values.
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 Administrators Guide Windchill Business Administrators Guide Windchill Customizers 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
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: http://www.ptc.com/support/support.htm
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
xiv
1
Windchill 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
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.
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.
1-4
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
1-5
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.
1-6
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.
1-7
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 servers 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.
1-8
HTML Generation Using Windchill Template Processor

The following diagram shows the interaction of components that starts at an HTML browser and uses the Windchill template processor. The descriptions below correspond to the numbered interactions in the diagram.
1. HTML browser issues GET request for URL, for example: GET /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 servers 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.
1-9
HTML Generation Using JSP with Info*Engine RPC Model Acquisition

The following diagram shows the interaction of components that starts at an HTML browser and uses JSP with Info*Engine RPC model acquisition. The descriptions below correspond to the numbered interactions in the diagram.
1. HTML browser issues GET request for URL, for example: GET /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.
1-10
XML Generation Using Info*Engine SOAP Model Acquisition

The following diagram shows the interaction of components that starts at an HTML browser and uses Info*Engine SOAP model acquisition. The descriptions below correspond to the numbered interactions in the diagram.
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.
1-11
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 below correspond to the numbered interactions in the diagram.
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.
1-12
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 below correspond to the numbered interactions in the diagram.
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.
1-13
1-14
2
Client-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 clients 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.
2-2
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
2-3
2007-09-05 14:15:40,536 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;152] 2007-09-05 14:15:40,536 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;152], 0 ms 2007-09-05 14:15:40,536 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start wt.session.SessionManagerFwd.getPrincipal [f687i6tz;2672;153] 2007-09-05 14:15:40,536 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end wt.session.SessionManagerFwd.getPrincipal [f687i6tz;2672;153], 0 ms 2007-09-05 14:15:40,536 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start wt.preference.PreferenceService2Fwd.getValue [f687i6tz;2672;154] 2007-09-05 14:15:40,536 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end wt.preference.PreferenceService2Fwd.getValue [f687i6tz;2672;154], 0 ms 2007-09-05 14:15:40,536 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start wt.preference.PreferenceService2Fwd.setValue [f687i6tz;2672;155] 2007-09-05 14:15:40,551 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end wt.preference.PreferenceService2Fwd.setValue [f687i6tz;2672;155], 15 ms 2007-09-05 14:15:40,551 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start wt.preference.PreferenceService2Fwd.setValue [f687i6tz;2672;156] 2007-09-05 14:15:40,551 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end wt.preference.PreferenceService2Fwd.setValue [f687i6tz;2672;156], 0 ms 2007-09-05 14:15:40,551 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start com.ptc.core.task.TaskManagerFwd.userHasAlertTasks [f687i6tz;2672;157] 2007-09-05 14:15:40,551 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end com.ptc.core.task.TaskManagerFwd.userHasAlertTasks [f687i6tz;2672;157], 0 ms 2007-09-05 14:15:40,567 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start com.ptc.netmarkets.util.misc.NmActionServiceFwd.getAction [f687i6tz;2672;158] 2007-09-05 14:15:40,567 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end com.ptc.netmarkets.util.misc.NmActionServiceFwd.getAction [f687i6tz;2672;158], 0 ms 2007-09-05 14:15:40,567 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start com.ptc.netmarkets.util.misc.NmActionServiceFwd.getAction [f687i6tz;2672;159] 2007-09-05 14:15:40,567 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end com.ptc.netmarkets.util.misc.NmActionServiceFwd.getAction [f687i6tz;2672;159], 0 ms 2007-09-05 14:15:40,567 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;160] 2007-09-05 14:15:40,582 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;160], 15 ms 2007-09-05 14:15:40,582 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;161] 2007-09-05 14:15:40,582 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;161], 0 ms 2007-09-05 14:15:40,582 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;162] 2007-09-05 14:15:40,582 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;162], 0 ms 2007-09-05 14:15:40,582 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;163] 2007-09-05 14:15:40,598 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;163], 16 ms
2-4
2007-09-05 14:15:40,598 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start com.ptc.netmarkets.folder.NmFolderServiceFwd.getFolderDetailsObjects [f687i6tz;2672;164] 2007-09-05 14:15:40,598 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end com.ptc.netmarkets.folder.NmFolderServiceFwd.getFolderDetailsObjects [f687i6tz;2672;164], 0 ms 2007-09-05 14:15:40,598 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start com.ptc.netmarkets.folder.NmFolderServiceFwd.getFolderDetailsObjects [f687i6tz;2672;165] 2007-09-05 14:15:40,598 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end com.ptc.netmarkets.folder.NmFolderServiceFwd.getFolderDetailsObjects [f687i6tz;2672;165], 0 ms 2007-09-05 14:15:40,598 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start com.ptc.netmarkets.util.misc.NmActionServiceFwd.getAction [f687i6tz;2672;166] 2007-09-05 14:15:40,614 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end com.ptc.netmarkets.util.misc.NmActionServiceFwd.getAction [f687i6tz;2672;166], 16 ms 2007-09-05 14:15:40,614 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;167] 2007-09-05 14:15:40,614 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;167], 0 ms 2007-09-05 14:15:40,614 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start wt.fc.cache.ObjectReferenceCacheFwd.inflate [f687i6tz;2672;168] 2007-09-05 14:15:40,614 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end wt.fc.cache.ObjectReferenceCacheFwd.inflate [f687i6tz;2672;168], 0 ms 2007-09-05 14:15:40,614 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;169] 2007-09-05 14:15:40,614 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;169], 0 ms 2007-09-05 14:15:40,614 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start wt.preference.PreferenceService2Fwd.getValue [f687i6tz;2672;170] 2007-09-05 14:15:40,629 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end wt.preference.PreferenceService2Fwd.getValue [f687i6tz;2672;170], 15 ms 2007-09-05 14:15:40,629 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;171] 2007-09-05 14:15:40,629 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;171], 0 ms 2007-09-05 14:15:40,629 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start wt.preference.PreferenceService2Fwd.getValue [f687i6tz;2672;172] 2007-09-05 14:15:40,645 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end wt.preference.PreferenceService2Fwd.getValue [f687i6tz;2672;172], 16 ms 2007-09-05 14:15:40,645 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start wt.preference.PreferenceService2Fwd.getValue [f687i6tz;2672;173] 2007-09-05 14:15:40,645 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end wt.preference.PreferenceService2Fwd.getValue [f687i6tz;2672;173], 0 ms 2007-09-05 14:15:40,645 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;174] 2007-09-05 14:15:40,661 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;174], 16 ms
2-5
2007-09-05 14:15:40,661 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start com.ptc.core.components.util.InPlaceCommand$Remote.execute [f687i6tz;2672;175] 2007-09-05 14:15:40,739 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end com.ptc.core.components.util.InPlaceCommand$Remote.execute [f687i6tz;2672;175], 78 ms 2007-09-05 14:15:40,739 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start wt.preference.PreferenceService2Fwd.getValue [f687i6tz;2672;176] 2007-09-05 14:15:40,739 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end wt.preference.PreferenceService2Fwd.getValue [f687i6tz;2672;176], 0 ms 2007-09-05 14:15:40,770 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;177] 2007-09-05 14:15:40,786 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;177], 16 ms 2007-09-05 14:15:40,786 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;178] 2007-09-05 14:15:40,786 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;178], 0 ms 2007-09-05 14:15:40,786 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;179] 2007-09-05 14:15:40,801 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;179], 15 ms 2007-09-05 14:15:40,801 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;180] 2007-09-05 14:15:40,801 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;180], 0 ms 2007-09-05 14:15:40,801 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start com.ptc.netmarkets.folder.NmFolderServiceFwd.getFolderDetailsObjects [f687i6tz;2672;181] 2007-09-05 14:15:40,817 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end com.ptc.netmarkets.folder.NmFolderServiceFwd.getFolderDetailsObjects [f687i6tz;2672;181], 16 ms 2007-09-05 14:15:40,817 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;182] 2007-09-05 14:15:40,817 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;182], 0 ms 2007-09-05 14:15:40,817 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;183] 2007-09-05 14:15:40,817 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end wt.fc.cache.ObjectReferenceCacheFwd.getObject [f687i6tz;2672;183], 0 ms 2007-09-05 14:15:40,832 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start com.ptc.core.components.util.InPlaceCommand$Remote.execute [f687i6tz;2672;184] 2007-09-05 14:15:41,411 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end com.ptc.core.components.util.InPlaceCommand$Remote.execute [f687i6tz;2672;184], 579 ms 2007-09-05 14:15:41,411 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start wt.preference.PreferenceService2Fwd.getValue [f687i6tz;2672;185] 2007-09-05 14:15:41,411 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end wt.preference.PreferenceService2Fwd.getValue [f687i6tz;2672;185], 0 ms
2-6
2007-09-05 14:15:41,442 INFO [TP-Processor13] wt.method.client.timing - INVOKE: start wt.preference.PreferenceService2Fwd.getValue [f687i6tz;2672;186] 2007-09-05 14:15:41,457 INFO [TP-Processor13] wt.method.client.timing - INVOKE: end wt.preference.PreferenceService2Fwd.getValue [f687i6tz;2672;186], 15 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 Administrators 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.
2-7
2-8
3
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
3-2
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. 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. 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
frank (%u)
[10/Oct/2000:13:55:36 -0700] (%t)
3-3
Log Entry
Description
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). 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.
2326 (%b)
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
3-4
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]
3-5
Each part of this log entry is described below:

Log Entry Description
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. 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. 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. This is the date and time at which the servlet engine started to execute the client request. This is the elapsed time in milliseconds that Tomcat spent executing the request. This is the URI sent in the client request. It does not log form parameters or query pairs.
Client=132.253.8.192
User=admin
Date=Wed Apr 04 17:00:13 CDT 2007 Elapsed=14153ms
URI=/Windchill/wtcore/jsp/co m/ptc/core/ca/web/ gw/gw.jsp
3-6
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
3-7
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 Administrators Guide.
3-8
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 IE Tasks count = 4 time = 3093
The page loaded four pre saved preferences and the loading time was 48 milliseconds.
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))
3-9
Preferences Reading (preload)
Description
count = 77 time = 0 Total time = 3 Seconds
The total number of preference keys loaded was 77.
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:
Preferences Reading (preload) Description
Preferences Writing count = 1 time = 16 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. The number of preferences that were updated was 1. The total time taken to update the preference was 16 milliseconds.
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.
3-10
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 Users 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 Users 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 Administrators Guide. The following sections describe diagnostics for server manager, method server, Info*Engine, Windchill adapter administration, and Windchill queues.
3-11
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 Administrators 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.
3-12
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).
3-13
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
3-14
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
3-15
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 Administrators 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
3-16
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 Administrators 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.
3-17
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 Client Host
The timestamp generated when the call completed rounded down to the nearest whole second. 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). 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.
Time in Milliseconds
3-18
Field
Description
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. 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. The target method name comprises the fully qualified identity of the method invoked. Shows the class name of the result object returned to the caller. If the call is received from the HTTPGatewayServlet the detail field contains the PATH_INFO from the requested URL. The last field in each line is the clients authenticated user name. This can be useful when monitoring user activity patterns and capacity planning.
Active Context Count
Target Method Results Class Detail
UserName
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.
3-19
Each summary line comprised of the fields described in the following table:
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. 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 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. 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.
Calls
Average Duration
Maximum/Average Active Calls
Server-side SOAP and Info*Engine Call Logging

The following sections describe SOAP and Info*Engine logging that is available on the server.
3-20
Using the Windchill Adapter Loggers
The following Windchill adapter log4j loggers that can be used to gather information:
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. Include information about the processing of attributes on objects. Include statistics associated with the retrieval and translation of attribute values. Include stack traces associated with exceptions that are thrown during execution of Info*Engine tasks and webjects. Include detailed information about individual webject parameters and internal webject operations. 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.
wt.adapter.attribute
wt.adapter.exception
wt.adapter.webject
wt.adapter.trace.timing
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 received trusted username demo 2007-09-05 10:14:04,920 INFO [SocketThread3] wt.adapter.verbose /com/ptc/windchill/enterprise/search/search-SystemWideSearch.xml authenticated request as demo 2007-09-05 10:14:04,920 INFO [SocketThread3] wt.adapter.verbose /com/ptc/windchill/enterprise/search/search-SystemWideSearch.xml - WTAdapter - WTAdapter processing - WTAdapter setup time 0 msec
3-21
2007-09-05 10:14:04,920 INFO [SocketThread3] wt.adapter.verbose - WTAdapter invoking task /com/ptc/windchill/enterprise/search/search-SystemWideSearch.xml 2007-09-05 10:14:04,920 INFO [SocketThread3] wt.adapter.verbose - WTAdapter received trusted username demo 2007-09-05 10:14:04,920 INFO [SocketThread3] wt.adapter.verbose - WTAdapter Apply-Service processing authenticated request as demo 2007-09-05 10:14:04,920 INFO [SocketThread3] wt.adapter.verbose - WTAdapter Apply-Service setup time 0 msec 2007-09-05 10:14:04,920 INFO [SocketThread3] wt.adapter.verbose - WTAdapter 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 2007-09-05 10:14:04,920 INFO [SocketThread3] wt.adapter.verbose - WTAdapter Apply-Service complete, 0 msec 2007-09-05 10:14:04,920 INFO [SocketThread3] wt.adapter.verbose - WTAdapter Apply-Service request complete, total time 0 msec 2007-09-05 10:14:04,920 INFO [SocketThread3] wt.adapter.verbose - WTAdapter received trusted username demo 2007-09-05 10:14:04,920 INFO [SocketThread3] wt.adapter.verbose - WTAdapter Apply-Service processing authenticated request as demo 2007-09-05 10:14:04,920 INFO [SocketThread3] wt.adapter.verbose - WTAdapter Apply-Service setup time 0 msec 2007-09-05 10:14:04,920 INFO [SocketThread3] wt.adapter.verbose - WTAdapter 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 2007-09-05 10:14:04,936 INFO [SocketThread3] wt.adapter.verbose - WTAdapter Apply-Service complete, 16 msec 2007-09-05 10:14:04,936 INFO [SocketThread3] wt.adapter.verbose - WTAdapter Apply-Service request complete, total time 16 msec 2007-09-05 10:14:04,936 INFO [SocketThread3] wt.adapter.verbose - WTAdapter received trusted username demo 2007-09-05 10:14:04,936 INFO [SocketThread3] wt.adapter.verbose - WTAdapter Apply-Service processing authenticated request as demo 2007-09-05 10:14:04,936 INFO [SocketThread3] wt.adapter.verbose - WTAdapter Apply-Service setup time 0 msec 2007-09-05 10:14:04,936 INFO [SocketThread3] wt.adapter.verbose - WTAdapter invoking webject Apply-Service 2007-09-05 10:14:04,936 INFO [SocketThread3] wt.adapter.verbose - Webject delegate for logical type is com.ptc.core.adapter.server.impl.ApplyServiceWebjectDelegate 2007-09-05 10:14:04,936 INFO [SocketThread3] wt.adapter.verbose - WTAdapter Apply-Service complete, 0 msec 2007-09-05 10:14:04,936 INFO [SocketThread3] wt.adapter.verbose - WTAdapter Apply-Service request complete, total time 0 msec 2007-09-05 10:14:04,936 INFO [SocketThread3] wt.adapter.verbose - WTAdapter received trusted username demo 2007-09-05 10:14:04,936 INFO [SocketThread3] wt.adapter.verbose - WTAdapter Indexed-Search processing authenticated request as demo 2007-09-05 10:14:04,936 INFO [SocketThread3] wt.adapter.verbose - WTAdapter Indexed-Search setup time 0 msec 2007-09-05 10:14:04,936 INFO [SocketThread3] wt.adapter.verbose - WTAdapter invoking webject Indexed-Search 2007-09-05 10:14:04,936 INFO [SocketThread3] wt.adapter.verbose - Webject delegate for logical type wt.query.template.ReportTemplate is com.ptc.core.adapter.server.impl.IndexedSearchWebjectDelegate 2007-09-05 10:14:04,936 INFO [SocketThread3] wt.adapter.verbose - WTAdapter Indexed-Search complete, 0 msec
3-22
2007-09-05 10:14:04,936 INFO [SocketThread3] wt.adapter.verbose - WTAdapter Indexed-Search request complete, total time 0 msec 2007-09-05 10:14:04,936 INFO [SocketThread3] wt.adapter.verbose - WTAdapter received trusted username demo 2007-09-05 10:14:04,936 INFO [SocketThread3] wt.adapter.verbose - WTAdapter Search-Objects processing authenticated request as demo 2007-09-05 10:14:04,936 INFO [SocketThread3] wt.adapter.verbose - WTAdapter Search-Objects setup time 0 msec 2007-09-05 10:14:04,936 INFO [SocketThread3] wt.adapter.verbose - WTAdapter invoking webject Search-Objects 2007-09-05 10:14:04,936 INFO [SocketThread3] wt.adapter.verbose - Webject delegate for logical type wt.query.template.ReportTemplate is com.ptc.core.adapter.server.impl.SearchObjectsWebjectDelegate 2007-09-05 10:14:11,124 INFO [SocketThread3] wt.adapter.verbose - WTAdapter Search-Objects complete, 6188 msec 2007-09-05 10:14:11,124 INFO [SocketThread3] wt.adapter.verbose - WTAdapter Search-Objects request complete, total time 6188 msec 2007-09-05 10:14:11,140 INFO [SocketThread3] wt.adapter.verbose - WTAdapter received trusted username demo 2007-09-05 10:14:11,218 INFO [SocketThread3] wt.adapter.verbose - WTAdapter Search-Results processing authenticated request as demo 2007-09-05 10:14:11,218 INFO [SocketThread3] wt.adapter.verbose - WTAdapter Search-Results setup time 78 msec 2007-09-05 10:14:11,218 INFO [SocketThread3] wt.adapter.verbose - WTAdapter invoking webject Search-Results 2007-09-05 10:14:11,218 INFO [SocketThread3] wt.adapter.verbose - Webject delegate for logical type is com.ptc.windchill.enterprise.search.server.impl.SearchResultsWebjectDelegate 2007-09-05 10:14:11,249 INFO [SocketThread3] wt.adapter.verbose - WTAdapter Search-Results complete, 31 msec 2007-09-05 10:14:11,249 INFO [SocketThread3] wt.adapter.verbose - WTAdapter Search-Results request complete, total time 109 msec 2007-09-05 10:14:11,249 INFO [SocketThread3] wt.adapter.verbose - WTAdapter /com/ptc/windchill/enterprise/search/search-SystemWideSearch.xml complete, 6329 msec 2007-09-05 10:14:11,265 INFO [SocketThread3] wt.adapter.verbose - WTAdapter /com/ptc/windchill/enterprise/search/search-SystemWideSearch.xml request complete, total time 6345 msec 2007-09-05 10:14:11,328 INFO [SocketThread3] wt.adapter.verbose - WTAdapter Get-Model complete, 6470 msec 2007-09-05 10:14:11,328 INFO [SocketThread3] wt.adapter.verbose - WTAdapter 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).
3-23
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) 2007-09-12 15:54:40,227 INFO [SocketThread10] com.infoengine.log.info 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 2007-09-12 15:54:40,352 INFO [SocketThread10] com.infoengine.log.info 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 2007-09-12 15:54:40,352 INFO [SocketThread10] com.infoengine.log.info - Elapsed time to search directory: 0 msec 2007-09-12 15:54:40,352 INFO [SocketThread10] com.infoengine.log.info - Elapsed time to process results: 0 msec 2007-09-12 15:54:40,383 INFO [SocketThread10] com.infoengine.log.info com.infoengine.au.delegateprovider.CommandDelegateProvider.getCommandDelegateEntry( ) - commandName: <search-SystemWideSearch>, wcTypeIdentifier: <WCTYPE|wt.doc.WTDocument>, targetRepository: <jdoe.ptcnet.ptc.com>, directorySearchBaseURL: <ldap://cn=Manager:admin@jdoe.ptcnet.ptc.com/o=Application Services,o=ptc> 2007-09-12 15:54:40,383 INFO [SocketThread10] com.infoengine.log.info com.infoengine.au.delegateprovider.DirectoryBasedCmdDelegateProviderService() directorySearchBaseURL: <ldap://cn=Manager:admin@jdoe.ptcnet.ptc.com/o=Application Services,o=ptc> 2007-09-12 15:54:40,383 INFO [SocketThread10] com.infoengine.log.info getRepositoryEntry(): <ldap://cn=Manager:admin@jdoe.ptcnet.ptc.com/dc=jdoe,dc=ptcnet,dc=ptc,dc=com, o=Application Services,o=ptc??base> ... 2007-09-12 15:54:40,508 INFO [SocketThread10] com.infoengine.log.info getCommandDelegateLDAPEntry(): <ldap://cn=Manager:admin@jdoe.ptcnet.ptc.com/ptcCommandDelegateName=searchSystemWideSearch,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 2007-09-12 15:54:40,508 INFO [SocketThread10] com.infoengine.log.info 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=
3-24
Application Services,o=ptc], RuntimeName=com.ptc.ptcnet.jdoe.Windchill, ContentType=null, TTL=15, Expire=1189631380508, Now=1189630480508 2007-09-12 15:54:40,539 INFO [SocketThread10] com.infoengine.log.info - invoke compiled task /com/ptc/windchill/enterprise/search/search-SystemWideSearch.xml 2007-09-12 15:54:40,571 INFO [SocketThread10] com.infoengine.log.info - invoke compiled task /com/ptc/windchill/enterprise/search/search-getTypeContainer.xml 2007-09-12 15:54:40,586 INFO [SocketThread10] com.infoengine.log.info - invoke compiled task /com/ptc/windchill/enterprise/search/search-IndexSearch.xml 2007-09-12 15:54:40,602 INFO [SocketThread10] com.infoengine.log.info - invoke compiled task /com/ptc/windchill/enterprise/search/search-Search.xml 2007-09-12 15:54:41,180 INFO [SocketThread10] com.infoengine.log.info - invoke compiled task /com/ptc/windchill/enterprise/search/search-SearchResults.xml 2007-09-12 15:54:41,524 INFO [SocketThread10] com.infoengine.log.info SocketAccess.SocketThread.run: sending response 2007-09-12 15:54:41,649 INFO [SocketThread10] com.infoengine.log.info 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] [user: demo] 2007-09-12 15:54:40,352 INFO [SocketThread10] com.infoengine.log.stat time, webject=Map-Credentials, msec=0 2007-09-12 15:54:40,352 INFO [SocketThread10] com.infoengine.log.stat time, webject=Query-Objects, msec=0 2007-09-12 15:54:40,539 INFO [SocketThread10] com.infoengine.log.stat time, webject=Map-Credentials, msec=0 2007-09-12 15:54:40,571 INFO [SocketThread10] com.infoengine.log.stat time, webject=Map-Credentials, msec=0 2007-09-12 15:54:40,571 INFO [SocketThread10] com.infoengine.log.stat time, webject=Apply-Service, msec=0 2007-09-12 15:54:40,571 INFO [SocketThread10] com.infoengine.log.stat time, webject=Apply-Service, msec=0 2007-09-12 15:54:40,586 INFO [SocketThread10] com.infoengine.log.stat time, webject=Apply-Service, msec=15 2007-09-12 15:54:40,586 INFO [SocketThread10] com.infoengine.log.stat time, webject=Call-Task, msec=47 2007-09-12 15:54:40,586 INFO [SocketThread10] com.infoengine.log.stat time, webject=Create-Group, msec=0 2007-09-12 15:54:40,586 INFO [SocketThread10] com.infoengine.log.stat time, webject=Map-Credentials, msec=0 2007-09-12 15:54:40,586 INFO [SocketThread10] com.infoengine.log.stat time, webject=Indexed-Search, msec=0 2007-09-12 15:54:40,586 INFO [SocketThread10] com.infoengine.log.stat time, webject=Call-Task, msec=0 2007-09-12 15:54:40,602 INFO [SocketThread10] com.infoengine.log.stat time, webject=Map-Credentials, msec=0 2007-09-12 15:54:41,180 INFO [SocketThread10] com.infoengine.log.stat time, webject=Search-Objects, msec=578 2007-09-12 15:54:41,180 INFO [SocketThread10] com.infoengine.log.stat time, webject=Call-Task, msec=594
[detail: ] processing processing processing processing processing processing processing processing processing processing processing processing processing processing processing
3-25
2007-09-12 15:54:41,180 INFO [SocketThread10] com.infoengine.log.stat - processing time, webject=Map-Credentials, msec=0 2007-09-12 15:54:41,196 INFO [SocketThread10] com.infoengine.log.stat - processing time, webject=Search-Results, msec=16 2007-09-12 15:54:41,196 INFO [SocketThread10] com.infoengine.log.stat - processing time, webject=Call-Task, msec=16 2007-09-12 15:54:41,196 INFO [SocketThread10] com.infoengine.log.stat - processing time, webject=Dispatch-Tasks, msec=813 2007-09-12 15:54:41,711 INFO [RMI TCP Connection(741)-132.253.49.121] com.infoengine.log.stat - [timestamp: 2007/09/12-15:54:41.711] [client: 132.253.49.121] [duration: 0] [redirects: 0] [active: 1] [invoked: 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] 2007-09-12 15:54:41,774 INFO [RMI TCP Connection(741)-132.253.49.121] com.infoengine.log.stat - [timestamp: 2007/09/12-15:54:41.774] [client: 132.253.49.121] [duration: 0] [redirects: 0] [active: 1] [invoked: 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 users 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
3-26
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
3-27
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 Customizers 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
3-28
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">
3-29
<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
3-30
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 Oracles 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
3-31
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';
3-32
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.
3-33
3-34
4
Application 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
4-2
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 clients 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 Customizers 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.
4-4
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:
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.
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.
Application Tuning
4-5
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:
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. 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. The maximum number of unused request processing threads that will be allowed to exist until the thread pool starts stopping the unnecessary threads. 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.
320
minSpareThreads
16
maxSpareThreads
40
acceptCount
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
4-6
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 pages 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.
Application Tuning
4-7
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.
4-8
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
Application Tuning
4-9
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
4-10
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. The minimum idle time (in seconds) before a session can be passivated to satisfy the maxActiveSessions constraint. 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. 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.
minIdleSwap
maxIdleSwap
debug
Application Tuning
4-11
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 Administrators 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
4-12
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> sql> sql> sql> sql> sql> sql> sql> sql> select select select select select select select select select count(*) count(*) count(*) count(*) count(*) count(*) count(*) count(*) count(*) from from from from from from from from from TimestampDefinition IntegerDefinition RatioDefinition UnitDefinition URLDefinition ReferenceDefinition FloatDefinition StringDefinition 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). Default size is 1000. Periodic logging is controlled by the property:
com.ptc.core.rule.server.delegate.selector.TypeBasedCompositeRuleSelector$Cache. summaryInterval
Application Tuning
4-13
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
Periodic logging is controlled by the property:

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 users role assignments. The default value is 1000. PTC recommends increasing this value to 3000. Periodic logging is controlled by the property:
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
4-14
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. Default value is 100. wt.folder.cache.namesToSubFoldersSize Caches subfolders by parent folder name or cabinet name. No logging is available. Default value is 100. wt.folder.cache.parentsToSubFoldersSize Caches subfolders by parent folder object identifier. No logging is available. Default value is 100. wt.folder.cache.subFoldersToParentsSize Caches parent subFolders by child subfolder object identifier. No logging is available. Default value is 100. wt.folder.cache.usersToCabinetsSize Caches user personal cabinets by user object identifier. No logging is available. Default value is 100. 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.
Application Tuning
4-15
wt.cache.size.FvPolicyItemCache Caches FvPolicyItems by wt.admin.Selector.

Sql> select count(*) from fvpolicyitem
Default value is 100. Periodic logging is controlled by the property:

wt.fv.FvPolicyItemCache.summaryInterval
wt.cache.size.StandardFvService$FvFolderCache Caches FvFolder by ObjectIdentifier. Default value is 100. Periodic logging is controlled by the property:
wt.fv. StandardFvService$FvFolderCache.summaryInterval
wt.cache.size.StandardFvService$FvMountCache Caches FvMounts by FvFolder ObjectIdentifier. Default value is 100. Periodic logging is controlled by the property:
wt.fv.StandardFvService$FvMountCache.summaryInterval
wt.cache.size.ConfigCache Caches replica HostConfig by hostname + masterURL. Default value is 100. Periodic logging is controlled by the property:
wt.fv.replica.ConfigCache.summaryInterval
wt.cache.size.IBADefinitionDBService$DefaultViewbyPathCache Caches Attribute Hierarchies by hierarchy identifier. Default value is 100. Periodic logging is controlled by the property:
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;
4-16

wt.index.IndexListCache.summaryInterval
wt.cache.size.AdHocAclSpecCache Caches AdHocAclSpec by PhaseTemplate. Default size 100. Periodic logging is controlled by the property:
wt.lifecycle.AdHocAclSpecCache.summaryInterval
wt.cache.size.CriterionCache Caches Life Cycle Criterion by PhaseTemplate Default size 100. Periodic logging is controlled by the property:
wt.lifecycle. CriterionCache.summaryInterval
wt.cache.size.InitialPhaseCache Caches initial PhaseTemplate by LifecycleTemplate. Default size 100. Periodic logging is controlled by the property:
wt.lifecycle. InitialPhaseCache.summaryInterval
wt.cache.size.LifeCycleTemplateCache Caches Life Cycle Query Results by LifeCycleTemplateMaster. Default size 100. Periodic logging is controlled by the property:
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. Periodic logging is controlled by the property:
wt.lifecycle. PhaseTemplateCache.summaryInterval
Application Tuning
4-17
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. Default size is 100. Periodic logging is controlled by the property:
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. Periodic logging is controlled by the property:
wt.principal.cache.summaryInterval
wt.cache.size.PagingSessionCache Caches paged query results by session. Default size is 100. Periodic logging is controlled by the property:
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
4-18
wt.cache.size.StandardInitRuleEvalService$Cache Caches Rule Attribute Values by CompositeRule or PersistentRule Default size is 100. Periodic logging is controlled by the property:
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 its 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. Periodic logging is controlled by the property:
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. Default size is 100. Periodic logging is controlled by the property:
wt.ufid.FederatableServerHelper$RepositoryCache.summaryInterval
wt.cache.size.WfProcessTemplateCache Caches a query result of WfProcessTemplates by WfProcessTemplateMaster. Default size is 100.
Application Tuning
4-19
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. The default value is 15000. 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. The default value is 10. To monitor the hit/miss ratios of the plan page cache set the property:
com.ptc.netmarkets.projmgmt.serverCacheVerbose=true
4-20
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
Application Tuning
4-21
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.
4-22
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. The default value is 5. 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).
Application Tuning
4-23
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.
4-24
It is imperative that the Oracle statistics be up to date for this feature to work 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. The default value is 100. It is imperative that the Oracle statistics be up to date for this feature to work 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) ))
Application Tuning
4-25
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. The default value is 100. 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.
4-26
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.
Application Tuning
4-27
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 Users 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. The default value is 12. 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%.
4-28
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.
Application Tuning
4-29
4-30
5
Java 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 isnt 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
5-2
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:
Windows Solaris HP-UX
NewRatio NewSize SurvivorRatio
12 640K 8
2 (client JVM: 8) 2228k 32
3 1/3rd of initial heap (ms) 8
A description of other virtual machine options can be found at: http://java.sun.com/javase/technologies/hotspot/VMoptions.jsp
5-3
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: http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html 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>
5-4
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.capacity 1048576 hotspot.gc.generation.0.space.1.name "s0" hotspot.gc.generation.0.space.1.size 1441792 hotspot.gc.generation.0.space.1.used 0 hotspot.gc.generation.0.space.2.capacity 1048576 hotspot.gc.generation.0.space.2.name "s1" hotspot.gc.generation.0.space.2.size 1441792 hotspot.gc.generation.0.space.2.used 0 hotspot.gc.generation.0.spaces 3 hotspot.gc.generation.1.capacity.current 86142976 hotspot.gc.generation.1.capacity.max 119341056 hotspot.gc.generation.1.capacity.min 59703296 hotspot.gc.generation.1.name "old" hotspot.gc.generation.1.space.0.capacity 86142976 hotspot.gc.generation.1.space.0.name "old" hotspot.gc.generation.1.space.0.size 119341056 hotspot.gc.generation.1.space.0.used 50467376 hotspot.gc.generation.1.spaces 1 hotspot.gc.generation.2.capacity.current 40894464 hotspot.gc.generation.2.capacity.max 100663296 hotspot.gc.generation.2.capacity.min 33554432 hotspot.gc.generation.2.name "perm" hotspot.gc.generation.2.space.0.capacity 40894464 hotspot.gc.generation.2.space.0.name "perm" hotspot.gc.generation.2.space.0.size 100663296 hotspot.gc.generation.2.space.0.used 40752928 hotspot.gc.generation.2.spaces 1 <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.
5-5
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.
5-6
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 servers 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
5-7
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.
5-8
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
Application / Database Process Type Split Servers / Windchill Server Split Servers / Oracle Server
Single Server
Windchill Oracle Servlet Engine Operating System Web Server Search Engine Total Used Memory
21.00% 21.00% 21.00% 12.50% 5.00% 5.00% 85.50%
30.00% 70.00% 30.00% 12.50% 5.00% 5.00% 85.50% 85.50% 12.50%
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.
5-9
The following table shows a sample memory allocation for a single server configuration that has 8 GB of memory:
Application / Database Process Type Single Server
Total Memory Available Windchill Oracle Servlet Engine Operating System Web Server Search Engine Total Used Memory
8 GB 1.68 GB 1.68 GB 1.68 GB 1 GB 400 MB 400 MB 6.84 GB
The following table shows a sample memory allocation for a split server configuration that has 4 GB of memory for each server:
Application / Database Process Type Split Servers / Windchill Server Split Servers / Oracle Server
Total Memory Available Windchill Oracle Servlet Engine Operating System Web Server Search Engine Total Used Memory
4 GB 1.2 GB
4 GB
2.8 GB 1.2 GB 500 MB 500 MB 200 MB 3.3 GB 3.3 GB 500 MB
5-10
6
Performance 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
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 Customizers 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.
6-2
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 Administrators 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.
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.
6-4
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.
6-5
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 Customizers 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.
6-6
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 Customizers 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.
6-7
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.
6-8
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.
6-9
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.
6-10
7
CPU, 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.
7-2
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 File Cache 0 28 0 8 0 584 2 64 0 Idle Process 4 System
191664 22816490 0:00:00.000 0:00:00.000 <cut> 0:13:02.453 0:00:06.156 0:00:43.046 0:00:38.875 0:01:28.218519780 0:00:00.546 28748 0:00:03.375112456 0:00:02.968115416 4277043 21878 115256 106121 540040 39216 110788 113976 8 8 213 544 14:11:17.968 0:12:24.421 16 232 0 64607
11 340 oracle.exe 30 10124 java_sm.exe 23 8728 java_ms.exe 48 9652 java_bgms.exe
8 1078 8 1134
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
7-3
tid pri Ctx Swtch StrtAddr 1a88 <cut> 24c8 15 3 77E7D295 9 4735 77E813F2
User Time 0:00:10.406
Kernel Time
State
0:00:01.859 Wait:UserRequest
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
7-4
<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:
Process Name CPU Time (ms)
Client browser Apache Tomcat Method Server Oracle
4000 200 2000 5000 2000 13200
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.
7-5
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.
Object \ Counter Processor \ % Processor Time Processor \ Interrupts/sec Suggested Threshold 95% Depends on processor Comments Upgrade to a processor with a larger L2 cache, a faster processor, or install an additional 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. An indirect indicator of the activity of disk drivers, network adapters, and other devices that generate interrupts. 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. 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.
Processor \ % Interrupt Time Server Work Queues \ Queue Length
Depends on processor. 4
System \ Processor Queue Length
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.
7-6
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 Administrators 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.
7-7
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.
7-8
On Windows, use the perfmon tool to collect the objects and counters shown in the following table.
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. This value is an indicator of the maximum paging file size and the amount of physical memory.
Server \ Pool Paged Peak
Amount of physical RAM
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

After performing other tuning actions (as described in earlier chapters) and 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.
7-9
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.
PhysicalDisk \ % Disk Time PhysicalDisk \ Disk Reads/sec, PhysicalDisk \ Disk Writes/sec
90% Depends on manufacturer's specifications
Add more disk drives and partition the files among all of the drives. 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. This is an instantaneous counter; observe its value over several intervals. For an average over time, use Physical Disk\ Avg. Disk Queue Length.
Physical Disk \ Current Disk Queue Length
Number of spindles plus 2
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 w/s kr/s kw/s wait actv 0.0 0.0 0.0 0.0 0.0
device md3
r/s 0.0
svc_t 0.0
%w 0
%b 0
7-10
sd6 sd9 sd10
0.0 0.0 2.0
0.0 0.0 0.0
0.0 0.0 10.0
0.0 0.0 0.0
0.0
0.0
0.0 0.0 9.4
0.0 24.0 0.0 0.0
0 100 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 c1t15d0 c3t15d0 c1t15d0 bps -0 -0 518 sps -0.0 -0.0 36.4 msps 1.0 1.0 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.
7-11
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 Current total memory RMI client sockets RMI bytes in RMI bytes out Database connections = 98282168 bytes = 133955584 bytes = 3 = 1959595 = 2780382 = 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.
7-12
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.
Network Segment \ % Net Utilization Processor \ Interrupts/sec
Depends on type of network Depends on processor
For full-duplex, switched Ethernet networks, for example, 80 percent can indicate a bottleneck. 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.
7-13
Object \ Counter
Suggested Threshold
Comments
Server \ Work Item Shortages
If the value reaches this threshold, consider tuning InitWorkItems or MaxWorkItems in the registry (under HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services \LanmanServer). 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.
Server \ Bytes Total/sec
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. 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. Indicates when bridges and routers might be flooded.
Network Segment \ % Network utilization
Depends on network
Network Segment \ Total frames received/second
Depends on network
On Solaris, use netstat s:

TCP tcpRtoAlgorithm tcpRtoMax tcpActiveOpens tcpAttemptFails tcpCurrEstab tcpOutDataSegs tcpRetransSegs tcpOutAck tcpOutUrg tcpOutWinProbe = 4 tcpRtoMin tcpMaxConn tcpPassiveOpens tcpEstabResets tcpOutSegs tcpOutDataBytes tcpRetransBytes tcpOutAckDelayed tcpOutWinUpdate tcpOutControl = = 400 -1
= 60000 =268751 = 52836 = 40
=762338 = 3538
=158902249 =3513185842 =3075364 =4631349 =102660 =2066461
=135077455 = 15493 =23773785 = = 2 3693
7-14
tcpOutRsts tcpInSegs tcpInAckSegs tcpInDupAck tcpInInorderSegs tcpInUnorderSegs tcpInDupSegs tcpInPartDupSegs tcpInPastWinSegs tcpInWinProbe tcpInClosed tcpRttUpdate tcpTimRetransDrop
= 59983 =160269847 =112714620 =836924 =127944295 = 9787
tcpOutFastRetrans
1549
tcpInAckBytes tcpInAckUnsent tcpInInorderBytes tcpInUnorderBytes tcpInDupBytes tcpInPartDupBytes tcpInPastWinBytes tcpInWinUpdate tcpRttNoUpdate tcpTimRetrans tcpTimKeepalive
=3510005295 = 0
=1062963776 =2875249 =3782883 = 32770 = = = = 0 3694 2346 9670
= 16580 = = 29 0
= 12119 = 208
=112071038 = 0
= 38614 0 0 164
tcpTimKeepaliveProbe= 11315 tcpListenDrop tcpHalfOpenDrop = = 0 0
tcpTimKeepaliveDrop = tcpListenDropQ0 tcpOutSackRetrans = =
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.
7-15
How To Fix Network Bottlenecks

After performing other tuning actions (as described in earlier chapters) and 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.
7-16
A
Oracle 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: http://www.ptc.com/appserver/cs/doc/refdoc.jsp 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
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.
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.
A-4
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
A-5
Following provides rough initial sizing of individual components in the above formulas:
Parameter1 Initial Value
DB_CACHE_SIZE LOG_BUFFER SHARED_POOL_SIZE LARGE_POOL_SIZE JAVA_POOL_SIZE SGA_TARGET PGA_AGGREGATE_TARGET SGA_MAX_SIZE
256M 20971520 128M 16M 16M 416M WT Connections *5M 80% RAM PGA_AGGREGATE_TARGET
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.
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.
A-6
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.
A-7
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.
A-8
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.
A-9
Create a baseline by entering the following:

connect system/manager 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:
connect system/manager 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:
connect system/manager @?/rdbms/admin/awrrpt
A-10
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.
A-11
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:
connect system/manager @?/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') a.index_name = b.index_name order by column_position; ) and
A-12
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.
A-13
A-14
B
SQL 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 its 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
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
C
Operating 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
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 200500MB. 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
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.
C-4
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
C-5
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.
C-6
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.
C-7
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.
C-8
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 adapters documentation). 2. Balance client I/O among network adapters. 3. Enable TCP checksum offloading support if network adapters support it.
C-9
C-10
D
Workflow 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
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.
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 templates 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.
D-4
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 Administrators 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
D-5
D-6
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
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
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 CPU bottlenecks, 7-7
G
Garbage collection tuning, 5-2 glance, 6-10, 7-5
H
How to fix CPU bottlenecks, 7-7 disk bottlenecks, 7-11 memory bottlenecks, 7-9 network bottlenecks, 7-16
Index-1
HP-UX configuring kernel, C-2 disk bottlenecks, 7-11 garbage collection, 5-3, 5-4 glance, 6-10 memory bottlenecks, 7-9 network bottlenecks, 7-13 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
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
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
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 bottlenecks, 7-13 network traffic, 7-12 resolving domain names, 7-16 Network bottlenecks, 7-13 NTFS tuning, C-8
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
Index-2
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.WTContainerTemplateMasterReference, 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.WfContainerTemplateReference, 3-31 wt.workflow.definer.WfNodeTemplateReference, 3-31 wt.workflow.definer.WfProcessTemplateMasterReference, 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 bottlenecks, 7-9 memory statistics snapshots, 7-8 netstat, 7-14 network bottlenecks, 7-13 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
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.maxFrameCount, 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
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
Index-4
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$DefaultViewbyPathCache, 4-16 wt.cache.size.IBAModelImplementation$DefaultIBATypeCach, 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.StandardInitRuleEvalService$Cache, 4-19 wt.cache.size.TeamTemplateCache, 4-19 wt.cache.size.TypeBasedCompositeRuleSelector$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

Windchill Performance Tuning Guide

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Windchill Performance Tuning Guide

Uploaded by

Copyright:

Available Formats

Windchill Performance Tuning Guide

Change Record .................................................................................................... vii About This Guide.................................................................................................. xi

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

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

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