Enterprise Administration > Implementing Windchill ESI > Implementing Windchill ESI in an ORACLE Applications Environment > Performance Planning
  
Performance Planning
Before installing Windchill ESI, it is 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 size.
Identifying potential performance bottlenecks.
Becoming familiar withWindchill ESI’s performance-related design concepts.
Applying performance-tuning parameters and techniques.
Applying Performance-Tuning Parameters and Techniques
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.
Components to Tune
The following components and areas can be tuned for optimum performance and scalability.
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 groupings 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 oneWindchill 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.
Performance-Tuning Techniques
The following lists some techniques that you can use to improve performance and scalability.
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:
Apply the latest JVM patches for your operating system
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.
Adjust operating system kernel parameters to match the characteristics of the application.
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 256 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:
http://www.javaperformancetuning.com/tips/rawtips.shtml
http://java.sun.com/docs/hotspot/VMOptions.html
Investigate later versions of the JRE; these may provide better performance. However they are not supported.
* 
TIBCO automatically compresses XML data that is sent over EMS up to 90%.