oracle commerce external repository caching with · pdf fileoracle commerce - external...

Oracle Commerce External Repository Caching with Coherence O R A C L E W H I T E P A P E R | A U G U S T 2 0 1 6

Oracle A-Team Cloud Solution Architects

ORACLE COMMERCE - EXTERNAL REPOSITORY CACHING WITH COHERENCE

Table of Contents

Executive Summary 1

2. Introduction 1

2.1. Background 1

2.2 Scope 2

3. Deciding Coherence Cache Topologies 2

Oracle Commerce Repository Configuration 3

4.1. Cache Locality 3

4.2. Cache Modes 4

4.3. Properties of Repository 4

5. Coherence Configuration 5

5.1. Creating & Deploying GAR File 5

5.2. Coherence Configuration 6

5.2.1. Coherence invalidation strategy for Near Cache 6

5.2.2. High-Units 9

5.2.3. Thread Count 9

5.2.4. JVM Heap Size parameters 9

Appendix A: Coherence Configuration File 10

Appendix B: JVM Parameters 15

Page Server JVM 15

Cache Server JVM 15


Coherence Management Server 16

Executive Summary Oracle Commerce’s Generic SQL Adapter (GSA) supports different ways of in-memory caching. This caching is very critical for achieving the desired performance. In addition to having its own local caching, it also supports ‘external’ mode of caching. In this mode it does not store data in the internal cache, but instead it stores data in the external Coherence cache. Coherence is a sophisticated, predictably scalable, highly performant, partitioned in-memory cache solution. As of the date this document was published several clients are struggling with using GSA’s Coherence-backed external caching solution. The reasons cited include: poor performance, complex configuration, and difficulty testing in a load test environment to name a few.

The purpose of this document is to provide best practices, set-up and configuration instructions, making it easier for clients to start using external cache.

2. Introduction

2.1. Background

A growing trend in the e-Commerce industry is the exponential growth of assets in catalogs and inventories. The fastest way to access these assets is to cache them locally in JVM memory. But, JVM memory caching has its own size limitation. Coherence employs a data grid to remove the limits imposed by in-memory JVM caching. Oracle Commerce, configured to use external caching in Coherence, can allow customers with such requirements to scale horizontally.

In addition, Coherence also has the additional advantage of reducing the load on database. Moreover, Coherence cache is kept on back-end servers. Thus Oracle Commerce servers could be restarted without losing the data in Coherence cache. This ensures that even after a restart of Oracle Commerce servers, Coherence cache does not have to be warmed-up, as long as at least one of the Coherence cache servers was kept alive.

Although external caching with Coherence offers several advantages, it is not a solution for all use cases. Published asset data, such as catalog and inventory data lends itself well to be cached in Coherence. However transactional data like orders, requires real-time persistence and therefore should not be cached. In general, caching should not be used as a relief for an un-tuned database. Ideally most transactional queries should return in 10-20 milliseconds or so 95% of the time. If that is not happening the database bottleneck should be fixed, rather than trying to cache data in Coherence.

Many companies have inquired about best practices to implement a solution using external caching in Oracle Commerce. The setup is challenging for many reasons. First of all, in Coherence there are several caching models and topologies that could be used. Secondly, there are a lot of configuration options that can be used to control performance. Documentation on each product (Coherence and Oracle Commerce) is limited to their domain and each refers to the other product’s documentation. Setup offers a lot of flexibility, i.e. a lot of configuration options, but guidance is rare. Therefore this paper offers some direction to those seeking to configure Coherence external caching in Oracle Commerce.

It is worth to note that throughout this document there are references to documentation, which is specific to version 11.2 for Oracle Commerce and 12c (12.1.2) for Coherence. The Platform Installation and Configuration Guide, for example, contains instructions on


how to configure Coherence for external caching1. And the Repository Guide2 contains more information regarding Coherence and Commerce integration. A word of warning then: if you are using another version of Oracle Commerce the links just mentioned may not be correct. You should refer to documentation that matches the version of Oracle Commerce and Coherence you have installed.

