IBM BPM, V8.0.1, All platforms > Tuning > Advanced tuning
Performance tuning for IBM Integration Designer
If an application fails to run or cycles for a long time without completing, those situations might be caused by insufficient memory. While some of the techniques for improving performance are applied to the server, you can also do some useful analysis in Integration Designer.
IBM Integration Designer can be used in a number of configurations. Although the context is the tools environment, the tuning solutions also involve adjustments to the test environment and Process Server using its administrative console. The issues described here could also occur if you are using Integration Designer with WebSphere Enterprise Service Bus or with IBM Process Center and, optionally, with IBM Business Monitor.
It is a common practice to run Integration Designer and the unit test environment on separate Java virtual machines. The test environment can run on a 32-bit or 64-bit JVM. You will usually get the best results if you match the test environment to the production environment. If a 32-bit application fits well within a 1.5 to 2.5 GB heap, and the application is not expected to grow significantly, a 32-bit servers can still be a good choice. Moving to a 64-bit system causes some degradation in throughput. If the application benefits from a larger heap size, a 64-bit mode is a better choice. For 64-bit operating systems, use a 64-bit test environment, unless you need to match the configuration of your production environment.
Analyzing system memory use
When heap size is increased, the memory available for the rest of the process is decreased. The remaining system memory is used by native code, the JVM loading classes, and the JVM itself. To analyze system memory utilization, use the appropriate system memory tool (for example, vmstat for Linux or Unix systems or Performance Monitor or Task Manager for Windows).
Changing heap size settings
Sometimes publishing in IBM Integration Designer takes a long time, and sometimes the server suddenly stops. If that happens, check the server log for an out of memory error. By default, the Integration Designer test environment is configured for unit testing and it might run out of memory with large workloads. To resolve this issue, increase the heap size. However, if you are running out of native memory, you might need to decrease the heap size. The instructions in "Changing heap size settings in Integration Designer" tell you how to make those changes.
Addressing problems related to garbage collection
This kind of problem can be indicated by either of two symptoms:
- An out of memory exception occurred with frequent garbage collection
activity immediately before the out of memory exception, which results in very little free space in the Java heap.
- Performance is severely degraded without swapping occurring, but the system is spending an excessive amount of time doing garbage collection.
You can address these symptoms by increasing the Java heap size (-Xmx) or tuning the JVM heap. The Java heap must be large enough to contain all required Java objects. However, on 32-bit systems, ensure that it is not so large that the amount of native memory becomes a bottleneck. You need to experiment to determine these limits.
For information about tuning the JVM heap, see 
Tuning the IBM virtual machine for Java in the WebSphere Application Server information center.
Best practices for avoiding performance issues
Not all performance improvements are won through troubleshooting. The way you set up your projects in Integration Designer can also influence efficiency.
Importing a very large number of Java files into Integration Designer can cause build performance issues. To improve performance in this situation, bundle Java classes into Java Archive (JAR) files and reference the JAR files instead of individual Java files. By compiling all the Java source files into a JAR file, you save Java compilation time (which is actually quite significant), and you save time on the Java indexing and validation as well.
Choose non-interruptible processes whenever you can because they provide much better performance at run time. Use interruptible processes (macroflows, long-running processes) only when they are required by human tasks or long-running service invocations. If interruptible processes are required for some capabilities, try to separate those processes so that they are run as exceptional cases.
Choose query tables for task list and process list queries. Query tables are designed to provide good response times for high-volume task lists and process list queries.
Business state machines have a performance impact connected with them, so consider that when you choose to use them.
If you do use business state machines, minimize using external events to drive state transitions. The total time required to run a business state machine is proportional to the number of state transitions that occur.
- Changing heap size settings in Integration Designer
When IBM Integration Designer is responding slowly to mouse clicks or keyboard strokes, use the Heap Status widget or generate the verbosegc.log file to see JVM heap usage. - Addressing performance problems caused by swapping
Excessive swapping between disk and memory can slow performance, but there are remedies that you can apply. - Processing Java files in Integration Designer
When you need to import a very large number of Java files into Integration Designer, those Java files can cause build performance issues.
Related information:
Tuning checklist