Contents: IBM Mashup Center Performance Tuning Guide

---

To download a PDF file of this content, click IBM Mashup Center Performance Tuning Guide and select to save the file.

Enabling cache

You can enable caching for MashupHub feeds to reduce the resource cost on the MashupHub server as well as the MashupHub database server. To enable caching for a feed, do the following steps:

1. Locate the feed that you want to modify in the catalog.
2. Open the details page for the feed.
3. In the Advanced section, expand the Caching data section.
4. Select the Cache data from the feed option, and specify the number of seconds the data should be cached. The lifetime is the time to cache the feed in seconds. 86400 is cache for one day.
   
   

Now, you feed details page should look similar to the following example:

Limiting feed size

To improve performance, try to limit the size of your feed by filtering out unnecessary data. As a general rule, smaller feeds perform better than larger feeds.

Improving disk input output

Disk I/O is an important performance factor for MashupHub feed access. The better the disk I/O, the greater the feed performance. For example, to improve disk I/O, you can add a new disk storage for the MashupHub table space to share the overhead on the disk I/O and improve server-side capacity.

Avoiding negative impact on the target database

The content in relational feeds is stored in a separate database. In our environment, we call this type of database the target database. When accessing a relational feed, MashupHub connects to, logs in to, queries, and disconnects from the target database. Frequent feed access creates significant overhead when connecting to, logging in to, and disconnecting from the database. For example, when working with some version of DB2® using Microsoft® Windows®, a heavy disk I/O occurs on the target database for authentication, which may be a limiting factor for database feeds. Here are two possible tuning methods that you can try in your own environment.

In this first approach, you can create a data source in WebSphere Application Server for the target database. Without a data source, each time a request is sent to a database feed, a database connection has to be created between server and target database. These connection operations use a lot of disk I/O resources on the target database. To learn how to configure a data source in WebSphere Application Server, see Configuring the WebSphere Application Server data source at http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/twim_fedmap_datasconf.html. To learn more about creating a database using a data source, see Creating a feed from an enterprise database (JDBC) at http://publib.boulder.ibm.com/infocenter/mashhelp/v2/index.jsp?topic=/com.ibm.muh.useradmin.doc/userhelp/feedhelp/help_feeds_sql.htm.

In this second approach, if you are using a DB2 server that is older than version 9.3, set the following DB2 variable to improve the connection times to the DB2 server: DB2_GRP_LOOKUP = LOCAL,TOKENLOCAL or DB2_GRP_LOOKUP = token. For more information, see the following IBM® support document: http://www-01.ibm.com/support/docview.wss?uid=swg1JR26395.

Previous topic: Tuning the IBM DB2 database
Next topic: Understanding general performance characteristics of the catalog, feed generators, and data mashup builder