Contents: IBM Mashup Center Performance Tuning Guide
Download this content as a PDF file
Similar to Lotus® Mashups, tuning the WebSphere Application Server instance of MashupHub also involves setting database connection pools, application server thread pools, and JVM heap properties. An additional configuration component is WebSphere® DynaCache for MashupHub feeds.
Database connection pools
In our testing, the maximum number of database connection pools is 50. In addition, the default prepared statement cache size is also too small. As a result, we set the cache size value to 100.
You can monitor the results of these settings in various ways, for example by enabling the IBM® Tivoli® Performance Monitor or from tracking high-water marks in database snapshots.
WebContainer thread pools
The default maximum size of the WebSphere Application Server WebContainer thread pool of MashupHub is 50, which is too small. In our measurements, we set this size to at least a maximum of 100, or 25 threads per processor core, to allow more simultaneous requests on the WebSphere Application Server instance of MashupHub.
You can monitor the actual number of threads being used in the pool by enabling the appropriate performance counters and launching the IBM Tivoli Performance Monitor.
The default size for each WebSphere Application Server JVM is not set. The maximum heap size of MashupHub should be at least 768 MB. To obtain our results, we used a maximum heap size of 1024 MB.
If your machine has more than one processor, we recommend parallel garbage collection. You can enable this setting for MashupHub with –XgcthreadsN
, where N is double the CPU core number.
Note that when running larger JVM sizes, all the JVMs running on a physical server must fit into the physical memory of the server.
In our measurements, one critical setting was enabling the generational garbage collector. Enabling this setting with -Xgcpolicy:gencon
for MashupHub means that the JVM reserves several small areas of the heap (two by default) for all new objects called nursery spaces. When one of these areas becomes full, only this area is scanned for dead objects. Any objects still living are moved to a different nursery space. If, after another garbage collection, the second nursery space still has an object in it, these objects are moved to the main heap. This action results in many short garbage collection cycles instead of less frequent, longer garbage collection pauses. In our measurements, with generational collection enabled, garbage collection cycles occur every one to two seconds but take less than 50 milliseconds to complete. This allows higher throughput since there is less chance of transactions being held up by a one-second pause for garbage collection, which would happen with the default collector.
We recommend that you enable verbosegc
logging and monitor heap use with any of the settings described above.
MashupHub supports cache in the server-side JVM memory. MashupHub uses WebSphere DynaCache to cache feeds. The cache instance is called MashupHub feed cache
, which can be found in Resources
-> Cache instances
-> Object cache instances
You can modify the cache size according to your needs. We recommend that your JVM heap setting have 40 percent of free heap after caching. In a default installation, memory size is set to 256 MB, which is the value we used in our testing.
is the number of entries to put in the cache. This value should be large enough to hold the cache entries that are associated with the more frequently used feeds in the application mix. In a default installation, the number of entries is set to 2000, which is the value we used in our testing. When a feed is enabled for server-side cache, the feed data will be cached in the DynaCache.
Previous topic: Tuning the WebSphere Application Server instance of Lotus Mashups
Next topic: Tuning IBM HTTP Server