Introduction A growing trend in the e-commerce industry is the exponential growth of assets in catalogs and related assets. The fastest way to access these assets is of course the local, in-memory caching, offered by the GSA, Generic SQL Adapter. But in-memory caching imposes its own limitations: heap size growth, increased database pressure, etc. An alternative […]
As many of you know SatelliteServer comes in two variants: Co-Resident SatelliteServer and Remote SatelliteServer. In this blog I will explain how they differ from a Page Caching perspective, and how that related to ContentServer (Sites) Page Caching. There are also two page fragment caching models in Sites, one is called ContentServer page cache and […]
Introduction A lot of clients end up implementing a large number of pagelets/components per page which if you are not careful with the details may result in many roundtrips between Sites’ ContentServer servlet and Remote Satellite Server. We can best describe this situation as a classic case of “overcaching”. To build their pages, the vast […]
This guide aims to give you complete configuration overview for how to configure Coherence Cache for Oracle WebCenter Portal Framework Application using the Content Presenter Task Flow.
This document is intended for WebCenter Portal Application administrators who have to improve performance by configuring Coherence cache for Content Presenter.
For more information about the Coherence Cache for Content Presenter have a look at the following link:
The Content Presenter and the Content Management Interoperability Service (CMIS) are delivered out of the box with in-memory Coherence cache. This cache is NOT enabled by default. You can enable it by adding the file content-coherence-cache-config.xml to the application class path of the WebCenter Portal Application. This guide describes how to configure the cache when you deploy applications based on WebCenter Portal Framework.
The Content Coherence Configuration file below uses the distributed cache mode in combination with local cache mode depending on the type of objects to be cached. Here the example Coherence cache file to use for the configuration:
<!DOCTYPE cache-config SYSTEM “cache-config.dtd”>
The cache entries are described in the following documentation:
NOTE: You have to put this file into the application classpath. If you use the file in the managed server class path or node manager class path it will NOT work.
Step by Step Installation Process
Step 1: Create JAR file with the Coherence Cache Config file
Create JAR file which contains the example content-coherence-cache-config.xml shown above. For how to create JAR files follow the tutorial from the Java documentation here:
You will use this JAR file to put it inside your WebCenter Portal Framework Application. As mention above this works only if this JAR file is part of the WebCenter Portal Framework Application class path.
Step 2: Create WebCenter Application EAR Lib folder
To put the created JAR file into the APP-INF/lib you have to update your project settings:
·From the JDeveloper WebCenter Portal Application Project click on Application->Application Properties.
·From the new window select Deployment. From the deployment profile select the EAR profile you want to use and then click on Edit button.
· From the new window select File Groups and then click on New button. From the new opened window select Packaging and type a name for the file group as shown bellow. Then click OK to add your new packaging file group. Click then OK again the save the changes.
·Create the APP-INF/lib folder into your project. Go to the file system where you create the WebCenter Portal Application Project as shown bellow
·<!–[endif]–>You have to create the APP-INF/lib folder under the src/ folder:
·<!–[endif]–>Inside the newly created APP-INF/lib folder you can place your JAR file with the Coherence Cache configurations.
·<!–[endif]–>To make sure that the file will be picked go back to JDeveloper and open the Application Properties again by clicking on Application->Application Properties and then click on Deployment. Select the EAR Profile which you used to add the Packaging File Group and click on Edit button. Inside the new window you should see that your APP-INF/lib folder is selected and inside there, there is also the JAR file you copied.
·<!–[endif]–>WebCenter Portal Framework Application is ready for deployment now. Redeploy your application and bounce(load your application one in an browser) to make sure that the configurations are loaded.
Step 3: Check your configuration
NOTE: You have to open your application once to make sure that the Coherence Configuration is loaded.
Make sure that you open the application once in the browser then open your <managed_server>_diagnosting.log file and search for coherence inside. If you see message like this:
[APP: AviTrustSamplePortal#V2.0] Unable to load Coherence configuration file content-coherence-cache-config.xml. Using in-memory (local) caches.
… then it means that your application did not find the configuration file. The reason for that is that the JAR file was not inside the application classpath. In this case you may used the Managed Server Classpath which is not working. You have to place the JAR file inside the application classpath as described above.
If you don’t see the message above you can go for the next step and look for the Coherence configuration inside the MBean.
To do so open your Enterprise Manager and go to the application configuration like shown bellow:
Then from the Application Deployment click on the System MBean Browser to have a look in the MBeans. Inside the MBean Tree search for the word <coherence>:
You should be able to see the configurations as shown above.
Another very good why to check if the cache works is to have a look inside the WCC request audit. It shows if queries were fired against the Content Server.
To do so login as Administrator to WCC.
After you login in as administrator select System Audit Information and from the Active Sections select only system and requestaudit as well as Full Verbose Tracing checkbox.
Click on Update button to update the configuration.
After that click from the upper right menu on View Server Output to trace the Content Presenter queries to the Content Server.
If you open a example page where the content presenter is used, like this:
You can see after that in the audit log the queries used by the content presenter to get the information:
Refresh the page by click on F5 or just the browser refresh button. There’re should be no new queries visible in the audit log anymore, since the content presenter should use the coherence cache now:
Step 4: Configuration for Cluster Environment
If you run your application in cluster environment you have to make sure that the coherence configuration works inside the cluster. If you have two managed servers in one cluster you can configure following parameters in the startup arguments. If Node Manager is used to start the Managed Servers, you can put the argument in the Server Start argument option.
NOTE: If the two server are running on the same physical machine, you have to make sure that they use different ports.
Many customers start out with smaller projects for an initial release. Typically, these applications require 20-30 Proxy services. But as time goes on and later phases of the project rollout, the number of proxy services can increase drastically. The RouterRuntimeCache is a cache implemented by OSB to improve performance by eliminating or reducing the amount of time spent on compiling the proxy pipeline.
By default, OSB will not compile a pipeline until a request message for a given service is received. Once it has been compiled, the pipeline is cached in memory for re-use. You have probably noticed in testing that the first request to a service takes longer to respond than subsequent requests, and this is a big part of the reason. Since free heap space is often at a premium, this cache can not be infinite in size so this cache has a built in limit. When the cache is full, the least recently used entry is released and the pipeline that is currently being requested is placed into cache in its place. The next time a request comes in for the service who’s pipeline was released, that pipeline has to be re-compiled and placed in cache, again forcing out the least recently used pipeline. Once a pipeline is placed in cache it is never removed from cache unless forced out by a full cache scenario as above, or if the service is updated, forcing it to be recompiled.
The default size limit of the RouterRuntimeCache is 100 entries (or pipelines). It is limited by the number of services in the cache, not the memory used by the cache so the amount of memory used by a full cache will vary greatly based on the complexity of the services, the extent and complexity of inline xquery, etc. If your project grows beyond 100 proxy services, system performance can degrade significantly if the cache size is not increased to hold all frequently used services.
the way to tune this cache is not exposed through the OSB console. As
of 11g PS5, the only way to set this parameter is via a system property
specified on the Java command-line. The property name is com.bea.wli.sb.pipeline.RouterRuntimeCache.size. For
“java … -Dcom.bea.wli.sb.pipeline.RouterRuntimeCache.size=500 …
In this example, OSB will cache 500 proxies,
instead of the default 100. Because
increasing the RouterRuntimeCache.size value will
require more space in the heap to hold the additional proxies, be aware that you may need to
reevaluate your JVM memory settings to allow OSB to
continue to perform optimally.