TIBCO® MDM Performance Tuning GuidePerformance Tuning Overview TIBCO MDM handles multiple functions...

TIBCO® MDMPerformance Tuning GuideSoftware Release 9.1August 2017

Two-Second Advantage®

Important Information

SOME TIBCO SOFTWARE EMBEDS OR BUNDLES OTHER TIBCO SOFTWARE. USE OF SUCHEMBEDDED OR BUNDLED TIBCO SOFTWARE IS SOLELY TO ENABLE THE FUNCTIONALITY (ORPROVIDE LIMITED ADD-ON FUNCTIONALITY) OF THE LICENSED TIBCO SOFTWARE. THEEMBEDDED OR BUNDLED SOFTWARE IS NOT LICENSED TO BE USED OR ACCESSED BY ANYOTHER TIBCO SOFTWARE OR FOR ANY OTHER PURPOSE.

USE OF TIBCO SOFTWARE AND THIS DOCUMENT IS SUBJECT TO THE TERMS ANDCONDITIONS OF A LICENSE AGREEMENT FOUND IN EITHER A SEPARATELY EXECUTEDSOFTWARE LICENSE AGREEMENT, OR, IF THERE IS NO SUCH SEPARATE AGREEMENT, THECLICKWRAP END USER LICENSE AGREEMENT WHICH IS DISPLAYED DURING DOWNLOADOR INSTALLATION OF THE SOFTWARE (AND WHICH IS DUPLICATED IN THE LICENSE FILE)OR IF THERE IS NO SUCH SOFTWARE LICENSE AGREEMENT OR CLICKWRAP END USERLICENSE AGREEMENT, THE LICENSE(S) LOCATED IN THE “LICENSE” FILE(S) OF THESOFTWARE. USE OF THIS DOCUMENT IS SUBJECT TO THOSE TERMS AND CONDITIONS, ANDYOUR USE HEREOF SHALL CONSTITUTE ACCEPTANCE OF AND AN AGREEMENT TO BEBOUND BY THE SAME.

This document contains confidential information that is subject to U.S. and international copyright lawsand treaties. No part of this document may be reproduced in any form without the writtenauthorization of TIBCO Software Inc.

TIBCO and Two-Second Advantage are either registered trademarks or trademarks of TIBCO SoftwareInc. in the United States and/or other countries.

Enterprise Java Beans (EJB), Java Platform Enterprise Edition (Java EE), Java 2 Platform EnterpriseEdition (J2EE), and all Java-based trademarks and logos are trademarks or registered trademarks ofOracle Corporation in the U.S. and other countries.

All other product and company names and marks mentioned in this document are the property of theirrespective owners and are mentioned for identification purposes only.

THIS SOFTWARE MAY BE AVAILABLE ON MULTIPLE OPERATING SYSTEMS. HOWEVER, NOTALL OPERATING SYSTEM PLATFORMS FOR A SPECIFIC SOFTWARE VERSION ARE RELEASEDAT THE SAME TIME. SEE THE README FILE FOR THE AVAILABILITY OF THIS SOFTWAREVERSION ON A SPECIFIC OPERATING SYSTEM PLATFORM.

THIS DOCUMENT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSOR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OFMERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT.

THIS DOCUMENT COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICALERRORS. CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN; THESECHANGES WILL BE INCORPORATED IN NEW EDITIONS OF THIS DOCUMENT. TIBCOSOFTWARE INC. MAY MAKE IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S)AND/OR THE PROGRAM(S) DESCRIBED IN THIS DOCUMENT AT ANY TIME.

THE CONTENTS OF THIS DOCUMENT MAY BE MODIFIED AND/OR QUALIFIED, DIRECTLY ORINDIRECTLY, BY OTHER DOCUMENTATION WHICH ACCOMPANIES THIS SOFTWARE,INCLUDING BUT NOT LIMITED TO ANY RELEASE NOTES AND "READ ME" FILES.

Copyright © 2010-2017 TIBCO Software Inc. All rights reserved.

TIBCO Software Inc. Confidential Information

2

TIBCO® MDM Performance Tuning Guide

Contents

Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

TIBCO Documentation and Support Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

Performance Tuning Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Deployment Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Hardware and Operating System Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Physical Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Input Output Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Java Virtual Machine Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Heap Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

JVM Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Data Source Configuration on JBoss WildFly Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Multiple JBoss Instances on One Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

TIBCO ActiveSpaces® Tuning and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Deployment Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

ActiveSpaces Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

ActiveSpaces Cache Memory Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

ActiveSpaces Cache Config Files Shipped with the Product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

TIBCO MDM Cache Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Monitoring ActiveSpaces Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Apache Ignite Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Oracle Database Configuration and Performance Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Initialization Parameters Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Tablespaces Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

Database Table Pinning in Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Microsoft SQL Server Database Configuration and Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Database Optimizations on Microsoft SQL Server - Customer Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Heavy Input Output Contentions on TEMPDB Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

CXPACKET Wait-type Observed Frequently . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Lesser Dedicated Memory to Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Incorrect Snapshot Isolation Level Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

File-Grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Antivirus Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Lack of Indexes on MVT Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Query Optimization on Product Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Storage or IO Contention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

3


Over-Aggressive Scheduled Maintenance Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

EMS Configuration and Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Database Loader Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

When to Use Database Loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Performance Best Practices for Database Loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Data Source Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Data Source Upload Limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28

Direct Load Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28

Performance Best Practices for Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Rulebase Execution Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Workflow Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Regular Workflow Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30

In-Memory Workflow Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30

Impact of In-Memory Workflows on UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Regular Workflows versus In-Memory Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

In-Memory Configuration through Configurator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

When to Use In-Memory Workflow Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Workflow Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Limitations for In-Memory Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Workflow Activity Parallelization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Activity Parallelization Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Asynch Call Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Activity Parallelization Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36

Record Bundling Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Record Caching Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Preload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38

Performance Best Practices for Preloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Guidelines for Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39

Purge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Performance Best Practices for Purge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40

Configuration for Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Standard Logging Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Performance Tuning Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4


Figures

TIBCO MDM Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

ActiveSpaces Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Setting the Pool Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Data Source Upload Limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Workflow Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Web services Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

TIBCO MDM Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

Activity Parallelization Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Preload Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38

Preload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5


TIBCO Documentation and Support Services

Documentation for this and other TIBCO products is available on the TIBCO Documentation site. Thissite is updated more frequently than any documentation that might be included with the product. Toensure that you are accessing the latest available help topics, visit:

https://docs.tibco.com

Product-Specific Documentation

Documentation for TIBCO products is not bundled with the software. Instead, it is available on theTIBCO Documentation site. To directly access the documentation for this product, double-click thefollowing file: TIBCO_HOME/release_notes/TIB_mdm_version_docinfo.html

where TIBCO_HOME is the top-level directory in which TIBCO products are installed. On Windows,the default TIBCO_HOME is C:\tibco. On UNIX systems, the default TIBCO_HOME is /opt/tibco.

The following documents for this product can be found on the TIBCO Documentation site:

● TIBCO MDM Release Notes

● TIBCO MDM Installation and Configuration Guide

● TIBCO MDM User’s Guide

● TIBCO MDM System Administration

● TIBCO MDM Customization Guide

● TIBCO MDM Workflow Reference

● TIBCO MDM Web Services Guide

● JAVA API Reference

● TIBCO MDM Best Practices Guide

● TIBCO MDM Performance Tuning Guide

● TIBCO MDM Rest Services Guide

● Swagger API Reference

How to Contact TIBCO Support

For comments or problems with this manual or the software it addresses, contact TIBCO Support:

● For an overview of TIBCO Support, and information about getting started with TIBCO Support,visit this site:

http://www.tibco.com/services/support

● If you already have a valid maintenance or support contract, visit this site:

https://support.tibco.com

Entry to this site requires a user name and password. If you do not have a user name, you canrequest one.

