2/20/2020 Document Display

Copyright (c) 2020, Oracle. All rights reserved. Oracle Confidential.

How to Perform GSA Repository Tuning (Doc ID 1037289.1)

In this Document

Goal
Solution

APPLIES TO:

Oracle Commerce Platform - Version 2006.3 and later

Information in this document applies to any platform.
Product Name: Dynamo Application Server
Product Version: 5.0

GOAL

How do I perform GSA Repository Tuning?

SOLUTION

General points to note:

There should be one ServerLockManager configured. This means that only one Dynamo is running with the
/atg/dynamo/service/ServerLockManager instance on. You will need to add this component to your Initial.properties.
By default the ServerLockManager is configured to listen on port 9010.
Make sure that the /atg/dynamo/service/ClientLockManager.properties is set to point to the correct host. Here is an
example of a ClientLockManager.properties

locServerAddress=<the hostname of the machine that is running the ServerLockManager>

lockServerPort=<the port configured in the ServerLockManager properties file>

useLockServer=true

Only one instance of Fulfillment should be running on the system. This means that the startDynamo -m Fulfillment
should only be running on one instance.
Make sure you have one global Scenario server configured and that all other instances are aware of it. This is explained
in the documentation, but essentially requires an xml file change in /atg/scenario/scenarioManager.xml

<scenario-manager-configuration>
<global-server>
<server-name>dyn1:8850</server-name>
</global-server>
</scenario-manager-configuration>

"dyn1" is the hostname that is running the global scenario server. This is documented in Chapter 12 of the administration
guide.
https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=g6krrn6s_4 1/3
2/20/2020 Document Display
Make sure you size your gsa caches appropriately. To size your caches you need to edit the following xml repositories:

/atg/commerce/catalog/productCatalog.xml - this contains categories, skus, products

/atg/commerce/order/orderrepository.xml - orders, commerce items, shipping groups etc..
/atg/commerce/gifts/giftlists.xml - controls gift lists.
(for 5.0 only) /atg/commerce/inventory/inventory.xml

The Product Catalog is probably the single most important repository to size correctly.

You should find out the number of categories, products and skus in your database and try to size the caches such that you can
cache all the hot portions of the catalog. For very large commerce systems, you should try to cache all of categories, products
and skus. That may or may not be feasible but remember that ranges such as:
2000 categories
10000 products
and 100000 skus are no big deal. You can definitely size to cache all of them.

To modify the cache sizes you need to do the following:

1 .Add an xml file into your localconfig in the same location as your xml file.

2. You will need to do something like this for the product catalog:

<gsa-template>
<item-descriptor name="category" item-cache-size="2000">
</item-descriptor>

You will be doing this for every item descriptor. Recall that bundles have links and such so you might end up with multiple
items for every item (many skus for a product, or multiple sku-links if there are bundles).

3. You should verify on startup that the changes took place by looking in the nucleus hierarchy at the component that uses this
xml file

The OrderRepository.xml will require some changes based on your expected concurrent session count and the number of
orders/items/shipping groups you expect to have:

If you want to have 500 concurrent sessions, you should size the orders to have 500 (or maybe 700 if you want a cushion).
If you will have an average of 3 commerce items per order you should set the commerce item descriptor cache to 1500.
If you will have an average of 2 shipping groups per order you shouldset the shippingGroup item descriptor cache to 1000

and so on for each item-descriptor defined.

Make sure you run with the liveconfig configuration and that you are running with -n on the production instances
Every time you have item-descriptors that have a cache-mode of locked you should make sure that they are using a
ClientLockManager that is communicating properly with a ServerLockManager.
Configure the DCS catalog with the switching data source. This is outlined in the documentation. The benefits of this are
that you can have the various changes to the catalog made to the version of the database that is currently not live and
then switch it to become live when you are happy with those changes. In 5.1 we have improved the performance of the
caching so that hot switching is possible. IT IS NOT RECOMMENDED that people modify their data on the live site
directly. THIS IS NOT SUPPORTED.
When you first bring the site live, you can do some level of monitoring by examining the /atg/dynamo/server/DrpServer
for the list of threads that are running and what they are doing. You can also turn on keepingStatistics for the
/atg/dynamo/servlet/RecordingServlet which will show you more of the details (number of times a page has been
requested, avg time, max time, min time etc.)

https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=g6krrn6s_4 2/3
2/20/2020 Document Display
Make sure you size your database pools correctly. A single JTDataSource should be used for all activities that need to
happen together. This means that it is good to verify that all of the repositories are using the same data source.
Monitor your database connections to make sure that they aren't being checked out for extensive periods of time.
Monitor the repository caches to make sure that the hit rates are climbing continuously. On a fully tuned site you should
be seeing hit rates over 90% or even 95% for all product catalog items.

Didn't find what you are looking for?

https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=g6krrn6s_4 3/3