Performace Tunning with OSB – RouterRuntimeCache and Proxy initialisation


As your project grows and the number of proxy services you have in the project grows significantly (>100) you might notice that the performance of the services degrades heavily.

This can be attributed to the fact that the OSB is now unable to Cache all your services at runtime.

OSB caches proxy service runtime meta-data using a two-level cache with static and dynamic sections. The cache introduces a performance trade off between memory consumption and compilation cost. Note that caching proxy services may help throughput but could impact memory usage.

The static section is an upper-bound Least Recently Used (LRU) cache that is never garbage collected. When a proxy service is bumped from the static section, it is demoted to the dynamic section where the cache can be garbage collected when there is memory pressure.

Fortunately for us there is a fix for this in place already.

The number of proxy services in the static portion of the cache can be tuned by configuring the RouterRuntimeCache appropriately.

It’s done using a system property com.bea.wli.sb.pipeline.RouterRuntimeCache.size. The default value is 100. Note that this is the number of proxies and NOT dependent on the size of each or proxies so the memory it takes can depend on complexity of these proxies and any Xqueries they call.

This setting can be increased to a desired value provided there is sufficient memory for runtime data processing for large number of proxy services, or you will have to increase the system JVM settings accordingly along with the increase to the runtime cache value.

This property value can be set in the setDomainEnv.sh file as an extra java argument as follows:

-Dcom.bea.wli.sb.pipeline.RouterRuntimeCache.size={size}

Example:

EXTRA_JAVA_PROPERTIES=”-Dcom.bea.wli.sb.pipeline.RouterRuntimeCache.size=3000 ${EXTRA_JAVA_PROPERTIES}”
Additionally, you might still notice that the first invocation is slow as we see while trying to test the services, this is due to the fact that these services are being compiled then and any future invocations will be a lot faster due to them being in the static Cache.
There is a very interesting article by Mark Smith illustrating how we can utilise this setting to improve the SLA and ensure that the first invocation does not cause you to fail on your SLA. https://blogs.oracle.com/MarkSmith/entry/osb_proxy_initialization/

Ref: http://docs.oracle.com/cd/E25054_01/core.1111/e10108/osb.htm


		

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s