How to Join TIBCO Community

TIBCO Community is an online destination for TIBCO customers, partners, and resident experts. It is aplace to share and access the collective experience of the TIBCO community. TIBCO Community offersforums, blogs, and access to a variety of resources. To register, go to the following web address:

https://community.tibco.com

6


https://docs.tibco.com

http://www.tibco.com/services/support

https://support.tibco.com

https://community.tibco.com

Performance Tuning Overview

TIBCO MDM handles multiple functions such as data cleansing, data retrieval, and bulk data insertswhere the volume of data can be millions of records. This topic provides information on TIBCO MDMperformance tuning methodologies and best practices, and hardware and software tuning techniques. Italso contains information on OS, JVM, and TIBCO MDM configuration parameters tuning.

System performance can vary depending on the volume of records that TIBCO MDM manages,concurrent users accessing the application, and the record level hierarchy (records depth withrelationships). The TIBCO MDM Performance Tuning Guide provides information on tuning the variouslayers of TIBCO MDM for stability, scalability, and large data volumes that can help achieve optimalsystem performance.

Deployment ModeThe following diagram depicts a high level architectural overview of TIBCO MDM and shows thevarious layers described in the guide.

The following layers are described in the guide:

● Hardware and Operation system

● Application layer

● Distributed Cache layer

● Messaging layer

TIBCO MDM Overview

7


Hardware and Operating System Tuning

TIBCO MDM manages the existing data as well as the data in motion across the organization.

The key performance parameters include:

● Volume of data

● Complexity of data (record hierarchy with relationships)

● Workload on the system

Allocating the correct hardware is critical for proper sustained performance of the solution. The correctsize of the hardware required to effectively run the final solution depends on the volume of the dataand the overall complexity of the solution.

You can scale TIBCO MDM performance by running TIBCO MDM on faster hardware (that is, moreCPUs and increased input/output) or by increasing the physical memory available.

Depending on the resources available, you can opt for horizontal scaling by deploying multiple TIBCOMDM instances on the same machine or vertical scaling by deploying multiple TIBCO MDM instanceson different machines.

Physical MemoryPhysical memory available on the system should satisfy the TIBCO MDM Heap settings (along withJVM or native thread stack overhead) and accommodate any other processes.

Size the available physical memory accordingly to accommodate the heap settings of the TIBCO MDMServer, memory allocated to the cache server, and any other processes running on the machine.

Before you start multiple instances of TIBCO MDM on the same machine and the cache server, ensurethat enough memory is available.

Allocate memory to the distributed cache at startup depending on the system memory available. Sizethe cache according to the memory available to ensure that eviction does not trigger when extensivecaching is used in the implementation. See TIBCO ActiveSpaces® Tuning and Configuration for moredetails.

Preload, an important function, loads the specified number of records into the cache from the databaseas defined in the TIBCO MDM configuration.

Insufficient memory available on the system for the records to be loaded in cache can trigger aneviction. Memory requirements depend on the attributes defined in the metadata model and thecomplexity of the data (record hierarchy with relationships). For more details, refer to Preload.

CPUTIBCO MDM relies on highly efficient threading to achieve its throughput in handling data and servingcontent to the user. For optimal performance, deploy TIBCO MDM, Database, and EMS on separatephysical machines.

Running other third-party applications creates competition for CPU and may have a negative effect onTIBCO MDM Server performance.

Direct Load Import is one of the TIBCO MDM features which is CPU intensive. If a CPU resource on aTIBCO MDM instance is available, you can increase the pool size of the asynchronous queue or increasethe number of TIBCO MDM instances.

In-memory workflow executions are another feature that is CPU intensive.

For concurrent processing including operations such as UI, web services, and Bulk Load, ensure thatyou have adequate CPU resources available for processing the requests.

8


If CPU usage on an TIBCO MDM instance is high, you may want to use Load Balancing. See LoadBalancing for more details.

Input Output ThroughputTIBCO MDM is a highly input/output intensive system which receives, stores, and retrieves data fromthe database.

Application logging level can also have an impact on input/output performance. See Configuration forLogging for more details.

Consider deploying faster storage hardware such as network, drives, or implement striping formultiple data destinations. If the input/output throughput for the system is below industry standards,check for input/output chain misconfiguration, ensure the firmware is up-to-date, or validate the SAN(Storage Area Network) routing configuration. You can also reduce the latency between the databaseand the TIBCO MDM server.

9


Java Virtual Machine Tuning

The Java Virtual Machine (JVM) tuning.

Heap SizeThe JVM heap is a repository of active objects, inactive objects, and free memory. When an object can nolonger be reached from any pointer in the running program, it is considered garbage and ready forcollection. When the JVM heap runs out of memory, all processing in the JVM stops until garbagecollection completes.

The JVM heap size is important because it controls how often, and for how long garbage collectionruns. If garbage collection runs too infrequently, the extra time that is required to complete garbagecollection can negatively affect the TIBCO MDM performance.

These are the recommended JVM settings for TIBCO MDM:

● Java heap (-Xms4096m -Xmx4096m). To avoid out of memory errors use identical settings forminimum and maximum memory. A good practice is to set the 512 MB heap per configured workerthread. For example, if there are eight worker threads, setting a heap of 4 GB is sufficient. Thesetting also depends on the bundle sizes.

● Performance options:

XX:NewSize=256m. Default size of new generation (in bytes) XX:MaxPermSize=512m. Size of the Permanent Generation

● Behavioral options:

XX:-UseParallelGC. Use parallel garbage collection for scavenges.

● Debugging options:

XX:+HeapDumpOnOutOfMemoryError. Dump heap to file when java.lang.OutOfMemoryError isthrown

Use the debugging options only if you suspect a memory leak and you need to take the heap dump outof memory. This is not recommended in a production environment.

For GC -XX:-ParallelGC is recommended to select the parallel garbage collector for the new generationof the Java heap. For more information, refer to http://www.oracle.com/technetwork/java/tuning-139912.html.

The JVM heap size is a configurable parameter that you can set when you start the TIBCO MDMinstance. You may also want to review the G1 garbage Collector introduced in JDK 1.7.0. For moreinformation, refer to http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/G1GettingStarted/index.html.

JVM ParametersThe JVM parameters are set in standalone.conf under the $JBOSS_HOME/bin directory.

You can set the following for JVM parameters for TIBCO MDM:

JVM Parameters

Parameter Value Additional Information

-Xms 4096m Java Heap Size

-Xmx 4096m Maximum Java Heap Size

10


http://www.oracle.com/technetwork/java/tuning-139912.html

http://www.oracle.com/technetwork/java/tuning-139912.html

http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/G1GettingStarted/index.html

http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/G1GettingStarted/index.html

Parameter Value Additional Information

-XX:MAxPermSize 512m Maximum Size forPermanent Generation Heap

-XX:NewSize 256m Default Size of NewGeneration

-XX:+UsePArallelGC Use parallel garbagecollection for scavenges

XX:+HeapDumpOnOutOfMemoryError Dump heap to file whenjava.lang.OutOfMemoryError isthrown

-Dsun.rmi.dgc.server.gcInterval 3600000 ms Ensures that unreachableremote objects areunexported and garbage iscollected in a timely fashion.The value of this propertyrepresents the maximuminterval (in milliseconds)that the RMI runtime allowsbetween garbage collectionsof the local heap. Thedefault value is 60000milliseconds (60 seconds).

-Dsun.rmi.dgc.client.gcInterval 3600000 ms Ensures that DGC cleancalls for unreachable remotereferences are delivered in atimely fashion. The value ofthis property represents themaximum interval (inmilliseconds) that the RMIruntime allows betweengarbage collections of thelocal heap. The default valueis 60000 milliseconds (60seconds).