2.2 Scope

The first version of this document will focus on showing how to configure Commerce and Coherence using Near-cache. Future versions of this document may document additional caching modes and Coherence topologies.

3. Deciding Coherence Cache Topologies Coherence supports several cache topologies, but the Replicated, Partitioned, and Near cache topologies will satisfy the vast majority of use cases. All topologies are fully coherent and support cluster-wide locking. A typical Coherence application includes a back-end tier of cache servers (JVMs dedicated to storing and managing data) and a front-end tier of cache clients (JVMs that produce/consume data).

These are Coherence cache topologies:

» Replicated—In this topology, the cache is replicated on each server. Every server contains a full copy of the data. This allows for very fast read access, as all the data is available in every machine, and data does not have to be brought in from another server. All the writes are copied to all machines. Thus there could be considerable over-head in writes. The maximum size of data also gets limited by the memory size of the smallest machine.

» Partitioned (or Distributed)—In this topology the cached data is partitioned, with each machine containing a unique partition of the data. This provides for very large capacity, as adding machines to the cluster will increase the capacity of the cache. This topology requires that both read & write operation may involve network transfer and serialization/deserialization.

» Near— Near cache consists of two caches. A small local cache, that provides fast access, and the larger back-end Partitioned cache that provides very large data capacity. In this configuration, each Page Serving instance contains a small front-end local cache (or Near cache in Coherence terminology) which is synchronized with the larger back-end Partitioned cache. The obvious advantage of a Near cache is reduced latency for accessing entries that are commonly requested. Additionally, a Near cache will reduce overall network traffic in several ways. Requests for cache entries that exist in the front of the Near cache will be serviced by the client making the request, thus eliminating the need for a request to the cache server. If an entry does not exist in the front of the Near cache, a single request will be made to retrieve that entry from the cache server, even if multiple threads on the client are requesting the same key.

Most Oracle Commerce customers should use either Near or Partitioned topology. The read/write ratio is the key factor in deciding whether to use Near topology or Partitioned topology. Near cache is ideal for those clients that have high ratio of read/write. However, for write heavy application, Partitioned topology may perform better.

The number of Oracle Commerce Page Server instances gets decided by the amount of load, page visits and on-line visitors the Site gets. The number of Back-end Coherence Cache Servers gets decided by the amount of data one has in the Coherence cache, and the number of back-up copies of the data you want to maintain. Typically, most clients maintain one back-up copy.

Details about calculating the size of Coherence cache are given in the Coherence Administrator’s Guide3. As a rule of thumb, cache size should be 3 to 4 times the size of your data (data + backup data+ Coherence indexes + free capacity for future). This is just a rule of thumb.

1 http://docs.oracle.com/cd/E55783_02/Platform.11-2/ATGInstallGuide/html/s1109configuringcoherenceforexternalc01.html

2 http://docs.oracle.com/cd/E55783_02/Platform.11-2/ATGRepositoryGuide/html/s1101externalsqlrepositorycaching01.html

3 https://docs.oracle.com/cd/E24290_01/coh.371/e22838/deploy_checklist.htm#COHAG5264


The following diagram shows the deployment of Near Coherence cache on Page Servers and Coherence Back-End Cache Servers:

Oracle Commerce Repository Configuration There are several properties that need to be changed to enable external cache. This section will discuss the configuration of each one of them.

To enable external caching change the following:

» Cache Locality » Properties of repository

4.1. Cache Locality

