Windchill performance improvement - most methodical way?

That is a long list of articles.  The links below are not in the list above.

What version of Windchill are you using?  PTC and the third-parties fix performance issues when they can.  For example, the latest DB patches are always recommended and there aren't any articles for tuning Java in the latest releases. 

The users' complaint is too broad.  Performance to an end user is how responsive it is in their browser.  Local computer resources, client configuration, and network issues can make a smoothly functioning Windchill appear flaky and slow.  It may not have anything to do with Windchill.  I start by interrogating the end users' complains.  Is it everyone, select people, random?  What functional aspect of Windchill is being impacted? etc.  That helps me determine if it is a server, network, or client issue.

In general, Windchill performance tuning starts at the DB, then moves on to the Windchill-DB configuration, client configuration, and finally investigating potential network issues.

I like to tune the cache values periodically (~every 6 months).  Appropriate cache values change as the DB grows.  The WCA is a place to start and the On-Demand System Scan may highlight other cache values that need adjusting.

I run an On-Demand System Scan and upload the results to PTC.  It returns suggestions in a few minutes.  This ensures there isn't something obvious I'm missing.  FYI: I create a custom System Configuration Collector scan to capture most of the information the On-Demand System Scan wants.

Java tuning is also necessary if Windchill is running on Java 1.8 or earlier.  Getting these values correct can be tricky.

If none of this resolves the issue, I log a Windchill Performance related call with PTC's performance team.  They guide me through deeper troubleshooting and resolutions.

Let me share my thoughts about this topic as I have certain background regarding this list…

The list is too big because Perf is cross-cutting, I think having a hub or article per functionality or server was a good approach!! If the architecture of this list is explained, one can take out the most of it!

First, figuring out from which side the perf is coming is not easier, and having to care about all aspects/all servers would be very difficult and complex, for instance, if you don’t have Solr you don’t have to care about indexing performance (enterprise search perf) and hence dropping all recommendations and troubleshooting techniques related to it.

I think you should make it simple, because I do agree perf investigation is not simple!!

If the user is complaining from “Windchill perf” this wouldn’t help much! At least he or someone else should investigate further and see which functionality is impacted, try to rule out options one by one, the more you limit the behavior, more you identify root causes, sometimes certain conditions change result, for instance the time at which the action is done, how many users connected simultaneously, asynchronous tasks running, etc.

The question of managing perf can be thought as follows:

1. Hardware Sizing: before you install Windchill, you choose best hardware requirements based on PTC recommendations, and your solution (you can only know how many users you would use the app, how many expected input/output operations etc.), there is certain calculation that give you the min sizing.
2. Initial & Periodical Perf settings: Once the solution is running, you can always tweak it, periodically, following best practices, such as tweak certain properties, java heap memory sizing, postpone certain tasks such as (vis) publishing etc. The hardware is always a limitation, and hence first option is necessary but not sufficient!!
3. Just-in time investigation: Whenever you notice slowness, investigation starts, the good thing about perf is that is does not stop the solution from functioning 🙃, otherwise, we are not talking about a perf issue but something else. Many tools exist that will help you identify causes and then fix it!

Perf aspects are not only by functionality/server component, but also by customization, both light and hard! for instance bad customization could be the issue or just a custom attribute created from the UI for which a new db index should be created!

In addition to many servers that the web solution is using, Windchill is often used in conjunction with other solution such as ERPs/WWGM, and hence makes perf issues ambiguate! Without to say that Windchill itself is primarily written in Java which is memory-consuming!

I finish by saying that perf is cross-cutting, all servers are tight to each other. The issue could be the database, or network latency, etc. but the behavior could be seen on Windchill not because its the root cause, but because its functionning is relying on all that stack!!

But I do agree that perf articles/hubs still need clean architecture as there are many duplicate links as you said and overlaps….

Hello ​@Andy_Admin 

First thing I would do is a On-Demand System Scan

Collect the performance and config info from Windchill by the System Configuration Collector

Pack all outputs and send to the On-Denabd System Scan.

It can give you a first help what can help with the perofrmance.

Second