To improve overall throughput, consider using a parallel garbage collection strategy. This type ofstrategy works best with workloads that are designed to:

● reduce or eliminate garbage collection pauses

● trade some memory throughput to accomplish the reduction or elimination

For more information on JVM, options, see

http://docs.oracle.com/javase/7/docs/technotes/guides/vm/

To verify the effectiveness of the garbage collection strategy, run the application, and measure eitherresponse times or the throughput relative to garbage collection pause times, or both.

11


http://docs.oracle.com/javase/7/docs/technotes/guides/vm/

Data Source Configuration on JBoss WildFly ApplicationServer

With Java EE6, the new annotation @Data SourceDefinition enables you to configure a data sourcedirectly from within their application.

A data source is a Java Naming and Directory Interface (JNDI) object used to obtain a connection froma connection pool to a database.

You can set the data source configurations at the following locations:

● JBoss WildFly : Edit the standalone.xml file located in the $JBOSS_HOME\standalone\configuration directory.

Consider setting the following parameters in the data source configuration file for performance tests:<min-pool-size>100</min-pool-size><max-pool-size>500</max-pool-size><blocking-timeout-millis>30000</blocking-timeout-millis>

● min-pool-size: specifies the minimum number of connections a pool should hold. These poolinstances are not created until an initial request for a connection is made. The default is 0.

● max-pool-size: specifies the maximum number of connections for a pool. The max-pool-size numberof connections is the maximum that is created in a pool. The default is 20.

● blocking-timeout-millis: specifies the maximum time in milliseconds to block while waiting for aconnection before throwing an exception. Note that this blocks only while waiting for a permit for aconnection, and never throws an exception if creating a new connection takes an inordinately longtime. The default is 5000.

Multiple JBoss Instances on One MachineMultiple instances of JBoss WildFly Application Server can run on a single machine provided you havethe necessary system resources such as RAM or CPU. These instances can be clustered or runindependently depending on your business requirements.

Running multiple instances:

● Scaling: you may need to test horizontal scaling of the application to determine if you have enoughsystem resources available.

● Isolation: you may require complete isolation of your applications if one application is unstable andnegatively impacts the other applications.

● QA: you might like a separate QA environment which is isolated from the developmentenvironment on the same box.

● JBoss WildFly Application Server version dependencies: you may have multiple applications withsome applications requiring version X of JBoss WildFly Application Server or version Y of JBossWildFly Application Server.

● JVM version dependencies: one application may require JDK 1.7 and another application mayrequire JDK 1.8. JBoss WildFly Application Server can use either, therefore you can launch oneinstance using 1.7 and another instance using 1.8 (unclustered).

12


TIBCO ActiveSpaces® Tuning and Configuration

ActiveSpaces combines the features and performance of databases, caching systems, and messagingsoftware to support large, highly volatile data sets and event-driven applications. With ActiveSpacesyou can offload transaction-heavy systems and enable developers to concentrate on business logicrather than the complexities of developing distributed fault-tolerance.

Deployment ModeTIBCO MDM can be configured for deployment, with ActiveSpaces in a peer-to-peer configurationwhere MDM members act as SEEDERS and centralize configuration where MDM members act asLEECH.

● With ActiveSpaces in a true peer-to-peer configuration where all the members are direct peers toeach other. Each member acts as SEEDER here. In this configuration all the members contribute tothe cache size. SEEDER plays an active role in maintaining the space by providing CPU and RAM.

● With ActiveSpaces where MDM members act as LEECH to a centralized distributed cache server.LEECH plays a passive role; it has access to space data but provides no resources.

For high performance scenarios, deploy TIBCO MDM in true peer-to-peer SEEDER role. Defaultconfiguration is SEEDER.

ActiveSpaces Server ConfigurationSet the AS Member Distribution Role property to the SEEDER role using Configurator (NodeID >Optimization - Member) for high performance levels.

ActiveSpaces Server Configuration

This deployment mode yields the highest performance level, however all processes must establishbidirectional TCP connections to each other.

ActiveSpaces Cache Memory ConfigurationThe ActiveSpaces Cache memory sets the maximum memory allocated to the cache server. For theSEEDER role all the members of TIBCO MDM in the clustered environment contribute to the cachememory.

The memory is allocated to ActiveSpaces cache at startup. ActiveSpaces Cache memory configuration isdone in CacheConfig.xml under the $MQ_HOME/config directory. <ServerConfig> <Name>Standard configuration</Name> <CacheServerCount>1</CacheServerCount> <CharSet>singlebyte</CharSet> <Memory>20480</Memory>

13


<HeapStorage>300</HeapStorage> <OverHead>1.3</OverHead> <ReplicationCount>0</ReplicationCount> <RowOverHead>2170</RowOverHead> <MinimumSeederRequiredForPreload>1</MinimumSeederRequiredForPreload> </ServerConfig>

The unit of memory is MegaBytes.

ActiveSpaces Cache Config Files Shipped with the ProductThree CacheConfig files are shipped with the product.

● CacheConfig.xml: sample can be used for QA environment testing.

● CacheConfig.dev.xml: sample can be used in Dev environment testing.

● CacheConfig.large.xml: preferred sample for high performance scenarios where millions of recordsneed to be cached and the list size for a few objects is set to -1.

You can change the property in Configurator to pick any of the preceding CacheConfig files:

<ConfValue description="This file describes the caching configuration." name="Cache ManagerConfiguration File" propname="com.tibco.cim.init.MqCacheManager.configFile" sinceVersion="7.0"visibility="All"> <ConfString default="config/CacheConfig.xml" value="config/CacheConfig.xml"/></ConfValue>

Depending on the number of records to be cached or preloaded, you can set the memory according tothe available memory on the system.

TIBCO MDM Cache CalculationTIBCO MDM uses cache objects of different sizes depending on the amount of data held. TIBCO MDMinternally calculates the cache size for each object based on the ListSize provided in CacheConfig.xmlfor the individual objects. For heavily used cache objects, allocate more memory to the object files in theconfiguration file.

Depending on the memory resources available, set the ListSize of individual objects inCacheConfig.xml. ListSize of -1 <ListSize>-1</ListSize> means unlimited size is set for that particularobject in ActiveSpace cache. Depending on the ListSize defined in the configuration file, if the memoryallocated for a particular object is full, eviction policy comes into effect which could impact theperformance. For high performance scenarios, it is recommended to set the ListSize to -1 for theRECORD, RECORDMAXMODVERSION, PRODUCTKEY and MV_VALUE objects.

Monitoring ActiveSpaces CacheThe CacheManager utility enables you to get the statistics of ActiveSpaces cache and member details.You can use the utility to monitor the Put/Take/Expire/Seed/Unseed activity.

You can execute the CacheManager utility from the $MQ_HOME\bin directory:

CacheManager Usage [options]

-? : print usage

-connect: Connects to the metaspace

-Listen: Listen space for [Put/Take/Expire/Seed/Unseed] activity

-member: Displays information about members

-space: Displays space details

-search: Searches the records in space

14


-asadmin: Executes the exact asadmin commands

Follow these steps to monitor AS spaces. You can monitor Put\Take\Get\Expire\Evicts.

Procedure

1. Enter ./CacheManager.sh

2. Enter Connect.

3. To monitor the RECORD space, enter space -s RECORD.

4. To monitor the Evicts, use the members detail command.

5. To monitor the individual spaces in the metaspace, use as-admin under $MQ_HOME/as/2.1/lib.

15


Apache Ignite Tuning

The generic tuning recommendations for Apache Ignite are as follows:

● Disable internal events notifications: the default configuration supplied with TIBCO MDM disablesall event notifications

● Turn off backup: the default configuration supplied with TIBCO MDM does not configure backup,however, it can be configured to avoid single point failure

