Contents: IBM Mashup Center Performance Tuning Guide
This topic describes the details and results of the performance testing of the WebSphere Application Server instance of Lotus® Mashups.
In our measurement environment, Lotus Mashups and MashupHub were installed on the same server but with separated instances of WebSphere Application Server. Lotus Mashups is composed of standard Java Web applications. Therefore, typical tuning practices for WebSphere Application Server applications were used in our testing. In your environment, at a minimum, you should size and monitor database connection pools, the application server thread pools, and the JVM heap. See the following sections for details about each of these components.
Database connection pools
The default maximum WebSphere Application Server Java Database Connectivity (JDBC) pool size is only 10 Lotus Mashups connections. You should increase this number of connections for all types of installations. In our benchmark testing, each application that we measured had a maximum of 100 Lotus Mashups connections. Certain applications had an even higher number of connections. We recommend that you set this value to 100 after installation and tune your testing environment as required by your workload. Also, be sure to confirm that the back end database will accept the total number of Lotus Mashups connections from all JDBC pools.
In addition, the initial prepared statement cache size is also too small. As a result, we set the cache size value 100.
WebContainer thread pools
The default maximum size of the WebSphere Application Server WebContainer thread pool of Lotus Mashups 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 Lotus Mashups.
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 Lotus Mashups 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 Lotus Mashups 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 Lotus Mashups 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.
Multipart is a new Mashup Center 2.0 feature. Server-side Lotus Mashups provides a way to handle multiple requests to a POC DataSource or a POC DataSink with one single request to the mashup source or sink. This is interesting if the mashup handler is accessed through an HTTP request, because then multiple logical requests can be tunneled through one single physical HTTP request.
In addition, the multipart requests sent by the HTTP GET method can be cached by the HTTP Server or Edge Server, so enabling the multipart feature correctly can improve browser-side performance and result in almost no regression for server-side performance. The negative impact on server-side performance of multipart is minimal. You can locate the following five multipart attributes of the WebSphere Application Server instance of Lotus Mashups by navigating to Resource
-> Resource Environment
-> Resource Environment Providers
-> Custom properties
- com.ibm.mashups.multipart.enabled and pageLoadOptimization: These two attributes enable and disable the multipart feature. Values are either false or true. Set these values to true to enable multipart.
- com.ibm.mashups.multipart.correlatehosts: With the default value of false, the browser sends only one multipart request to retrieve resources, even the resources are distributed on a different host. This may take a long time. Set the value to true to allow the browser to send different multipart requests for different hosts.
- pageLoadOptimizationTheme: Keep the default value of true to enable the multipart feature for theme files. Enabling this feature may improve client-side performance. Also, enabling this feature has no negative impact on server-side performance.
- pageLoadOptimizationAppWidgets: Keep the default value of false to disable the multipart feature for application widget files. Enabling this feature decreases server-side performance, especially under complex deployment and network conditions.