IBM BPM, V8.0.1, All platforms > Tuning > Advanced tuning > Tuning for large objects
Reduce or eliminate other processing while processing a large object
One way to allow for larger object sizes is to limit concurrent processing within the JVM. You must not expect to process a steady stream of the largest objects possible concurrently with other IBM BPM and WebSphere adapters activities.
The operational assumption that needs to be made when considering large objects is that not all objects are “large” or “very large”, and that large objects do not arrive very often, perhaps once or twice a day. If more than one very large object is being processed concurrently, the likelihood of failure increases dramatically.
The size and number of the "normally arriving" smaller objects affects the amount of Java™ heap memory consumption in the system. In general, the heavier the load on a system when a large object is being processed, the more likely it is that memory problems will occur.
For adapters, the amount of concurrent processing can be influenced by setting the pollPeriod and pollQuantity parameters. To allow for larger object sizes, set a relatively high value for pollPeriod (for example, 10 seconds) and low value for pollQuantity (for example, 1) to minimize the amount of concurrent processing that occurs. If that these settings are not optimal for peak throughput, so if a given adapter instance must support both high throughput for smaller objects interspersed with occasional large objects, then trade-offs must be made.