Skip Headers

Agile Product Lifecycle Management Capacity Planning Guide Release 9.3.3 E39278-01 |
| Contents

Previous | Next |

# 2 Capacity Planning

This chapter helps you to plan and gauge server capacity.

## 2.1 Agile PLM Application Server

Agile PLM 9.3.3 supports Oracle WebLogic Server as the application server on Solaris, Linux, Windows and AIX operating systems.

To determine the application server capacity, the average Transactions per second (TPS) the server can support for a given Agile solution must be determined. For each solution, business scenarios were identified that users with different roles would perform daily. Based on these scenarios and the user distribution, the workload is designed per solution.

In the first phase, tests were conducted on individual solutions to determine the TPS. A single, 2 CPU Dual core application server supported an average three second response time.

The TPS for the Agile PLM solutions is as follows:

Solution | Transactions Per Second (TPS)
--- | ---
Product Collaboration (PC) | 19
Product Quality Management (PQM) | 19
Product Portfolio Management (PPM) | 16
Product Cost Management (PCM) | 12
Product Governance and Compliance (PGC) | 17

## 2.2 Java Heap Size Recommendations

Agile PLM began to support 64-bit JDKs for the application server component beginning with the 9.3.1.0 release. It is strongly recommended that you use a 64-bit JDK for the application server component, because it allows you to configure the heap size for the Java Virtual Machine to be higher than that of a 32-bit JDK. The table below lists the default heap sizes configured by the Agile PLM installer, as well as heap sizing recommendations when using a 64-bit JDK.

Note: When deploying an Agile PLM application server on Windows, use of a 64-bit JDK for the application server is STRONGLY RECOMMENDED due to the heap size constraint of the 32-bit JDK on the Windows platform.

Note: The heap size recommendations below apply to JVMs running the core Agile PLM application. There is no need to alter the heap settings for the Agile PLM File Manager or the WebLogic Admin Server components.

Recommended Settings (Installer Defaults)

Configuration | Heap Size (min=max) | MaxPermSize | NewSize | MaxNewSize
Unix/Linux (64-bit JDK 7) | 3072m | 512m | 1300m | 1300m
Windows (64-bit JDK 7) | 3072m | 512m | 1300m | 1300m
Unix/Linux (32-bit JDK 7) | 2048m | 256m | 256m | 256m
Windows (32-bit JDK 7) | 1280m | 256m | 256m | 256m

Note: For the Agile PLM application server component that runs in WebLogic Server, the JVM heap settings can be found in the shell script(s) that are used for starting up the application. These scripts have filenames that begin with "startAgile" and are located in the directory AGILE_HOME/agileDomain/bin. On Windows, the heap settings are also present in the service install scripts and you must uninstall and re-install the service to put a change into effect. Always back up the original file before making changes.

Note: The benchmark tests presented below were performed on 64-bit operating systems using 64-bit JVMs with a 3 GB (min=max) heap size. In general, the 64-bit JVM is perhaps 5% slower than the 32-bit JVM on a given platform but the 64-bit JVM allows for larger heap sizing that could result in improved stability in situations where the 32-bit JVM's maximum heap size is a constraint. This is especially true on Microsoft Windows Server with a 32-bit JVM where the maximum heap constraint of about 1.25 GB (1280m) also limits scalability. When deploying Agile PLM on Microsoft Windows Server, the 64-bit version with a 64-bit JVM is strongly recommended. Also, when configuring heap size, larger is not necessarily better. The best heap configuration is arguably the smallest heap size that can accomplish the task without heap thrashing. Therefore, for most deployments, a 3 GB (3072m) initial heap size is recommended (assumes 64-bit JDK).

## 2.3 Hardware Sizing

Agile conducts extensive load tests to determine scalability for individual product components, as well as for combinations of modules. Agile uses HP Load Runner 9.1 to simulate virtual user load for the benchmark tests.

To determine the required hardware for a given implementation, a number of factors must be considered. These factors are:

- Average user load

- Peak user load

- User distribution across different modules, if more than one module is implemented

- Network configuration

  - Latency

  - Bandwidth

The goal of hardware sizing is to balance hardware costs with user response times. To do this effectively, you need to accurately estimate and plan for both peak and average system load. Peak load is the load on the system during peak times. For example, users may access the system heavily between 9:00 AM and 10:00 AM, then again between 1:00 PM and 2:00 PM. Average load is determined by calculating load during all periods and averaging it.

If the peak load occurs on a regular basis, such as, daily or weekly, it would be ideal to configure and tune systems to meet the peak load requirements. Those users who access the application during non-peak times would experience better response times than the peak-time users. If peak load times are infrequent or do not deviate much from average load and higher response times during peak usage is acceptable, then the system can be configured and tuned to average load. This leads to a decrease in hardware investment at the cost of higher response times during infrequently high server load.

Another major factor that needs to be considered for hardware sizing is the average wait time between actions or clicks for a given user. The average wait time can vary from one second to 15 seconds to several minutes, depending on how the user uses the system. The user spends time on analyzing or reading data received between transactions and performing other tasks such as reading email, using the telephone, and chatting with a colleague. All of these actions contribute to the average wait time between actions performed in the Agile system.

The Transaction Processing Performance Council (`http://www.tpc.org`) that publishes the benchmarks for different applications, recommends a wait time of 7 to 70 seconds between subsequent actions. For sizing calculations, the average wait time must be considered. The lower the average wait time, the smaller the number of users the server can support.

### 2.3.1 Hardware Sizing for Exalogic/Exadata

Agile PLM on Oracle Exalogic (64-bit OS with 64-bit JVM)

The following table shows the recommended hardware sizing for Exa based on user load.

Processor Type and Speed | Number of Application Servers (JVMs) | Total Number of Cores (four cores per JVM) | Total Number of Users
Intel Xeon E5-2690 @ 2.90GHz | 1 | 4 | 400
Intel Xeon E5-2690 @ 2.90GHz | 2 | 8 | 720
Intel Xeon E5-2690 @ 2.90GHz | Add 1 Server with 4 cores for every 360 users. | 720+

Note: To support multiple application servers, clustering must be implemented, which adds an additional 10% load on each server.

Server Configuration by Processor Type

Processor Type and Speed | Server Model | Server Details
Intel Xeon E5-2690 @ 2.90GHz | Oracle Exalogic X3-2 | Intel Xeon Processor, 2 CPU - 16 Cores, 2.9 GHz, 32 GB RAM

### 2.3.2 Hardware Sizing for Linux

Agile PLM on Oracle Linux (64-bit OS with 64-bit JVM)

The following table shows the recommended hardware sizing for Linux based on user load.

Processor Type and Speed | Number of Application Servers (JVMs) | Total Number of Cores (four cores per JVM) | Total Number of Users
Intel Xeon E5-2690 @ 2.90GHz | 1 | 4 | 280
Intel Xeon E5-2690 @ 2.90GHz | 2 | 8 | 500
Intel Xeon E5-2690 @ 2.90GHz | Add 1 Server with 4 cores for every 250 users. | 500+

Note: To support multiple application servers, clustering must be implemented, which adds an additional 10% load on each server.

Server Configuration by Processor Type

Processor Type and Speed | Server Model | Server Details
Intel Xeon E5-2690 @ 2.90GHz | Sun Server X3-2L | Intel Xeon Processor, 2 CPU - 16 Cores, 2.9 GHz, 32 GB RAM

### 2.3.3 Hardware Sizing for Windows

Agile PLM on Microsoft Windows Server (64-bit OS with 64-bit JVM)

The following table shows the recommended hardware sizing for Windows based on user load.

Processor Type and Speed | Number of Application Servers (JVMs) | Total Number of Cores (four cores per JVM) | Total Number of Users
Intel Xeon E5-2690 @ 2.90GHz | 1 | 4 | 280
Intel Xeon E5-2690 @ 2.90GHz | 2 | 8 | 500
Intel Xeon E5-2690 @ 2.90GHz | Add 1 Server with 4 cores for every 250 users. | 500+

Note: To support multiple application servers, clustering must be implemented, which adds an additional 10% load on each server.

Server Configuration by Processor Type

Processor Type and Speed | Server Model | Server Details
Intel Xeon E5-2690 @ 2.90GHz | Sun Server X3-2L | Intel Xeon Processor, 2 CPU - 16 Cores, 2.9 GHz, 32 GB RAM

### 2.3.4 Hardware Sizing for Solaris

Agile PLM on Sun Solaris x86-64 (64-bit OS with 64-bit JVM)

The following table shows the recommended hardware sizing for Solaris based on user load.

Processor Type and Speed | Number of Application Servers (JVMs) | Total Number of Cores (four cores per JVM) | Total Number of Users
Intel Xeon E5-2690 @ 2.90GHz | 1 | 4 | 280
Intel Xeon E5-2690 @ 2.90GHz | 2 | 8 | 500
Intel Xeon E5-2690 @ 2.90GHz | Add 1 Server with 4 cores for every 250 users. | 500+

Note: To support multiple application servers, clustering must be implemented, which adds an additional 10% load on each server.

Server Configuration by Processor Type

Processor Type and Speed | Server Model | Server Details
Intel Xeon E5-2690 @ 2.90GHz | Sun Server X3-2L | Intel Xeon Processor, 2 CPU - 16 Cores, 2.9 GHz, 32 GB RAM

Agile PLM on Sun Solaris SPARC64 (64-bit OS with 64-bit JVM)

The following table shows the recommended hardware sizing for Solaris based on user load.

Processor Type and Speed | Number of Application Servers (JVMs) | Total Number of Cores (four cores per JVM) | Number of Users*
--- | --- | --- | ---
SPARC T5 @ 3.6GHz | 1 | 4 | 260
SPARC T5 @ 3.6GHz | 2 | 8 | 470
SPARC T5 @ 3.6GHz | Add 1 Server with 4 cores for every 235 users. | 170+
Note: To support multiple application servers, clustering must be implemented, which adds an additional 10% load on each server. *Note: these results were achieved using the following JVM parameters: -ms3072M -mx3072M -XX:PermSize=512M -XX:MaxPermSize=512M -XX:NewSize=1300M -XX:MaxNewSize=1300M -XX:+UseCompressedOops -XX:+AlwaysPreTouch -XX:+UseTLAB -XX:+AggressiveOpts -XX:SurvivorRatio=6 -XX:TargetSurvivorRatio=90 -XX:+UseParallelGC -XX:ParallelGCThreads=16 -XX:+UseLargePages -XX:LargePageSizeInBytes=256M

Server Configuration by Processor Type

Processor Type and Speed | Server Model | Server Details
SPARC T5 @ 3.6GHz | Oracle SPARC T5-2 | SPARC T5-2 Processor, 2 CPU - 16 Cores, 3.6 GHz, 512 GB RAM

### 2.3.5 Hardware Sizing for AIX

Agile PLM on IBM AIX (64-bit OS with 64-bit JVM)

The following table shows the recommended hardware sizing for AIX based on user load.

Processor Type and Speed | Number of Application Servers (JVMs) | Total Number of Cores (four cores per JVM) | Total Number of Users
IBM POWER7 @ 3.86 GHz | 1 | 4 | 320
IBM POWER7 @ 3.86 GHz | 2 | 8 | 570
IBM POWER7 @ 3.86 GHz | Add 1 Server with 4 cores for every 285 users. | 570+

Note: To support multiple application servers, clustering must be implemented, which adds an additional 10% load on each server.

Server Configuration by Processor Type

Processor Type and Speed | Server Model | Server Details
IBM POWER7 @ 3.86 GHz | IBM Power 780 | 4 CPU - 16 Cores, 32 GB RAM

## 2.4 Database Server Sizing

For production environments, it is recommended to run the database server on dedicated hardware. Database hardware sizing is dependent on both concurrent usage and the amount of data or size of the database. The best measure of database size is schema dump file size and estimated monthly incremental increases. Exporting the Agile schema at periodic intervals and analyzing its size helps you determine if a larger database sizing model is needed to better manage database growth, as well as minimize ongoing database maintenance and tuning.

### 2.4.1 Oracle Database Sizing

For existing Agile customers, getting the initial dump file size as a baseline is easy. For new customers, the dump file size needs to be estimated. If there is an existing database, use the Oracle Export Utility to verify the dump file size. If there is no existing database to reference, the size of the database needs to be estimated by monitoring database growth over the first few months of normal operation to predict future disk size needs.

The following tables show the Agile PLM 9.3.3 Database Sizing Matrix for Oracle.

Database Sizing Model:

- Small

Agile DB Configuration | Number of Users | CPU | RAM in GB | Disks
D | 1000 | 8 | 8 | 9
C | 500 | 4 | 4 | 4
B | 250 | 4 | 2 | 4
A | 100 | 2 | 1 | 4

- Medium

Agile DB Configuration | Number of Users | CPU | RAM in GB | Disks
D | 1000 | 12 | 12 | 9
C | 500 | 8 | 8 | 9
B | 250 | 4 | 4 | 4
A | 100 | 2 | 2 | 4

- Large

Agile DB Configuration | Number of Users | CPU | RAM in GB |
--- | --- | --- | --- | ---
D | 1000 | 16 | 16 | 13
C | 500 | 8 | 8 | 11
B | 250 | 4 | 4 | 9

- Extra Large

Agile DB Configuration | Number of Users | CPU | RAM in GB | Disks
D | 1000 | 24 | 24 | 15
C | 500 | 12 | 12 | 13

The following table shows the Oracle Database Sizing Model.

Size | Initial Dump File Size (MB) | Monthly Increment (MB)
--- | --- | ---
Small | < 1024 | <50
Medium (Regular) | < 5120 | <200
Large | < 16384 | <400
Extra Large | < 38912 | <1000

Each database sizing model requires an initial database configuration for deployment. For scalability and concurrency support, you need additional hardware resources, such as CPU, RAM, and number of disks.

#### 2.4.1.1 Small Database

The Agile PLM 9.3.3 small database sizing model can be used in a demo or test environment with the minimum hardware requirements. In a production environment, a small database (default) requires the settings of configuration A as an initial configuration. Configurations B, C, and D can be used for scalability and the addition of more concurrent users.

#### 2.4.1.2 Medium Database

The Agile PLM 9.3.3 medium database sizing model requires configuration A as an initial configuration with additional RAM. Configurations B, C, and D can be used for scalability and the addition of more concurrent users.

#### 2.4.1.3 Large Database

The Agile PLM 9.3.3 large database sizing model requires configuration B as an initial configuration. Configurations C and D can be used for scalability and the addition of more concurrent users.

#### 2.4.1.4 Extra-large Database

The Agile PLM 9.3.3 extra-large database sizing model requires configuration C as an initial configuration. Configuration D can be used for scalability and the addition of more concurrent users.

#### 2.4.1.5 CPU and Memory

As you can see from the sizing tables, the Agile PLM 9.3.3 database, CPU, and memory requirements are roughly the same as with previous versions of Agile. With further improvement on bind variables and optimization of SQL, memory resource should be primarily used for the DB cache (or buffer), which is directly proportional to the amount of data.

For servers running Windows, the minimum recommended CPU is an Intel 2.8 GHz Xeon with 512 KB L2 cache.

#### 2.4.1.6 Storage

It is recommended to start with a 4-disk configuration. The starting disk space requirement, 4x18GB=72GB, may seem quite large when comparing it to the size of the initial dump file, but considering the storage needs of the Agile PLM 9.3.3 features, including full text search, this may actually be on the low side.

#### 2.4.1.7 Network Card

The database should have a 100Mbps network card.

#### 2.4.1.8 Sizing Summary

RAM sizing is directly related to database size. Storage sizing should be based on the number of spindles. The Agile PLM 9.3.3 database utility can be used to optimize up to 15 separate disks.

### 2.4.2 Hardware Resource Plan for Database Models

The following table lists recommended hardware resources for different database size models.

Database Size | CPU | RAM | Disks *
--- | --- | --- | ---
Demo | 1 | 512 Mb | 1
Small | 2 | 1 Gb | 4
Medium | 2 | 2 Gb | 4
Large | 4 | 4 Gb | 8
Extra-Large | 12 | 8 Gb | 12

* Each disk has 18 Gb disk space.

### 2.4.3 Disk Space and Tablespace Configurations

While the proper sizing of extents minimizes dynamic extensions in the same segments, disk I/O contention within the same logical tablespace or physical data file can also be harmful.

You can improve disk I/O performance for multiple disk configurations by spreading the I/O burden across multiple disk devices. The following sections describe the use of multiple disks for the Oracle database server. It is always advisable to use more disks.

#### 2.4.3.1 One-Disk

A one-disk configuration can result in disk I/O contention when the storage device is a single physical disk. As both database size and usage increase, performance can decline significantly. A one-disk configuration is best for a demonstration, preproduction, and testing environment or where the database files are stored on a RAID array, SAN, or other storage subsystem with built-in striping and mirroring. The configuration can be implemented as shown in the table below.

The following table shows a one-disk configuration for OFA implementation.

Disk | Resource
--- | ---
Disk 1 | ORACLE_HOME SYSTEM TOOL UNDO TEMP USERS INDX AGILE_DATA1 AGILE_DATA2 AGILE_DATA3 AGILE_DATA4 AGILE_INDX1 AGILE_INDX2 AGILE_INDX3 AGILE_INDX4 LOG1 LOG2 LOG3 LOG4

There is no beneficial gain from OFA for the one-disk configuration from the perspective of disk I/O contention. There should be no significant impact on a current production database if you implement the default Oracle settings with a one-disk configuration.

#### 2.4.3.2 Two-Disk Configuration

A two-disk configuration is best for a small database. To eliminate potential I/O contention, AGILE_DATA and AGILE_INDX data files are on separate disks. As usage and database size increases, performance declines.

The following table shows a two-disk configuration for OFA implementation.

Disk | Resource
--- | ---
Disk 1 | ORACLE_HOME SYSTEM TOOL UNDO AGILE_DATA1 AGILE_DATA2 AGILE_DATA3 AGILE_DATA4 LOG1 LOG2
Disk 2 | TEMP USERS INDX AGILE_INDX1 AGILE_INDX2 AGILE_INDX3 AGILE_INDX4 LOG3 LOG4

#### 2.4.3.3 Four-Disk Configuration

A four-disk configuration is best for an enterprise-level implementation of Agile. A four-disk configuration spreads the various data files, control files, and redo log files across multiple disk devices.

- The three control files can be mirrored onto three different disks for best recovery protection.

- All potential I/O demand-intensive data files can be distributed onto their own separate disk. Redo log files are completely isolated from the rest of the data files, as the log files can cause significant I/O contention during transactions if they are sharing disks with other data files. The UNDO data file is separated from the schema data files and log files as well, so I/O contention can be minimized.

- The Agile schema tablespaces can be isolated from the rest of the SYSTEM, TEMP, TOOL, and UNDO data files.

The four-disk configuration shown in the table below is recommended. For production database sites, the four-disk configuration represents the minimum requirements for an OFA implementation and provides the minimum hardware configuration for performance tuning.

The following table shows a four-disk configuration for OFA implementation.

Disk | Resource
--- | ---
Disk 1 | ORACLE_HOME SYSTEM TOOL UNDO LOG1/2/3/4 Controlfile01
Disk 2 | TEMP USERS INDX Archive log file Controlfile02
Disk 3 | AGILE_DATA1 AGILE_DATA2 AGILE_DATA3 AGILE_DATA4 Controlfile03
Disk 4 | AGILE_INDX1 AGILE_INDX2 AGILE_INDX3 AGILE_INDX4

#### 2.4.3.4 Eight-Disk Configuration

In addition to the advantages associated with a four-disk configuration, an eight-disk configuration supports an enterprise-level implementation of Agile by further spreading various data files and redo log files across multiple disk devices.

Application schema can get additional performance gains in terms of I/O load spread by further separating the AGILE_DATA1, AGILE_DATA2, AGILE_DATA3, and AGILE_DATA4 and AGILE_INDX1, AGILE_INDX2, AGILE_INDX3 data files because of potential I/O contention between the AGILE_DATA data files and AGILE_INDX data files. A complete separation of potential large datafiles in its own disk spindle should help I/O contention as physical disk I/O is inevitable, due to the share size of data, as shown in the table below.

The following table shows an eight-disk configuration for OFA implementation.

Disk | Resource
--- | ---
Disk 1 | ORACLE_HOME SYSTEM TOOL UNDO LOG1/2/3/4 Controlfile01
Disk 2 | TEMP USERS INDX Archive log file Controlfile02
Disk 3 | AGILE_DATA1 Controlfile03
Disk 4 | AGILE_DATA2
Disk 5 | AGILE_DATA3
Disk 6 | AGILE_DATA4
Disk 7 | AGILE_INDX1 AGILE_INDX2
Disk 8 | AGILE_INDX3 AGILE_INDX4

#### 2.4.3.5 Twelve-Disk Configuration

Further separating the AGILE_DATA and AGILE_INDX tablespaces, twelve-disk configurations can be implemented as shown in the table below. This results in complete independent spindles for AGILE_DATA1, AGILE_DATA2, AGILE_DATA3, and AGILE_DATA4 and AGILE1_INDX, AGILE_INDX2, AGILE_INDX3, and AGILE_INDX4.

The following table shows a twelve-disk configuration for OFA implementation.

Disk | Resource
--- | ---
Disk 1 | ORACLE_HOME SYSTEM TOOL LOG1/2/3/4 Controlfile01
Disk 2 | USERS INDX Archive log file Controlfile02
Disk 3 | UNDO Controlfile03
Disk 4 | TEMP
Disk 5 | AGILE_DATA1
Disk 6 | AGILE_DATA2
Disk 7 | AGILE_DATA3
Disk 8 | AGILE_DATA4
Disk 9 | AGILE_INDX1
Disk 10 | AGILE_INDX2
Disk 11 | AGILE_INDX3
Disk12 | AGILE_INDX4

## 2.5 Hardware Load Balancer and Proxy Web Server

A load balancer or proxy web server is deployed to protect the application server. When external users need access to Agile, this device is deployed in the DMZ. The load balancer or proxy web server does not need to be installed in the DMZ if Agile is only accessed internally from within the corporate firewall.

Note: Load balancers can be used with the Java client and the Web client. Proxy web servers can only be used with the Web client.

Much like the application server, the dominant factor in determining hardware sizing for the proxy web servers is concurrent usage. Use the following table to determine the hardware needed for the web server tier.

The following table shows the web server sizing matrix.

Peak Logged In Users | Number of Servers | Number of CPUs | Memory (GB)
--- | --- | --- | ---
100 | 1 | 1 | 1
250 | 1 | 1 | 1
500 | 1 | 2 | 2
1000 | 2 | 2 | 2

### 2.5.1 CPU

For servers running Windows or Linux, the minimum recommended CPU is an Intel 2.8 GHz Xeon with 512 KB L2 cache.

### 2.5.2 Network Card

Each proxy web server should have a 100Mbps network card for up to 500 peak logged in users. For more than 500 logged in users, each server should have a 1Gbps network card.

## 2.6 Distributed File Management

The performance of Distributed File Management is a function of how many files are being downloaded or uploaded concurrently, along with how large the files are. A site handling up to 100 logged-in users requires a server with two CPUs running the processors previously mentioned and 2GB of RAM. File vault storage size is a function of the expected amount of data to be stored there.

## 2.7 AutoVue for Agile PLM

AutoVue for Agile PLM performance is a function of the number of files being viewed concurrently and the average file size being viewed. For the latest requirements, refer to the Oracle AutoVue OTN documentation site.

## 2.8 Events

The Events feature allows custom business logic, which is implemented as Java code or Groovy script, to be invoked as part of PLM actions. This feature is a powerful capability that enables you to do validation, auto-populate attributes, and automate dependent tasks.

Enabling events, processing event subscriptions, and executing the handler with custom logic triggers additional processing by the server as part of the PLM action, which consequently impacts throughput and response times. The actual impact depends on the number of events enabled, the number of handlers registered for the enabled events, and the amount of computing done by the handler.

Internal tests done with a simple handler enabled for every action in the system reduced overall throughput by 2.5% and slowed response times for individual actions up to 10%. These numbers, however, are for illustration purposes only. In reality, you will most likely enable only a subset of the events, but the handlers are likely to be more compute intensive than the test scenario. You should consider the additional computational load from events and adjust hardware sizing accordingly.