● Disable SWAP storage: the default configuration supplied with TIBCO MDM disables SWAP usage

● Tune cache data rebalancing: any change in topology results in re-balancing. Rebalancing mightrequire additional resources and hit cache performance. The default configuration of Apache Igniteis used.

● Configure thread pools: Apache Ignite has its main thread pool size set to the two times availableCPU count

● Disable peer class loading: the default configuration supplied with TIBCO MDM disables peer classloading by defining property peerClassLoadingEnabled=false in the IgniteMember.xml file.

● Tune garbage collection: Apache Ignite recommends G1 garbage collector with the followingsettings as a starting point for JDK 1.8:

-XX:NewSize=512m

-XX:SurvivorRatio=6

-XX:+AlwaysPreTouch

-XX:+UseG1GC

-XX:MaxGCPauseMillis=2000

-XX:GCTimeRatio=4

-XX:InitiatingHeapOccupancyPercent=30

-XX:G1HeapRegionSize=8M

-XX:ConcGCThreads=16

-XX:G1HeapWastePercent=10

-XX:+UseTLAB

-XX:+ScavengeBeforeFullGC

-XX:+DisableExplicitGC

16


Oracle Database Configuration and Performance Tuning

TIBCO MDM stores the master data of the enterprises in the backend database and retrieves potentiallylarge amounts of data from the database. If the database does not perform well, the TIBCO MDMServer slows down as a result. A properly tuned backend database helps the TIBCO MDM Server runmore efficiently.

For better performance of the Oracle database, you need to do some important database configuration.However, you should consult an experienced database administrator (DBA) who can take appropriatedecisions to set up your particular database environment.

Initialization Parameters ConfigurationThe following table describes the initialization parameters set in the performance lab for testingmedium and large systems. The SGA and PGA requirements for performance payload was 24G and10G respectively.

Initialization Parameters

Parameter Value Description

db-block_size 8192 Specifies (in bytes) the size of Oracle databaseblocks. Typical values are 4096 and 8192. Thevalue of this parameter must be a multiple of thephysical block size at the device level. Thisparameter affects the maximum value of theFREELISTS storage parameter for tables andindexes.

db_cache_size 10G Specifies the size of the DEFAULT buffer poolfor buffers with the primary block size (the blocksize defined by the DB_BLOCK_SIZEinitialization parameter).The value must be atleast 4M * number of cpus * granule size (smallervalues are automatically rounded up to thisvalue).

db_file_multiblock_read_count

16 Minimizes disk input/output during table scansby specifying the maximum number of blocksread in one input/output operation during asequential scan.

db_writer_processes 10 Useful for systems that modify data heavily. Itspecifies the initial number of database writerprocesses for an instance.

job_queue_processes 10 Specifies the maximum number of processes thatcan be created for the execution of jobs.

17


Parameter Value Description

open_cursors 3024 Specifies the maximum number of open cursors(handles private SQL areas) a session can have atonce. This parameter prevents a session fromopening an excessive number of cursors. It isimportant to set the value of OPEN_CURSORShigh enough to prevent your application fromrunning out of open cursors.

parallel_threads_per_cpu

8 Specifies the default degree of parallelism for theinstance and determines the parallel adaptiveand load balancing algorithms. The parameterdescribes the number of parallel executionprocesses or threads that a CPU can handleduring parallel execution.

processes 1000 Specifies the maximum number of operatingsystem user processes that can simultaneouslyconnect to an Oracle server. This valueaccommodates all background processes such asJob Queue (SNP) and parallel execution (Pnnn)processes.

sessions 2000 Specifies the total number of user and systemsessions.

optimizer_adaptive_features

true Enables or disables all of the adaptive optimizerfeatures, including adaptive plan (adaptive joinmethods and bitmap plans), automatic re-optimization, SQL plan directives, and adaptivedistribution methods.

The optimizer_adaptive_features property (default value is set to true) may produce a huge negativeimpact on the performance, especially with the RAC database. If negative performance is observed,change the property on RAC database with Oracle 12C.

Tablespaces ConfigurationTIBCO MDM manages the master data of the enterprises across different tables in the database. Tomanage the data in the database, create individual tablespaces for all the large tables and their indexes.

Create all the indexes including unique and primary keys for each large table in a separate table space.

Create separate tablespaces for the following tables and their associated indexes:

● Master Catalog Table (MCT)

● MV_SHARED Tables for different data types

● MV Non Shared Tables (MVT)

● Relationship Attribute Tables (RCT)

● GOLDENCOPY

● PRINCIPALKEY

● PROCESSLOG

18


● PRODUCTKEY

● PRODUCTLOG

● RELATIONSHIP

For optimal performance it is recommended to have the data files on Solid State Drives (SSD).

Contact the engineering team for information regarding the scripts.

Database Table Pinning in MemoryTo improve the performance of TIBCO MDM when using Oracle, ensure that you use the commonlyused tables that are cached in memory.

The following commons used tables should be used:

● ASSOCIATION

● CONFIGURATIONDEFINITION

● DOMAIN

● DOMAINENTRY

● DOMAINLINK

● DOMAINSTRING

● DOMAINVALUE

● RESOURCEACCESS

● RESOURCEACL

● QUEUEENTRY

● FUNCTION

● OBJECTSEQUENCE

● ORGANIZATION

● ENTERPRISE

● WORKFLOWFORM

Run the sample script after the installation is complete. The sample script is located under$MQ_HOME/db/oracle/install/tablepinning.sql and contains a complete list of tables which should bepinned in memory.

Consult your database administrator (DBA) to modify and run this script.

19


Microsoft SQL Server Database Configuration and Tuning

This chapter describes how to manage the data in the database and create individual data files for largetables.

Data Files Configuration

TIBCO MDM manages the master data of the enterprises across different tables in the database. Tomanage the data in the database, create individual data files for all the large tables and their indexes.

Create all the indexes including unique and primary keys for each large table in a separate data file.

Create separate data files for the following tables and their associated indexes.

● Master Catalog Table (MCT)● MV_SHARED Tables for different data types● MV Non Shared Tables (MVT)● Relationship Attribute Tables (RCT)● GOLDENCOPY● PRINCIPALKEY● PROCESSLOG● PRODUCTKEY● PRODUCTLOG● RELATIONSHIPOut-of-the-box scripts are used for the following actions:

● Create filegroups● Add data files in filegroups● Move tables or indexes● Delete data filesFor additional information, contact the engineering team.

Database Optimizations on Microsoft SQL Server - Customer StudyThe database optimization recommendations are based on the tuning that was carried out at one of ourcustomer sites.

For recommending Microsoft SQL performance optimization, start by running the SQL diagnosis,identify the bottlenecks, and then change any configuration changes to the Microsoft SQL server.

Follow the same approach in tuning the database at the customer location. Iteratively, TIBCO ran theSQLdiag utility and highlighted top bottlenecks and addressed the heavy input/output contentions onthe TEMPDB files common items first.

These configuration changes may or may not be applicable to other customers.

The following information lists some of the bottlenecks that TIBCO identified and fixed after runningthe Microsoft SQL diagnosis or Microsoft SQL profiler.

Heavy Input Output Contentions on TEMPDB FilesHeavy input/output contention on temp database was one of the bottlenecks that appeared in theanalysis.

Optimum TEMPDB configuration is important for any solution that has heavy data access as in the caseof TIBCO MDM. If you observe heavy TEMPDB input/outptut contention due to huge spikes on the

20


Microsoft SQL server CPU, check the TEMPDB file. The contention can occur even if there is only oneTEMPDB file.

If this is the case, you should consider increasing the number of TEMPDB files according to the initialdata access requirements and server configuration.

