Property file

You can review the properties that let you enhance system performance.

Application server connection pool parameters

Sterling Order Management System Software components (e.g., EJB, servlets) that run in the application servers use the Application Server Connection Pool parameters to find the connection pool. Refer to WebLogic connection pool if you are using WebLogic or WebSphere connection pool if you are using WebSphere® for more detail.

The Application Server Connection Pool parameters are not applicable to agents and the asynchronous adapters because they do not run in the application server.

Note: If Sterling Order Management System Software running in an application server cannot get a connection through the connection pool, it tries to establish a connection through the Direct Connection parameters. If you do not like this behavior, you can comment out the Direct Connection parameters in the application server-specific yfs.properties file. The application server transactions that cannot get a connection aborts with an exception.

Reference data cache parameters

Reference data caching is critical for performance and scalability. By default, the cache is enabled. Please see Performance feature - reference data caching for more detail, recommendations and strategies.

User interface control

The UI Control parameters are only applicable to the screen workloads (e.g., JSPs) running in the application servers. They provide system level controls to the application administrators.

yfs.ui.maxRecords

In addition to this control, the List screens have a Maximum Record field which is currently defaults to 30. Therefore, out-of-the-box, if the user issues a search that has 1,000 records, only 30 are displayed. The user can, at their discretion, change the value of Maximum Record up to the value specified by yfs.ui.MaxRecords.

There is an important points that you need to be aware of:

The yfs.ui.MaxRecords only controls the number of records (e.g., orders or items) that can be displayed in a list. It does not control the amount of work the database has to perform to get those records. For example, a user can issue a very inefficient query by asking for all orders that "contains" the letter "Z" in the order number or in the customer's e-mail id. Those queries typically result in a full table scan of potentially large tables.

yfs.ui.queryTimeout

API control

yantra.app.maxrecords

This parameter serves as a safe guard to limit records returned by LIST APIs to 5,000 records. Please see List APIs.

Statistics

By default, Sterling Order Management System Software generates application-level statistics every 10 minutes. The statistics generation is governed by the following parameters:


   yantra.statistics.collect=y
   yantra.statistics.persist.interval=10m

The System Management Console relies on these statistics.

Please see Statistics for more information.

Caution: The time that JVMs refresh their YFS_HEARTBEAT status is set to yantra.statistics.persist.interval / 2. Therefore, by default, the YFS_HEARTBEAT refresh interval is set to 5 minutes. We recommend that you do not increase the yantra.statistics.persist.interval parameter because of its secondary effect on the YFS_HEARTBEAT refresh interval.

Hot SKU feature

Please see Hot SKU control parameters for information on the Hot SKU control parameters.

Yfs.inventory.sortandlock

To prevent deadlocks, Sterling Order Management System Software sorts the order or shipment lines by the items at the line level (see Sort order and deadlocks) prior to processing. As the application processes the line, it locks the YFS_INVENTORY_ITEM record. For example, given the following four line order where:

  • Line 1, item A
  • Line 2, item G
  • Line 3, item F
  • Line 4, item E

Sterling Order Management System Software locks the items and process the lines in the following sequence:

  • Lock item A, process line 1
  • Lock item E, process line 4
  • Lock item F, process line 3
  • Lock item G, process line 2

Transactions that follow this convention reduces the likelihood of deadlocks. The exception is when orders has kits. Using the example above, assume that item G in line 2 is a kit that is made up of the following kit items D, B, and C. Since the application sorts the item at the line level, the application still processes lines 1, 4, 3, and 2 as above. However, when the transaction processes item G, it potentially locks the kit items out of sequence. Using the example above, the locking sequence is as follows:

  • Lock item A, process line 1
  • Lock item E, process line 4
  • Lock item F, process line 3
  • Lock items B, C, and D, process line 2

If you are processing kits and are experiencing deadlocks, you can set the yfs.inventory.sortandlock parameter to Y. With the parameter enabled, the application first sorts and locks all the line item and kit items prior to processing the transaction. Using the example above, if you enable yfs.inventory.sortandlock, the application performs the following:

  • Lock item A, B, C, D, E and F first
  • Process line 1
  • Process line 4
  • Process line 3
  • Process line 2
Note: Setting the yfs.inventory.sortandlock increases the amount of time the YFS_INVENTORY_ITEM locks are held. That increase may not be noticeable in small orders (for example, five line orders). However, that increase could be noticeable if the number of lines is large (for example, over 100 or 200 lines).

Warning: You should not set this parameter if you do not process kits. Setting this parameter does not add any value to non-kit orders.

See Related Sections: