I'm all for performance testing Windchill so long as it's the right type of testing being done. But unfortunately, I often feel that testing time and resources could be better spent concentrating on areas other than the maximum concurrency the system can handle from a given set of load scripts.
In many cases load testing Windchill means either creating custom load scripts using a tool like JMeter or SilkPerformer or using a benchmark test provided by PTC to load the system with a synthetic load (there is also a single user test for CAD data management operations also available from PTC).
In my opinion there are a several problems with using a multi-user load to apply a synthetic load to test the performance of a Windchill system:
wt.properties: wt.method.loadbalance.activeContext --> needs to be set high
wt.properties: wt.method.loadbalance.maxRedirects --> needs to be set low or maybe to 0
But by far my biggest issue with LoadTests is that they don't stress or test the operations that are most likely to cause problems on a Windchill system when it goes live and spending time on load tests takes away time from those things. I have looked at hundreds maybe thousands of of systems over the years which were having either performance or stability problems and I can only remember one case where the load peak load from performing a small number of operations caused problems. In that case (I think it was an R8 system) there was an e-mail sent to 800+ people to look at something and many of them did that within a short period of time. The code has improved since then, heaps are bigger and today I think in a properly sized system this action would be less likely to cause problems. Maybe a brief slow down, but nothing to serious. But by far the most common cause of stability problems is caused by one big or few relatively large operations run concurrently and consume many of the available the resources (MethodServer Memory or Oracle capacity being among the most commonly affected) starving the other normal operations of the ability to run quickly if at at all. When this starts to happen in a production system Windchill will report a high number of concurrent users giving the appearance of a load related problem, when it's really a problem brought on by one or a small number of large transactions. Identifying these transactions and correcting their root causes, are the next steps.
Below is by no means an exhaustive list, but some of the more common patterns which performance problems tend to appear are:
My advice is to keep everything in balance. Understand that load tests have significant short comings in ensuring acceptable end user performance and identifying and concentrating on the larger slower operations should be significant part of a performance assurance testing plan. Lastly, arranging for a Performance Engineer to analyze data generated as part of a performance test (either multi user or single operation) will ensure that problems exposed during the performance tests are identified and dealt with appropriately.