The size of the heap for the IS JVM is only one factor affecting performance. This list of other factors is too long to explore fully in a single post, but includes the efficiency of the service doing the work, the size of the IS thread pool, the speed of the resources (disk drives, database servers, networks, off-the-shelf and custom applications) used to perform the work ,etc.
Generally, the larger the heap size, the more time spent in garbage collection (GC) which can lead to long pause times when nothing else is running on the JVM. However, a heap size that is too small leads to more frequent GC activity and potentially to out of memory errors when a thread tries to create objects bigger than the available memory.
In general, I would not set your heap size higher than the amount you need to process average load plus a contingency amount big enough to handle peak loads most of the time. The amount of memory that is right for your portfolio of integration services will vary based on the number of integrations on your server, the size of the documents being processed and the number of requests to process those documents per unit of time.
You can calculate a heap size to use when you begin testing, but you will need to adjust this by conducting well-designed load tests in a disciplined manner. There is no substitute for this performance testing process other than wishful thinking.
Experienced webMethods consultants can help with designing and running these performance test suites as well as analyzing the results to determine what changes, if any, should be made. Internal or external “experts” who dismiss the need for such testing should be tarred and feathered (or at least ignored) .
Mark
#Integration-Server-and-ESB#webMethods#webMethods-Architecture#webMethods-General