The default cache locality is “local” which means GSA uses it’s own caching functionality within its own JVM. In this mode there is no external caching. Therefore cache locality should be changed to “external”, which enables GSA to store data in an external caching application (in this case Coherence.

For scenarios with a large data set and a small subset that is read all the time, it’s best to set cache locality to ‘external’ and use the Near cache and Partitioned topologies. This provides local caching of the data maintained in Coherence Partitioned cache. Also, when using Near cache, coherence is responsible for maintaining the consistency of cache between Coherence front-end Near cache and Coherence back-end Partitioned cache.


As a point of clarification, in addition to the data maintained in Coherence cache, Oracle Commerce always maintains some of its objects in local cache. This is outside of Coherence cache, and Coherence is not aware of its existence. This should not be confused with Coherence Near cache, which is also maintained locally.

If the requirement is to cache just specific item descriptors, one would change the cache-locality attribute in the item-descriptor element to “external”.

If the requirement is to cache the entire repository, one would change the property cacheLocality to “external” in the repository properties file. Please note the distinction of cache-locality and cacheLocality. The former is used in repository definition files (xml) while the latter is used in property files.

More detailed discussion about cache locality, including examples, can be found in the Oracle Commerce Repository Guide4.

4.2. Cache Modes

As discussed in the Repository Guide5, the only 2 modes that should be used with external caching are simple and distributedExternal.

Simple should be used for item descriptors that will not be invalidated by changes, i.e. read-only items such as catalog items.

If the item being cached is expected to change, then the appropriate mode should be distributedExternal, which causes invalidation messages to be sent to other nodes in the cluster.

4.3. Properties of Repository

Modify atg/commerce/catalog/ProductCatalog.properties

The property “externalCacheManager” needs to be set to GSACoherenceManager, which is the component that contains read/write logic to interface with Coherence. Also, as described earlier, cacheLocality needs to be set to “eternal” so that the GSA will use Coherence Partitioned cache.

externalCacheManager=/atg/adapter/gsa/externalcache/GSACoherenceManager selectiveCacheInvalidationEnabled=false cacheLocality=external lazyLoadItems=true

It should be noted that when the cache locality is external, the property item-cache-size6 not utilized. In this case, cache size is controlled either by the size of Coherence nodes or by limiting cache size through Coherence configuration.

There are several repositories that could be cached as well to improve performance. An example is the PriceList (atg/commerce/pricing/priceLists/PriceLists.properties). In the code snippet below the cache locality was set to external. Also, notice that lazyLoadItems was also set to true. This is recommended for this situation, because when you enable lazy loading on an item type or a repository, the cache initially loads only the stubs of the multi-valued property. These include only the repository IDs7. The values of the other properties are deferred until a getPropertyValue call is made8.

cacheLocality=external

4 http://docs.oracle.com/cd/E55783_01/Platform.11-2/ATGRepositoryGuide/html/s1103cachelocality01.html

5 http://docs.oracle.com/cd/E55783_02/Platform.11-2/ATGRepositoryGuide/html/s1103cachemodesforexternalcaching01.html

6 http://docs.oracle.com/cd/E55783_02/Platform.11-2/ATGRepositoryGuide/html/s1302itemdescriptor01.html

7 http://docs.oracle.com/cd/E55783_02/Platform.11-2/ATGRepositoryGuide/html/s1016enablinglazyloading01.html

8 http://www.ateam-oracle.com/oracle-commerce-best-practices-for-repository-item-cache-warming/


lazyLoadItems=true

Here is another example where caching with Coherence allows for a much larger set of caching items. In this case price list has over a million items, so the property maximumCacheEntries (in atg/commerce/pricing/priceLists/PriceCache.properties ) was increased from it’s default value:

maximumCacheEntries=10001000

Additional information about configuring external cache can be found at the Repository Guide9.

5. Coherence Configuration Coherence is integrated with WebLogic server, and does not have to be installed separately. During WebLogic installation, the user is presented with the option to install WebLogic with Coherence.

For this paper, we will demonstrate how Coherence can be configured with Near cache topology – having a back-end Partitioned coherence cache server, and a front-end local coherence cache on Page Server instances. For configuring Coherence topology in WebLogic, you can deploy a collection of files within a directory structure, known as a exploded directory format, or as an archived file called a Grid ARchive (GAR) with a .gar extension. In this document we will explain how to create and deploy a GAR file.

5.1. Creating & Deploying GAR File

Coherence GAR file contains coherence configuration files. The WebLogic manual “Oracle Fusion Middleware Developing Oracle Coherence Applications for Oracle WebLogic Server10” contains more extensive instructions about creating, configuring and deploying GAR files.

We provide here a shorter list of steps to create a GAR file.

Follow these steps to build a Coherence GAR module:

1. Create the following GAR directory structure:

/ /lib/ /META-INF/coherence-application.xml /META-INF/coherence-cache-config.xml

2. Add the Coherence cache configuration file, and coherence-application.xml. If one is using POF Serializer11, the pof-config.xml should also be included here, but for the purpose of this paper, we were not using POF serializer. Note: These configuration files are typically located in META-INF directory.

9 http://docs.oracle.com/cd/E52191_03/Platform.11-1/ATGRepositoryGuide/html/s1101externalsqlrepositorycaching01.html

10 http://docs.oracle.com/middleware/1212/wls/WLCOH/create-application.htm#WLCOH774

11 https://docs.oracle.com/middleware/1221/coherence/develop-applications/GUID-F331E5AB-0B3B-4313-A2E3-AA95A40AD913.htm#COHDG5182


3. Create a coherence-application.xml deployment descriptor file and save it to the /META-INF directory. A Coherence GAR must contain a coherence-application.xml deployment descriptor that is located within the META-INF directory. The presence of the deployment descriptor indicates a valid GAR.

4. Edit the coherence-application.xml file and specify the location of the configuration files coherence-cache-config.xml and [optionally] pof-configuration.xml. For example:

<?xml version="1.0"?> <coherence-application> xmlns="http://xmnls.oracle.com/coherence/coherence-application"> <cache-configuration-ref>META-INF/coherence-cache-config.xml </cache-configuration-ref> <pof-configuration-ref>META-INF/pof-config.xml</pof-configuration-ref> </coherence-application>

5. The GAR file should be packaged as part of the EAR for Page Servers, and deployed with the EAR. For Coherence Back-End cache, the GAR file should be deployed independently through the WebLogic Admin Console.

Detailed instructions for creating GAR file are given in the Coherence documentation12.

5.2. Coherence Configuration

This document describes how to deploy Coherence in Near topology, having a local front-end cache, and a Partitioned back-end cache. The local front-end Coherence cache was in the same JVMs as the Page serving instances. Coherence was configured through config.xml and through JVM parameters. Future versions of the document may describe additional Coherence topologies.

The following important Coherence parameters may require tuning.

5.2.1. Coherence invalidation strategy for Near Cache

Invalidation is the biggest challenge for Near caching. Storing entries in a client is easy, but detecting when changes are made to those entries in other clients is more difficult. Coherence provides several different strategies for Near cache invalidation.

Listener Based Invalidation Strategy

With the listener-based strategies, Coherence will register map listeners that receive events when the contents of the "back" cache are modified. When these events are received by the client, the affected entries will be removed from the front of the Near cache. This ensures that subsequent requests will force a read-through to the cache server in order to fetch the latest version. Coherence supports two listener-based strategies: PRESENT and ALL.

Expiry Based Invalidation Strategy

12 https://docs.oracle.com/middleware/1212/coherence/COHAG/deploy_options.htm#CHDEEBIE


This strategy does not use map listeners to invalidate data, which means there is no way for the front of the Near cache to know when entries are updated. This requires the configuration of an expiry on the front of the Near cache. When an entry expires, this will force a read-through to the cache server to fetch the latest copy. If an expiry-based strategy is used, the invalidation strategy should be set to NONE.

The following is a description of each of the strategies in detail.

Invalidation Strategy ‘Present’ This invalidation strategy indicates that each Near-cache will register a listener for every entry present in the front of the Near-cache.

Advantages: The Near cache will only receive events for entries that it contains, thus greatly reducing the amount of network traffic generated by the cache servers.

Disadvantages: This strategy results in increased latency for cache misses. This is because a map listener must be registered for a key before the entry is retrieved from the cache server.

The increased latency for the listener request will vary depending on the network. A good rule of thumb would be ~1ms of overhead for every cache miss. Another side effects are slightly higher memory consumption on the cache servers to maintain the key registrations, and more CPU cycles on cache server when invalidating cache entry. The exact overhead depends on the size of the keys, and number of invalidations. It’s best to monitor the cache servers if there are lots of invalidations.

This strategy works best for Near-caches that:

» Have access patterns where certain JVMs will access a small portion of the cache - for example, web applications that use sticky load balancing will mostly access the same subset of sessions stored in a cache.

» Have back caches that won't expire or evict data often since there is a latency penalty for cache misses.

Invalidation Strategy ‘All’

The invalidation strategy of ALL indicates that each Near cache will register a single map listener to receive events on all updates performed in the cache. This includes events for entries not present in the Near-cache.

Advantages: This strategy maintains the coherency of the Near cache without the extra latency associated with cache misses. Disadvantages: Every time an entry is updated on the storage tier, an event will be delivered to each Near cache. For clusters with a large client tier, this can generate a large amount of network traffic. This strategy can be especially problematic when bulk updates are preformed via:

• Bulk loading/seeding of the cache (i.e. populating the cache from a database) • Clearing the cache • Cache server failures which cause redistribution which cause mass evictions due to exceeding of high units • This strategy works best for Near caches that:

• Contain a small amount of data (low hundreds of megabytes or less) • Have access patterns that guarantee that a significant portion of the cache will be accessed by each client

When using the ALL strategy, it is important to avoid bulk updates or deletes in order to limit the number of map events that are generated.

Invalidation Strategy ‘None’

The NONE invalidation strategy does not use map listeners; therefore entries in the Near cache are never invalidated. Since there is no invalidation, the front of the Near cache must be configured with an expiry which will force entries to be removed and a read-through to the back tier.

The front of the Near cache must be configured with an expiry. Here is an example:

<near-scheme> <scheme-name>near</scheme-name> <front-scheme> <local-scheme>  <expiry-delay>1m</expiry-delay> </local-scheme> </front-scheme> <back-scheme> <distributed-scheme> <scheme-ref>partitioned</scheme-ref> </distributed-scheme> </back-scheme> <invalidation-strategy>none</invalidation-strategy> </near-scheme> <distributed-scheme> <scheme-name>partitioned</scheme-name> <backing-map-scheme> <local-scheme> <expiry-delay>5m</expiry-delay>  </local-scheme> </backing-map-scheme> <autostart>true</autostart> </distributed-scheme>

An expiry in the backing map is not required; it is shown here for illustrative purposes in order to distinguish between front and back expiry.

Advantages: This strategy is the most scalable since it does not require delivering map events for every update made in the cache. It does not have to pay a latency penalty for misses. Furthermore, this strategy works best for caches that require a high rate of updates. Disadvantages: Near caches will require some tolerance for stale data. Note however that an expiry of as little as a few seconds can make this strategy a good compromise between low latency access and scalable performance for the cluster. This strategy works best for Near caches that

» Have back caches containing large amounts (tens of gigabytes) of data


» Have large client tiers (many dozens or hundreds of JVMS) » Have a requirement for bulk updates

For the purpose of this document, we had set the invalidation-strategy to ‘all’.

<invalidation-strategy>all</invalidation-strategy>

5.2.2. High-Units

This value determines the size of the Near cache (Coherence cache in the same JVM as Page Server). Near cache should be large enough to hold the most frequently accessed products.

<eviction-policy>HYBRID</eviction-policy> <high-units>100000</high-units>

5.2.3. Thread Count

Thread Count specifies the number of daemon threads used by the distributed cache systems. The default is zero and it should be changed. If the default is used, all relevant tasks are performed on the service thread, which creates major performance problems. The thread count can be set in coherence-config.xml.

As with any other application, it should be tuned before being used in a production environment. One of the configuration items that should be looked at is the number of thread counts. The best practice is to limit number of threads to be equal or less than the total number of cores. For example, if a single Coherence JVM is running on a machine with 32 cores, thread count should be set up to 32. However if 2 Coherence JVMs are running the thread count should be set up to 16.

5.2.4. JVM Heap Size parameters

JVM Heap size parameters may need to be tuned like for any J2EE application. For example, NewSize may be set to 30% of max JVM memory size.

-Xms12g -Xmx12g -XX:NewSize=4g -XX:MaxNewSize=4g -XX:PermSize=512m -XX:MaxPermSize=512m

JVM Heap Size parameters are data dependent and will vary according to the amount of data, size of caches and frequency and amount of invalidations. These parameters must be carefully tuned and then set.

Appendix A: Coherence Configuration File Sample Coherence configuration file used for load tests:

<?xml version="1.0"?> <cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config" xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config coherence-cache-config.xsd">  <defaults>  <serializer system-property="tangosol.coherence.serializer"/>  <socket-provider system-property="tangosol.coherence.socketprovider"/> </defaults> <caching-scheme-mapping> <cache-mapping> <cache-name>dist-*</cache-name> <scheme-name>MAATest-distributed</scheme-name> <init-params> <init-param> <param-name>back-size-limit</param-name> <param-value>16GB</param-value> </init-param> <init-param> <param-name>back-expiry</param-name> <param-value>0</param-value> </init-param> </init-params> </cache-mapping> <cache-mapping> <cache-name>near-cache_ProductCatalog_sku</cache-name> <scheme-name>MAATest-near_ForSkuOnly</scheme-name> <init-params> <init-param> <param-name>back-size-limit</param-name>

<param-value>16GB</param-value> </init-param> <init-param> <param-name>back-expiry</param-name> <param-value>0</param-value> </init-param> </init-params> </cache-mapping> <cache-mapping> <cache-name>near-*</cache-name> <scheme-name>MAATest-near</scheme-name> <init-params> <init-param> <param-name>back-size-limit</param-name> <param-value>16GB</param-value> </init-param> <init-param> <param-name>back-expiry</param-name> <param-value>0</param-value> </init-param> </init-params> </cache-mapping> <cache-mapping> <cache-name>local-*</cache-name> <scheme-name>example-object-backing-map</scheme-name> </cache-mapping> <cache-mapping> <cache-name>*</cache-name> <scheme-name>MAATest-distributed</scheme-name> <init-params> <init-param> <param-name>back-expiry</param-name> <param-value>0</param-value> </init-param> </init-params> </cache-mapping> </caching-scheme-mapping> <caching-schemes>  <distributed-scheme> <scheme-name>MAATest-distributed</scheme-name> <service-name>DistributedCache</service-name> <backing-map-scheme> <local-scheme> <scheme-ref>example-binary-backing-map</scheme-ref> </local-scheme> </backing-map-scheme> <autostart>true</autostart> </distributed-scheme> <!-- Near caching (two-tier) scheme with size limited local cache in the front-tier and a distributed cache in the back-tier.

--> <near-scheme> <scheme-name>MAATest-near_ForSkuOnly</scheme-name> <front-scheme> <local-scheme> <eviction-policy>HYBRID</eviction-policy> <high-units>1000</high-units> <expiry-delay>1m</expiry-delay> </local-scheme> </front-scheme> <back-scheme> <distributed-scheme> <scheme-ref>MAATest-distributed</scheme-ref> </distributed-scheme> </back-scheme> <invalidation-strategy>present</invalidation-strategy> <autostart>true</autostart> </near-scheme> <near-scheme> <scheme-name>MAATest-near</scheme-name> <front-scheme> <local-scheme> <eviction-policy>HYBRID</eviction-policy> <high-units>1000</high-units> </local-scheme> </front-scheme> <back-scheme> <distributed-scheme> <scheme-ref>MAATest-distributed</scheme-ref> </distributed-scheme> </back-scheme> <invalidation-strategy>present</invalidation-strategy> <autostart>true</autostart> </near-scheme>  <local-scheme> <scheme-name>example-object-backing-map</scheme-name> <eviction-policy>HYBRID</eviction-policy> <high-units>{back-size-limit 0}</high-units> <expiry-delay>{back-expiry 1h}</expiry-delay> <cachestore-scheme></cachestore-scheme> </local-scheme> <!-- A scheme used by backing maps that store data in internal (binary) format and employ size limitation and/or expiry eviction policies.

--> <local-scheme> <scheme-name>example-binary-backing-map</scheme-name> <eviction-policy>HYBRID</eviction-policy> <high-units>{back-size-limit 0}</high-units> <unit-calculator>BINARY</unit-calculator> <expiry-delay>{back-expiry 1h}</expiry-delay> <cachestore-scheme></cachestore-scheme> </local-scheme>  <local-scheme> <scheme-name>unlimited-backing-map</scheme-name> </local-scheme>  <read-write-backing-map-scheme> <scheme-name>example-read-write</scheme-name> <internal-cache-scheme> <local-scheme> <scheme-ref>example-binary-backing-map</scheme-ref> </local-scheme> </internal-cache-scheme> <cachestore-scheme></cachestore-scheme> <read-only>true</read-only> <write-delay>0s</write-delay> </read-write-backing-map-scheme>  <overflow-scheme> <scheme-name>example-overflow</scheme-name> <front-scheme> <local-scheme> <scheme-ref>example-binary-backing-map</scheme-ref> </local-scheme> </front-scheme> <back-scheme> <external-scheme> <scheme-ref>example-bdb</scheme-ref> </external-scheme> </back-scheme> </overflow-scheme>  <external-scheme> <scheme-name>example-bdb</scheme-name>

<bdb-store-manager> <directory></directory> </bdb-store-manager> <high-units>0</high-units> </external-scheme>  <invocation-scheme> <scheme-name>example-invocation</scheme-name> <service-name>InvocationService</service-name> <autostart system-property="tangosol.coherence.invocation.autostart">true</autostart> </invocation-scheme>  <proxy-scheme> <scheme-name>example-proxy</scheme-name> <service-name>TcpProxyService</service-name> <acceptor-config> <tcp-acceptor> <local-address> <address system-property="tangosol.coherence.extend.address">localhost</address> <port system-property="tangosol.coherence.extend.port">9099</port> </local-address> </tcp-acceptor> </acceptor-config> <autostart system-property="tangosol.coherence.extend.enabled">false</autostart> </proxy-scheme> </caching-schemes>


Appendix B: JVM Parameters

Page Server JVM

These java parameters were used in the page serving JVMs. Following Coherence best practice, configuration was packaged in a cache GAR file, which was then added to the commerce EAR. More information can be found in the WebLogic documentation13

-Xms12g -Xmx12g -XX:NewSize=4g -XX:MaxNewSize=4g -XX:PermSize=384m -XX:MaxPermSize=384m -XX:+UseLargePages -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=90 -XX:+UseCMSInitiatingOccupancyOnly -XX:ConcGCThreads=5 -XX:ParallelGCThreads=6 -XX:StringTableSize=1000003 -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=7095 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djavax.management.builder.initial=weblogic.management.jmx.mbeanserver.WLSMBeanServerBuilder -Dcom.sun.management.jmxremote -Dtangosol.coherence.management=local-only -Dtangosol.coherence.management.remote=true -Dtangosol.coherence.management.report.autostart=true -Dtangosol.coherence.management.report.distributed=true -Dtangosol.coherence.reporter.output.directory=<REPORTER_LOG_LOCATION> -Dtangosol.coherence.member=<WLS_MANAGED_SERVER_NAME> -Doracle.coherence.machine=scan04cn21.us.oracle.com -Dtangosol.coherence.localhost=192.168.219.197 (bond0 internal IB interface) -Dtangosol.coherence.management.extendedmbeanname=true -Dtangosol.coherence.mode=prod -Dtangosol.coherence.distributed.localstorage=false

Cache Server JVM

The following parameters were used in the cache Server JVMs (Coherence).

-Xms12g -Xmx12g -XX:NewSize=4g -XX:MaxNewSize=4g -XX:PermSize=512m -XX:MaxPermSize=512m -XX:+UseLargePages -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=90 -XX:+UseCMSInitiatingOccupancyOnly -XX:ConcGCThreads=5 -XX:ParallelGCThreads=6 -XX:StringTableSize=1000003 -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=7091 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djavax.management.builder.initial=weblogic.management.jmx.mbeanserver.WLSMBeanServerBuilder -Dcom.sun.management.jmxremote -Dtangosol.coherence.management=local-only -Dtangosol.coherence.management.remote=true -Dtangosol.coherence.management.report.autostart=true -Dtangosol.coherence.management.report.distributed=true -Dtangosol.coherence.reporter.output.directory=<REPORTER_LOG_LOCATION> -Dtangosol.coherence.member=<WLS_MANAGED_SERVER_NAME> -Doracle.coherence.machine=scan04cn24.us.oracle.com -Dtangosol.coherence.localhost=192.168.219.197 (bond0 internal IB interface) -Dtangosol.coherence.management.extendedmbeanname=true -Dtangosol.coherence.mode=prod -Dtangosol.coherence.distributed.localstorage=true

13 http://docs.oracle.com/middleware/1212/wls/WLCOH/create-application.htm#WLCOH719


Coherence Management Server

Classpath:

<EM_AGENT_EMbase>/plugins/oracle.sysman.emas.agent.plugin_12.1.0.7.0/archives/coherence/coherenceEMIntg.jar <EM_AGENT_EMbase>/plugins/oracle.sysman.emas.agent.plugin_12.1.0.7.0/archives/coherence/bulkoperationsmbean.jar

Java args:

-Xms12g -Xmx12g -XX:NewSize=4g -XX:MaxNewSize=4g -XX:PermSize=384m -XX:MaxPermSize=384m -XX:+UseLargePages -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=90 -XX:+UseCMSInitiatingOccupancyOnly -XX:ConcGCThreads=5 -XX:ParallelGCThreads=6 -XX:StringTableSize=1000003 -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=7193 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djavax.management.builder.initial=weblogic.management.jmx.mbeanserver.WLSMBeanServerBuilder -Dcom.sun.management.jmxremote -Dtangosol.coherence.management=all -Dtangosol.coherence.management.report.distributed=true -Dtangosol.coherence.member=<WLS_MANAGED_SERVER_NAME> -Dtangosol.coherence.localhost=192.168.219.197 (bond0 internal IB interface) -Doracle.coherence.machine=scan04cn22.us.oracle.com -Dtangosol.coherence.management.extendedmbeanname=true -Dtangosol.coherence.mode=prod -Dtangosol.coherence.distributed.localstorage=false %s/-XX:+UseParallelGC -XX:+UseParallelOldGC/-XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=90 -XX:+UseCMSInitiatingOccupancyOnly -XX:ConcGCThreads=5/g


Oracle Corporation, World Headquarters Worldwide Inquiries 500 Oracle Parkway Phone: +1.650.506.7000 Redwood Shores, CA 94065, USA Fax: +1.650.506.7200

Copyright © 2015, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only, and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. 0615 Oracle Commerce – External Repository Caching with Coherence August 2016

C O N N E C T W I T H U S

blogs.oracle.com/oracle

facebook.com/oracle

twitter.com/oracle

oracle.com

oracle commerce external repository caching with · pdf fileoracle commerce - external...

Documents