Although there is no convention on the number of files or size, TIBCO recommends having oneTEMPDB file per two CPUs with identical sizes.

Another factor to consider while configuring the TEMPDB files is the growth of each file. You can set thegrowth to auto-growth with a percentage of growth factor or to no auto-growth limit. A Microsoft bestpractice is to allow no auto-growth but you can also set an auto-growth of 300MB.

CXPACKET Wait-type Observed FrequentlyCXPACKET wait is another bottleneck TIBCO observed. This wait-type occurs when SQL serverspawns a single query on multiple worker threads.

The default maximum degree of parallelism (MAXDOP) is set to 0 which requires infinite workerthreads to execute the query. Microsoft recommends that you optimize the queries, however becausemost of these are product queries you may encounter limitations when optimizing some of them.

TIBCO recommends that you set the MAXDOP to 10. In our environment there were 32 physical CPUsand 40 CPUs with hyper-threading.

TIBCO also recommends setting the MAXDOP to 25% of the total number of available CPUs. TIBCOdecided that the MAXDOP set to 10 will allow the query to spawn across 25% of the total CPUs leavingthe remaining 75% available for other threads. If you allow one query to spawn across 100% of theCPUs it may cause CPU contention.

Lesser Dedicated Memory to Operating SystemTIBCO recommends allocating sufficient memory to the operating system. If the operating system isrunning on less dedicated memory it could become a bottleneck.

TIBCO also recommends increasing the memory dedicated to the operating system to a higher memoryallocation. A slow operating system may reflect on the database instances hosted. This may not bereflected in the SQL profiler report.

Incorrect Snapshot Isolation Level SettingsIt is important to setup the correct snapshot isolation level as recommended in the TIBCO MDMproduction documents. Even though this occurs in the earlier stages of the project, you should verifythis configuration in case of performance issues. As noted in the product documentation, the isolationlevel is set to READ_COMMIT.

File-GroupingTIBCO MDM product documents recommend creating various file-groups while setting up seed-data.However, depending on the data model and the solution, you should create several file-groups so thatthe larger entities are on separate file-groups.

This reduces the input/output contention on the same file group. You can decide if you need more filegroups by observing the file-group input/output in the SQL profiler. A Microsoft best practice is to limitthe number of file groups.

Refer to Data Files Configuration for more details.

Antivirus ConfigurationThe SQL server runs on a Windows operating system containing anti-virus software. TIBCOrecommends that you configure the anti-virus software to disallow some of the SQL server related filesto skip on-access scanning.

21


Lack of Indexes on MVT TablesTIBCO recommends that you include the recommended set of indexes on the MVT tables includingclustered indexes on CMODVERSION and CPRODUCTKEYID. TIBCO has addressed this product defect.

Query Optimization on Product QueriesThe SQL profiler report may also show top select statements that include heavy logical reads or thatconsume heavy CPU cycles. These can be external queries which may not be executed by TIBCO MDMbut communicate with TIBCO MDM. Based on regular observation, you may need to tune these typesof queries. You can contact TIBCO MDM engineering for more information.

Storage or IO ContentionSQL input/output test can highlight various storage or input/output related bottlenecks. Ensure thatthere are no fault disks which can cause a performance bottleneck.

Over-Aggressive Scheduled Maintenance Jobs

Over-Aggressive Backup Schedules

To avoid an over aggressive backup strategy TIBCO recommends the following strategy:

● Complete a full backup daily.

● Complete a differential backup once per hour.

These backup strategies not only cause performance issues but also cause high CPU and input/outpututilization. TIBCO recommends changing the scheduled maintenance activities to no incrementalbackups and full backup once a week.

There were improvements in the CPU and input/output utilization which in turn improvedperformance at the customer location.

Over-Aggressive T-Logs Backup

To avoid overhead, TIBCO recommends configuring the T-Log backup schedule to run every fourhours rather than every 15 minutes.

Over-Aggressive Reorganization and Rebuild of Indexes

To avoid overhead, set the schedule for the reorganization and rebuild of indexes to a weekly basisrather than every day.

Additional places to look at for performance issues include reviewing your network or the overallhardware configuration of the database server.

The information in this chapter is based on a recent experience at a customer site and this effort is anongoing activity.

22


EMS Configuration and Tuning

TIBCO MDM uses TIBCO EMS internally for proper functioning of the application. Minimalcustomization (pool sizes) is required for proper functioning of TIBCO MDM.

TIBCO MDM also uses some queues to exchange messages and events with external applications. Youcan set the pool size of the queues as well as for the individual members in the cluster.

The following figure shows how to set the pool size using Configurator (NodeID > Async TaskManagement):

Setting the Pool Size

You can set the pool size for Asynchronous and Workflow queues for each member in the cluster.

If the CPU on a TIBCO MDM instance is available, you can increase the pool size of asynchronousqueues of TIBCO MDM instances to increase the throughput.

23


Load Balancing

Load balancing is configured for distributing workloads across multiple TIBCO MDM instances,network links, central processing units, disk drives, or other resources. Load balancing optimizesresource use, maximizes throughput, minimizes response time, and avoids overload. Using multiplecomponents with load balancing instead of a single component increases overall throughput of thesystem.

Load Balancing

You can configure load balancing to replicate the member properties in the Configurator. Additionally,you can configure load balancing to start TIBCO MDM instances on the same machine or differentmachines referring to the same configuration file with a different Member ID. Since all the clustermembers would point to the same EMS queues, the load on the system would be distributed equally.This type of configuration optimizes resource use, maximizes throughput, minimizes response time,and avoids overload.

Use an Apache web server with mod_jk for HTTP load balancing with JBoss Application Server. Referto the JBoss Application Server documentation for the configurations.

24


Database Loader Tuning

The Database Loader utility addresses the need to import millions of records along with theirrelationships. To optimize the time involved to import a large number of records, validation is notperformed and workflows are not considered while importing records into a repository.

25


When to Use Database Loader

Database Loader provides fast loading of data with relationships and should be your preferred optionif you need to import large initial data in a single load with or without relationships.

Database Loader is faster because it does not include:

● Workflows

● Approval

● Validations

● Record history

● Named version

Use Database Loader when the imported data is clean, does not require any validation, and only forinitial versions. Data is mapped from data sources to input maps and imported as is.

Database Loader performance depends on the following factors:

● Database setup: database Loader performs bulk operations (mostly inserts, some updates anddeletes) therefore the larger the batch size, the more database resources it requires. If you cannotchange the database parameters, consider using smaller sets per import.

● Number and size of attributes: more attributes and larger attribute sizes take longer to import.

● Indexes on MCT tables: although you can create many indexes on MCT tables to facilitate searches,this slows down inserts and deletes. Determine if you really need these indexes and consider if youcan drop the indexes during the initial load.

● Number of records in a repository: a larger size means the database needs to work harder to insertand delete the records. To address this issue, ensure that the database advisors do not report anyproblems with file systems, segments, or table spaces. You can also partition your data.

● Partitioning strategy: verify how your indexes are partitioned and that your partitioning isappropriate and not causing slow inserts.

You cannot improve Database Loader performance by adding CPU or memory to TIBCO MDM orcache instances.

Performance Best Practices for Database Loader

To obtain optimum performance when using Database Loader, consider the following points:

● Create Indexes which are shipped with the product as part of Seed Data.

● Create Indexes on data source as mentioned in Data Source Indexes.

● Create separate tablespaces or datafiles for large TIBCO MDM tables and Indexes. For information,refer to Tablespaces Configuration and Database Optimizations on Microsoft SQL Server - CustomerStudy.

● Disable logging on the Oracle database for the following tables:

— MCT's

— Productkey

— Principalkey

— Relationship

— Goldencopy

26


— MVT

— RCT

Data Source IndexesWhen multiple data sources are joined in an import, and if the load sizes are huge, that is, 200 K,configuring indexes for data sources is helpful.

Indexes are created on the Data File (DF) tables for bulk loading scenarios.

Create the index file under: $MQ_COMMON_DIR\enterpriseinternalname\datasource\datasourcename.idx.Filename must match to the data source name. Indexes are created only whenuploading data source. Therefore, files must be created before the actual upload.

● Example 1

If the CID column of the DF_33969_37793_TAB data source table is mapped to PRODUCTID; andnot mapped to PRODUCTIDEXT, create an index file as UPPER("CID")

● Example 2

If the CID column of the DF_33969_37793_TAB data source table is mapped to PRODUCTID, andCEXT is mapped to PRODUCTIDEXT, create an index file as UPPER("CID"),UPPER("CEXT")

Data Source Upload LimitFor large loads (Database Loader and Import) in a single batch, increase the data source upload limit.The default limit is 10485760 bytes. You can set the limit from Configurator for the UI Operation onlyand not for the FileWatcher operation.

Data Source Upload Limit

● Set the limit to 1048576000 bytes (1000 MB).

● Zip the data source and upload it for larger loads.

For large loads, split the data to ensure the upload file size does not exceed 1 GB.

27


Import

Import is used in bulk loading of data with and without relationships. The Import utility addresses theneed to import millions of records along with their relationships. To optimize the time involved toimport a large number of records, validation is not performed and workflows are not considered whileimporting records into a repository.

Direct Load Import

Direct load import depends on the following factors:

● CPUs available for processing records in parallel: if the CPU resources on a TIBCO MDM instanceare available, you can increase the pool size of the asynchronous queue or the number of TIBCOMDM instances.

● Preloaded data: this has a pronounced impact when the data you are importing are modifications ofexisting records. Preloading does not noticeably improve the performance when you import newrecords.

● Database: the database insert performance could be a limiting factor. Insert performance dependson the number of indexes, the file system, and the partitioning strategy.

● Database parameters: TIBCO recommends that you review the Review advisories generated byOracle, SGA, and PGA focusing on sizing.

Performance Best Practices for Import

To obtain optimum performance when using import, consider the following points:

● Create Indexes on data source as mentioned in Data Source Indexes.

● Create separate tablespaces for each MDM tables and Indexes. For information, refer to TablespacesConfiguration and Database Optimizations on Microsoft SQL Server - Customer Study.

● If your load is large, TIBCO recommends splitting the load into smaller loads in the range of 500Kand using the Import utility to load the data.

● Disable logging on the Oracle database for the following tables:

— MCT's

— Productkey

— Principalkey

— Relationship

— Goldencopy

— MVT

— RCT

28


Rulebase Execution Optimization

Typically, rulebase execution on a single record executes quickly and is a light weight job. For the caseswhere the overall bundle size is big, rulebase execution on the complete bundle has been seen as acontributor to execution time and eventually throughput.

You can have more control over processing orders. You can define dependencies in rulebases and canutilize parallel execution within a bundle. With no dependencies to define, almost all records in abundle can be processed in parallel to optimize overall rulebase execution time.

The following are some of the directives introduced to have more control over rulebase execution andoptimization:

● Evaluate Parent First (parentFirst)

● Can Parallelize (parallelize)

● Can Skip If no Change (skipIfNoChange)

For example, updating one or few records from a bundle results into execution of rulebase on allrecords in a bundle. With proper dependencies defined, execution can be optimized by utilizingparallel execution. Additionally skipIfNoChange directive can be used to skip complete rulebaseexecution when the record is not modified.

The two following properties have been added at the constraints level for performance improvement:

● Parallelize

● Active

For example, if the parallelize flag is enabled, the constraint can be executed in parallel with otherconstraints in rulebase. Disabling the active flag will not evaluate the respective constraint.

For more information on release execution optimization, see the "Rulebase Execution Optimization"section in TIBCO MDM Studio Rulebase Designer User's Guide.

29


Workflow Execution

TIBCO MDM uses a workflow message to initiate any new processes and the messages are posted toJMS queues for processing. When the JMS queue receives a message, an event (associated with themessage) and a document are created from the message and stored in the distributed cache. The eventand document type and subtype (defined in the workflow manager configuration file) determine theexecution process.

Regular Workflow ProcessingA workflow is executed in the transactional mode.

● When the process is executed in transactional mode, TIBCO MDM persists the event to the databaseand the documents to the file system. The file name is associated with the event in the database. Theevent is then posted to a workflow queue for processing.

● The event type and subtype determine the workflows triggered for an event. The workflow readsthe message associated with the event from the file system and starts a new process. This file is themain input parameter to the workflow. Each workflow has a set of activities which in turn haveinput and output parameters.

● Activity state changes are stored to the database. Activities can generate documents (written to thefile system) that act as output parameters for that activity and input parameters to a subsequentactivity in the flow.

In-Memory Workflow ProcessingTIBCO MDM retrieves the workflow data from the cache. The workflow can run without persisting theworkflow state information when the workflow is executed in the in-memory mode.

The following object types are put in memory:

● Event

● EventDetails

● Process

● ProcessLog

● ProcessDetails

● ProcessState

● AttributeLog

● MLXMLDoc

Input and output parameters such as XML files are stored in memory and are not written to a disk.When a workflow is executed, the local cache manages the workflow states and documents.

Impact of In-Memory Workflows on UIThis section describes how the workflows impact the UI.

Checking Progress in the Event Log

● An event is not generated when a workflow is run as in-memory. In this case, you cannot checkevent details for operations triggered by an in-memory workflow. However, if you have configuredin-memory workflows that are persisted on success (for example, if you set the savestateonsucessproperty to true), and the event is generated, you can view the result in the Event Log after theworkflow has finished executing.

30


● Intermediate event logs are available if the workflow contains the CheckpointWorkflow activity,async subflow, spawn workflow activity, or if the activity suspends. If a workflow errors out, theentire Event Log is available for debugging.

● If a data source upload or an import operation triggers an in-memory workflow, the Check Progresslink (which you can use to track progress in case of regular workflows) redirects the event to anappropriate page with a message that the event is an in-memory operation.

Checking Progress of Records for Workflows Run In-Memory

If you add a record in-memory, you can check the success of the workflow by searching for the recordin the catalog or checking the record count in the catalog.

Record history does not contain any reference to events processed in-memory. The link to the event isdisabled and the event column shows a message in memory.

Regular Workflows versus In-Memory WorkflowsThe table compares and contrasts the regular workflow with the in-memory workflow.

Regular Workflows versus In-Memory Workflows

Regular Workflows In-Memory Workflows

During each activity execution, process states arepersisted to the database and distributed cache.

During each activity execution, process states arewritten to the local cache.

Input, output, and intermediate documents arepersisted to the file system.

Input, output, and intermediate documents aremaintained in the local cache.

Each activity is considered a transaction. The entire workflow (consisting of multipleactivities) is considered a transaction.

When a transaction is committed, all workflowchanges (process states, documents, and recordrelated data) in that activity are committed.

When a transaction is committed, record relateddata in the workflow is committed. If thesaveonsuccess flag is on, data from the localcache (process states, documents) is committed.

In-Memory Configuration through ConfiguratorYou can use Configurator to enable the In-memory workflows. The setting is available in the WorkflowSettings of the Advanced Configuration Outline.

To complete the In-memory configuration, add the name of the workflow you want to execute In-memory in Configurator. You can add the following two types of workflows:

● List of Workflows that run in-memory: the Value column of this property contains a pop-up dialogwhere you can enter the names of the workflows you want to run-in memory. Click the cross icon toremove a specified workflow from the in-memory execution.

● List of workflows that run in-memory and whose state needs to be persisted on success: the Valuecolumn of this property contains a pop-up dialog where you can enter the names of the workflowsyou want to run in-memory and persist to the database on success. Click the cross icon to remove aspecified workflow from the in-memory execution and database persistence.

The property is not hot deployable so you must restart the server after saving theconfiguration.

31


Workflow Settings

When to Use In-Memory Workflow ExecutionA boost in performance occurs when you use workflow execution and the throughput is two or threetimes better compared to the regular workflow execution mode.

In-memory is most effective if you eliminate the process state. You also save disk space on the database.

TIBCO does not recommend using in-memory workflow in development.

Additionally, there is an intermediate mode where workflows run in-memory and where the state ispersisted on success.

Workflow ConfigurationsYou can use the following configurations for web services tests under load for regular workflowexecution, in-memory workflow execution, and concurrent scenarios (involving UI, web services, andBulk Import Scenarios simultaneously).

The Web service request Validation property enables the inbound web service request validation. Theincoming request is validated according to the XML schema. This adds some overhead on theprocessing and the default value is set to false for performance. You can set this property throughConfigurator.

Web services Tests

These TIBCO MDM configurations vary according to the concurrent users accessing the system:

● Maximum concurrent http service count: This property sets the maximum count for a number ofHTTP threads (web services and HTTP) The default value is 20 and this property application serveris member-specific.

● Maximum concurrent webservice listener count: This property sets the maximum count for anumber of web services service listeners. The default value is 10 users and this property is memberspecific application server.

32


TIBCO MDM Configurations

Limitations for In-Memory WorkflowsDo not use the following activities for in-memory workflows:

● UploadData Source

● Purge

● ProcessServiceMessage

● ImportCatalog

● ImportClassificationScheme

● ReclassifyRecord

Additionally, in-memory workflows cannot be used in case of CIM2CIM. Mass update andsynchronization export are not supported in-memory.

33


Workflow Activity Parallelization

Asynchronous execution of activities provides numerous benefits including the ability to process datain batches and execute batches in parallel.

Activity parallelization works as follows:

1. A COMMAND in and out parameter is used to indicate run modes for the activity. This is an internalparameter and no configuration is needed. A null command indicates that the activity is executingfor the first time.

2. When the activity suspends, it sets the command to indicate the next step.

3. The workflow passes this command back to the activity when the activity restarts.

4. The activity initializes the run counters (these counters are stored in the ProcessDetail Table):

● Total number of records to be processed.● Initial counter for record processed as zero.● Hidden (with respect to the UI).

5. The activity initiates parallel batch processing and suspends.

6. The activity creates batches of the records to be processed and sends messages for each batch.

7. Each batch keeps track of the record/bundle count for the batch.

8. At the end of each batch, the processing batch increments the counters in an atomic operation.

9. Checks for restart. If total records processed matches the total records to be processed, a restartevent is sent.

10.Workflow manager restarts the workflow and initiates the suspended activity.

Activity Parallelization Configuration

The following properites are specified in Configurator (Initial Config > Basic > Optimization ):

Optimization Properties

Property Name Description Default Value

Records PerAsynchronous Call

(com.tibco.cim.optimization.recordsperasynccall)

Fine tunes the processing of records in batches.The records to be processed are grouped intoasynchronous batches and each batch wouldcontain the number of records configured. Thedefault value is 10 records per batch. A largervalue might provide performance improvementsin certain situations.

100

Records PerAsynchronous Call

(com.tibco.cim.optimization.bundlesperasynccall)

Defines how many groups of records (bundles)are allowed in one separate asynchronousprocessing batch. The default value is 20, settingthis value higher can lead to performanceimprovements in certain situations.

20

Override in the Activity

You can override the values by specifying the following parameters in the activity:

34


● <Parameter direction="in" name="RecordsPerAsyncCall" type="long" eval="constant">10</Parameter>

● <Parameter direction="in" name=“BundlesPerAsyncCall" type="long" eval="constant">10</Parameter>

Activity Timeout

It is possible that an activity takes too long to complete or does not correctly restart. In this case, theactivity timeouts. The activity must handle the timeout. This special timeout is pre-configured using adefault value:com.tibco.cim.optimization.parallelactivity.timeout (default value 24)

In most cases, the activity does not do anything other than setting the status to Timeout.

Asynch Call Queue

The application can initiate a task in the background using the Async call queue. An “asynchCall”queue is defined with appropriate senders and receivers.

● AsyncCallQueueSenderManager

● AsyncCallQueueReceiverManager

This configuration provides for a default async call listener which expects all async calls to pass thehandler. This handler must implement the IAsychCallable interface.

