Performance Planning

Before installing Windchill ESI, it is also important to consider the factors that are involved in planning system performance. This section highlights important areas to review and focus on when consideringWindchill ESI performance.

Since each environment is unique and systems integration projects are inherently complex, it is not feasible to provide a single set of steps that can be followed to optimize the performance of all systems. However, the following information, combined with the experience of skilled systems integrators, should help you get started on achieving specific performance goals. These include:

• Analyzing message numbers and sizes.

• Identifying potential performance bottlenecks.

• Becoming familiar with ESI’s performance-related design concepts.

• Applying performance-tuning parameters and techniques.

When optimizing performance, it is useful to identify and quantify the data load at interfaces between TIBCO components and the systems to be integrated, for each transaction in a publish operation. The areas to consider for the number of messages and their size are:

• ESIPostResult = Number of business objects or subtransactions in the ESIResponse +1 (n+1)

• ESIResultReponse (n+1)

The size of the response message is typically much larger than the other messages, as it contains all of the product structure data for the given transaction.

• API calls per business object or subtransaction (approximately 3) multiplied by the number of business objects or subtransactions in the ESIResponse message.

• ERP API results (approximately 3) multiplied by the number of business objects or subtransactions in the ESIResponse message.

Windchill ESI services will create as many transactions as there are ERP instances in a given release. Thus, the number of messages per release (or publish operation) will equal the number of messages per transaction multiplied by the number of transactions that are created for the release.

• The latency effect or time lag that occurs when integrating end-systems. This includes:

• The processing time between an adapter instance and SAP. Due to the complex, layered SAP architecture and the low-level RFC communications required, the processing between an adapter instance and SAP typically exceeds the resources that are consumed and required in the relatively straightforward mapping from the BusinessWorks process to the adapter.

To analyze resource consumption and timing, use TIBCO BusinessWorks Administrator's performance monitoring features. Refer to TIBCO Administrator User’s Guide for details.

This section highlights and lists aspects of Windchill ESI’s design that may impact performance. Taking these into consideration would be useful as you assess and plan for optimal performance.

• Windchill ESI does not use TIBCO Rendezvous Certified Messaging (RVCM), therefore, managing ledger files and the associated performance impacts do not come into play. Due to Windchill ESI's strategic use of JMS, request/reply messaging, and synchronous SAP APIs, the Reliable Messaging (RV) delivery option adequately provides robust transaction management services.

• Windchill ESI uses checkpoints at key points in the TIBCO BusinessWorks processing flow to prevent data corruption in the event of system failures. Checkpoints persist the current state of the application to disk, and therefore are notably slower to execute than memory-based operations. However, the location of checkpoints has been strategically designed to ensure robust transaction integrity while minimizing adverse performance effects.

• Windchill ESI does not use an external or third-party database and therefore is not subjected to any of the associated performance impacts.

• Windchill ESI does not support multi-threading (parallel processing) within a single product data release operation (that is within a single BusinessWorks job). This is due, in part, to the object processing sequence required by SAP. Multi-threading/parallel processing is, however, supported between different jobs.

• Windchill ESI by default uses a single adapter configuration for all SAP objects. In other words, the adapter instances do not use TIBCO's automatic load balancing (RVCMQ) feature. This is due to the complexity of the SAP API set (multiple API calls are required in sequence to process a single business object) and a TIBCO restriction on the management of adapter sessions. If adapter throughput is a critical concern for you, we recommend you look into the performance tuning options, described later, or develop new SAP APIs that can process one business object with a single API call. Developing new SAP APIs would help in restoring the option of using the RVCMQ feature, but would require extensive customization of the Windchill ESI application.

This section recommends specific techniques for tuning and improving system performance. Areas where you can apply performance-tuning techniques are listed first followed by suggested performance-tuning techniques.

• TIBCO BusinessWorks application: This component uses an embedded implementation of Java Runtime Environment (JRE) which creates the Java Virtual Machine (JVM). The JVM can be tuned for better performance.

• TIBCO BusinessWorks process engines: These are logical grouping of jobs; a process engine runs within a single Java Virtual Machine (JVM).

• TIBCO BusinessWorks jobs: These are instances of a BusinessWorks process template and consume resources. One job corresponds to one overallWindchill ESI product data publish operation per ERP instance, or one ESI transaction.

• TIBCO BusinessWorks threads: These are the same as Java threads. Threads represent a pool of workers for jobs. Each thread executes a fixed number of BusinessWorks activities and is then released back to the pool.

• Adapter connections: These represent the data channels available to the distribution targets. Refer to the appropriate TIBCO adapter documentation for a complete understanding of how connections are formed, and when they are released.

• JVM memory size: This needs to be monitored to check how much memory is consumed for a given number of jobs and if this is pushing the limits of available memory. You can use basic operating system tools to perform this function.

• CPU usage allocation: This activity needs to be monitored because having multiple, available CPUs does not guarantee that the application resource load is automatically distributed across them. CPU load-balancing is typically configured at the operating-system level.

• Additional host machines: Adding more physical servers can provide greater data throughput, as well as high-availability features.

• Perform a data volume/frequency analysis to predict likely adapter memory consumption. To establish a baseline, measure the memory consumption of an idle adapter instance.

• Assess the latency in your environment as this is critical when integrating end-systems.

• Minimize the number of unused, idling process engine jobs in BusinessWorks, as they needlessly consume memory.

• Consider the option of tuning the Java Virtual Machine (JVM) using these suggestions:

◦ Tune heap and stack size to optimize garbage collection, including selecting an optimal value for the TIBCO BusinessWorks engine’s thread stack size deployment setting.

◦ Set the -Xms and -Xmx parameters on the JVM, which are operating system independent and control the amount of memory allocated to the JVM at startup (-Xms) and the maximum amount of memory the JVM is allowed to consume (-Xmx). At a minimum, these should both be set to 512 MB. If the application generates java.lang.OutOfMemoryErrors during testing or production runs, then you must increase the -Xmx parameter to larger values.

◦ Investigate other JVM parameters and tuning options. Depending on the JVM and operating system, there may be other tuning options available. The following web sites should be helpful: