Contents: IBM Mashup Center Performance Tuning Guide
Download this content as a PDF file
In order for caching to work correctly in Mashup Center, you must set several key values in the ibmproxy.conf file for WebSphere Edge Server. For example, you should set the SendRevProxyName
value to yes. In addition, you should set the ReversePass
rules to something similar to the following example:
ReversePass http://appserver/* http://proxyserver/*
ReversePass https://appserver/* https://proxyserver/*
These values ensure that HTML links to the application are rewritten with the reverse proxy server name instead of the application server host name. Note that it is safe to pass all URLs for the server if only Mashup Center applications are installed on the application server. In the example above, these URLs are noted by the * character.
When a cache object is re-validated with the back end server, the requests for the same resource continue to be sent to the back end server. This means that a large number of requests for the same resource may hit the back end server, which can cause high resource usage. You can prevent this situation by enabling the following directive: KeepExpired On
. An expired or stale copy of the resource gets returned for the brief time that the resource is updated on the proxy.
The default memory sizes for caching are very small. If you are working with a dedicated server, you can increase the memory cache size to a significant fraction of the total system memory. For our benchmark testing, we configured the proxy with a memory cache of one gigabyte using the following directive: CacheMemory 1 G
Because the proxy server is a 32–bit application, cache memory is limited to about 1500 MB. Larger sizes must be moved to a cache that is backed up by a disk.
Edge Server has its own set of threads used for incoming Mashup Center requests. You should change the following setting to be at least as large as the ThreadsPerChild
setting for the IBM® HTTP Server:
By default, a connection coming into the proxy requires a connection to the back end servers if the request content is not cached. This connection can cause a higher-than-necessary usage of the HTTP Server connection threads. By turning on the proxy’s connection pool, as shown in the following example, Mashup Center requests from front end clients can share existing back end Mashup Center connections and reduce overhead on the HTTP Server:
Finally, you can configure another setting to allow more requests to use the same persistent HTTP connection to the server. By default, only five requests are allowed per connection. You can modify this setting to allow more connections. This update can be especially beneficial when using Secure Sockets Layer (SSL), since an SSL handshake can take a significant amount of time to complete. Allowing more requests per connection allows the SSL connection to stay open longer, which means that less handshakes are necessary. You can change this setting with the MaxPersistRequest
directive. Note that this setting was not required for our testing environment.
To reduce network traffic, we also enabled GZIP on the proxy server for all tests, as shown in the following example. After GZIP is enabled, the zipped files are specified by MIME type. For our testing, all non-image files were compressed.
CompressionFilterEnable <Edge Server install location>\\Bin\\modz.dll
Previous topic: Tuning IBM HTTP Server
Next topic: Tuning the IBM DB2 database