For example:public class AsyncCatalogImport implements IAsyncCallable{

This interface has a onAsyncCall method which is invoked by the listener.public void onAsyncCall( {System.out.println("Processing importData/processRelationship : "+importData+"/"+processRelationship+"onAsyncCall()...................."); process(); }

To initiate a call, create the AsynchCallable object, initialize it with the input parameter, and then sendit for async processing as follows:AsyncCaller.callAsync(object);//object is the asyncCallable object

35


Activity Parallelization WorkflowActivity Parallelization Workflow

Record Bundling OptimizationWhen a bundle of records is created, all related records are loaded into the bundle. If the bundle is toolarge, it takes a long time to load. You can redice the the time to display records.

● When a bundle is loaded for view/edit, it is validated to pre-configured depth.

● Every time a user navigates the bundle, the next level is processed.

● The default depth is set to 2.

● If any record is modified, and when a bundle is saved,

— All modified records are validated.

— Related records are validated to specified depth.

● The UI display changes to show only the specified depth.

● If the recordBundle has a large hierarchy, on the UI the loading/displaying of the bundle can becontrolled/restricted by the configuration.

● Custom Validations can be turned off or on during recordView.

Record Caching OptimizationOnly one record is added to cache when requested. Previously, when records were requested, theywere retrieved from the database and added to the cache.

Records can be preloaded into the cache when the server is restarted and at runtime when a record isrequested, it can be retrieved from the cache and returned. This is done by asynchronous messaging.

36


The message for a given Organization loads all PRODUCTKEYS into the cache. All records for a givenrepository and organization are loaded into the cache.

Processing of the PRODUCTKEY and records is done in the same message, that is, synchronously. If bothare required to be done in parallel, a new instance of the class needs to be added in theConfigValues.xml file, passing: catalogName=PRODUCTKEY and RECORD

in the second.OrganizationName=PRODUCTKEY and RECORD

in the second.<ConfValue description="The list of catalog/repository names for which the record data should be cached on startup. Specify a comma separated list. Example : MASTERCATALOG, TEST" isHotDeployable="false" listDefault="DEMO" name="Cache Preloader Catalog/Repository Name List" propname="com.tibco.cim.init.PreLoadManager.catalogName" sinceVersion="7.0" visibility="Advanced"> <ConfList> <ConfListString value="DEMO" /> </ConfList></ConfValue>

<ConfValue description="The list of organization names used to select catalogs/repositories for preloading on startup. This should correspond to catalog/repository names. Specify a comma separated list. Example : MYORG, TIBCOCIM" isHotDeployable="false" listDefault="TIBCOCIM" name="Cache Preloader Organization List" propname="com.tibco.cim.init.PreLoadManager.OrganizationName" sinceVersion="7.0" visibility="Advanced"> <ConfList> <ConfListString value="TIBCOCIM" /> </ConfList></ConfValue>

<ConfValue description="List of object types which should be cached on startup. Only the record (RECORD) and the key information of the record (PRODUCTKEY) are supported right now." isHotDeployable="false" listDefault="RECORD PRODUCTKEY" name="Cache Preloader Record Types" propname="com.tibco.cim.init.PreLoadManager.ObjectName" sinceVersion="7.0" visibility="All"> <ConfList> <ConfListString value="RECORD" /> <ConfListString value="PRODUCTKEY" /> </ConfList></ConfValue>

<ConfValue description="The list of input map names used to filer records for preloading on startup. Example : INPUTMAP1" isHotDeployable="false" listDefault="DEMO" name="Cache Preloader Input Map Name List" propname="com.tibco.cim.init.PreLoadManager.inputMapName" sinceVersion="7.1" visibility="All"> <ConfList> </ConfList></ConfValue>

If an inputmap is specified, records/productkeys for the data source related to that inputmap are loaded into the cache. <ConfValue description="The list of input map names where the record data should be cached on startup. Example : INPUTMAP1" isHotDeployable="false" listDefault="DEMO" name="Cache Preloader InputMap Name List" propname="com.tibco.cim.init.PreLoadManager.inputMapName" sinceVersion="7.1" visibility="All"> <ConfList> </ConfList></ConfValue>

Preloading can also be done through a utility ($MQ_HOME/bin/preload.sh or bat), when the server isrunning. The utility sends an asynchronous message to preload records and Productkeys per theconfiguration in the config file.

37


Preload

Use Preload to load important data quickly at startup and enhance TIBCO MDM performance. Preloaduses multiple threads across all nodes in the TIBCO MDM cluster.

You can preload the following objects:

● Product keys

● Records and record version numbers

● Synchronized records and synchronization logs

● Repository metadata

● Enterprise specific data such as Enterprise, organization, users, or roles

Preload configuration is common to the whole cluster and should not be configured as member specificproperties. To set up the preload, start Configurator and go to InitialConfig > Optimization.

Preload Optimization

Performance Best Practices for Preloading

These are some of the best practices to follow when you use Preload:

● Size the cache according to the requirements (number of records to be preloaded, size of records,percentage of synchronized records). Refer to TIBCO MDM Cache Calculation.

● Enable the preload tranche for preloading large volumes of data.

● Set preload tranche size high for preloading large volumes of data. Tranche enables quick loading ofthe data from a single repository by splitting the records of the repository in portions and initiatingthe load for each portion in parallel.

The tranche is set to 500000 in the performance lab for 35 million records preloading.

For more information on the preload properties, refer to the Configuring Preload Properties section inTIBCO System Administration.

38


Preloading is an asynch activity. After you initiate preloading, JMS messages are queued up on theASYNCH queue. An increase in the number of listeners or TIBCO MDM members increases theprocessing speed. Preloading also supports clustering.

Guidelines for SizingThe following information provides guidelines for sizing the cache appropriately based on the data tobe preloaded. It can vary the number of records and repositories, the size of records, metadatadefinition, synchronized records, and the objects to be preloaded.

Preload

The performance lab has four repositories with a fixed number of attributes. The preceding estimatesare only for RECORD,RECORDMAXMODVERSION, and PRODUCTKEY objects preloaded. For moreinformation, refer to TIBCO MDM Cache Calculation.

39


Purge

Purge, a data clean-up operation, removes the data from the database, cache, and text index unlike thelogical delete done in other delete operations. Purge enables you to keep only the required data andreduce the disk capacity required.

Use the command line to purge the following objects:

● Records● Repositories● Data sources● EventsTo trigger purge, use the command line utility $MQ_HOME/bin/datacleanup.sh.

For example, the command datacleanup.sh -o repository -a 69390 -rn ALL -m 20101 purges all recordsof all repositories in enterprise ID 69390 and member ID 20101.

The purge log file (located in $MQ_COMMON_DIR\Temp\Year\Month\Date\Hour) provides detailssuch as:

● Purge Start Date● Member who initiated the purge● Event Descriptor● Repository or the Repositories’ ID to which Purge is applicable.● Exec mode● Number of rows deleted● Number of records deleted● All relevant data

Performance Best Practices for Purge

These are some of the best practices to follow when you use Purge:

● Create or alter indexes on MATCHRESULTDETAILS, MATCHCANDIDATE_PTIDX1,MATCHCANDIDATEDETAILS_PTIDX1, MERGERESULT_PTIDX1, PRODUCTSTATUS,PRODUCTKEY, ACTIVITYRESULT and RELATIONSHIPDEFINITION tables.

Contact TIBCO Engineering team for the indexes scripts.● Resize the redo logs depending on the analysis of Automatic Workload Repository (AWR) reports.

Consider resizing the redo logs based on the Redo Size in AWR and the redo interval. Considerincreasing the size of redo logs and also the number of redo logs.

● Log file switch: for a 10 minute switch, the total redo log file size should be approximately 2.5 GB.This enables the log switch to occur in 12 to 15 minutes.

— Use the AWR report: Report Summary to calculate the required size.— Check Load Profile: Redo Size and take the per second size and calculate the required size for

12-15 minutes.— Next, check the assigned redo logs. You can increase the size of the logs and number of logs. If

the log file size is too large, the switch does not occur for some time and delays data recoveryand the data being written. If there are too many log files, multiple concurrent accesses aresupported but switches still occur.

40


— Consider moving the redo logs to faster disks to avoid log file switch delays.

— Set the size of the System Global Area (SGA) in Oracle, based on the recommendations inAutomatic Database Diagnostic Monitor (ADDM) reports.

41


Configuration for Logging

TIBCO MDM logs the entire request and response data in logs depending on the log level set for theapplication.

You can set the following logging levels for the TIBCO MDM server through Configurator:

● Debugging level for TIBCO MDM package

● MASSUPDATEUI package

● DQ package

● HeaderExtractor package

● Root logging level

In the following figure, the logging is set at an individual application server member:

Logging

Standard Logging Levels

You can set the following log levels through Configurator (NodeID > Logging > Standard Log):

● FATAL

● ERROR

● WARN

● INFO

● DEBUG

● Set the log level to DEBUG to debug functional issues as well as understand the flow.You should also set logging to DEBUG in the production environment in case youencounter errors and you need to debug the issue.

● Set the log level to ERROR for performance scenarios because logging set to DEBUG mayimpact performance by 15 percent.

Logging is hot deployable and you can change the logging level without restarting the TIBCO MDMserver.

42


Performance Tuning Tips

● If you have very large workflows, split them into smaller sub-flows.

● Reduce the workflow pool size (by setting the value forcom.tibco.cim.init.WmQueueReceiverManager.poolSize in the Configurator) to 1 if you haveless memory. However, the recommended maximum pool size is 4 to 6.

● Review validation rules. A review of all validation rules to simplify the logic will improve theperformance. With increased robustness of rulebase syntax, you may be able to reduce the time toview, validate and save records and optimize performance.

● Modify enumerated data lists. It is recommended that the enumerated data lists (for valid valuelists) be changed to use data sources. TIBCO MDM caches data sources, and this helps to improvedisplay time for the record view and edit screen. It is recommended to not to have the drop downlist longer than 100 choices.

● Reduce the revivify frequency. The revivify interval is used to time-out work items, and restart theworkflows for time out. When set to a high frequency, it slows down all aspects of TIBCO MDM.The revivify frequency should be reduced, as follows:

— Set to an interval of 20 hours (a value of 72,000,000).

● When using Oracle, caching a few tables in Oracle memory is recommended.

● Optimization and faster loading of the Relationship tab. The default value for the Rulebaseexecution on related records (com.tibco.ui.rulebase.processrelated.flag) property is set tofalse. This means rendering of the relationship tab will be delayed and only done when the uservisits the Relationship tab.

43


Date post:	12-May-2020
Category:	Documents
Upload:	others
View:	15 times
Download:	0 times

TIBCO® MDM Performance Tuning GuidePerformance Tuning Overview TIBCO MDM handles multiple functions...

Documents