run Windchill Config Assisntant (WCA) with configureCacheManagerSizes option 

ant -f utilities/wca/WindchillConfigAssistant.xml configureCacheManagerSizes -Dpropagate=true

then optimize Database indexes and index fragmentation. It can improve performance. Do it regularly once per a half year

Also do not forget to recount SQL statistics after rebuild

There are many discussions  how to optimize all indexes that are fragmented more then 50% etc. 

MSSQL Procedure for rebuild indexes with fragmentation more then 30%

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
-- =============================================
-- Author:		<HELESIC,,PETR>
-- Create date: <2024-09-12,,>
-- Description:	<REBUILD PROCEDURE ALL INDEX FRAGMENTED MORE THEN 30% - condition,,>
-- =============================================
CREATE PROCEDURE WindchillDB.AV_REBUILD_ALL_INDEXES 
AS
BEGIN
-- Declare variables
SET NOCOUNT ON
DECLARE @tablename VARCHAR (128)
DECLARE @execstr   VARCHAR (255)
DECLARE @objectid  INT
DECLARE @indexid   INT
DECLARE @frag      DECIMAL
DECLARE @maxfrag   DECIMAL

-- Decide on the maximum fragmentation to allow
SELECT @maxfrag = 30.0

-- Declare cursor
DECLARE tables CURSOR FOR
   SELECT TABLE_NAME
   FROM INFORMATION_SCHEMA.TABLES
   WHERE TABLE_TYPE = 'BASE TABLE'

-- Create the table
CREATE TABLE #fraglist (
   ObjectName CHAR (255),
   ObjectId INT,
   IndexName CHAR (255),
   IndexId INT,
   Lvl INT,
   CountPages INT,
   CountRows INT,
   MinRecSize INT,
   MaxRecSize INT,
   AvgRecSize INT,
   ForRecCount INT,
   Extents INT,
   ExtentSwitches INT,
   AvgFreeBytes INT,
   AvgPageDensity INT,
   ScanDensity DECIMAL,
   BestCount INT,
   ActualCount INT,
   LogicalFrag DECIMAL,
   ExtentFrag DECIMAL)

-- Open the cursor
OPEN tables

-- Loop through all the tables in the database
FETCH NEXT
   FROM tables
   INTO @tablename

WHILE @@FETCH_STATUS = 0
BEGIN
-- Do the showcontig of all indexes of the table
   INSERT INTO #fraglist 
   EXEC ('DBCC SHOWCONTIG (''WindchillDB.' + @tablename + ''') 
      WITH FAST, TABLERESULTS, ALL_INDEXES, NO_INFOMSGS')
   FETCH NEXT
      FROM tables
      INTO @tablename
END

-- Close and deallocate the cursor
CLOSE tables
DEALLOCATE tables

-- Declare cursor for list of indexes to be defragged
DECLARE indexes CURSOR FOR
   SELECT ObjectName, ObjectId, IndexId, LogicalFrag
   FROM #fraglist
   WHERE LogicalFrag >= @maxfrag
      AND INDEXPROPERTY (ObjectId, IndexName, 'IndexDepth') > 0

-- Open the cursor
OPEN indexes

-- loop through the indexes
FETCH NEXT
   FROM indexes
   INTO @tablename, @objectid, @indexid, @frag

WHILE @@FETCH_STATUS = 0
BEGIN
   PRINT 'Executing DBCC INDEXDEFRAG (0, ' + RTRIM(@tablename) + ',
      ' + RTRIM(@indexid) + ') - fragmentation currently '
       + RTRIM(CONVERT(varchar(15),@frag)) + '%'
   SELECT @execstr = 'DBCC INDEXDEFRAG (0, ' + RTRIM(@objectid) + ',
       ' + RTRIM(@indexid) + ')'
   EXEC (@execstr)

   FETCH NEXT
      FROM indexes
      INTO @tablename, @objectid, @indexid, @frag
END

-- Close and deallocate the cursor
CLOSE indexes
DEALLOCATE indexes

-- Delete the temporary table
DROP TABLE #fraglist
END
GO

Some script for the sql orecle definitely exists.

PetrH