RSA Archer GRC

Sizing and Performance Guide

Platform 6.0
Contact Information
Go to the RSA corporate web site for regional Customer Support telephone and fax numbers:
http://www.emc.com/support/rsa/index.htm.

Trademarks
RSA, the RSA Logo, RSA Archer, RSA Archer Logo, and EMC are either registered trademarks or trademarks of EMC
Corporation ("EMC") in the United States and/or other countries. All other trademarks used herein are the property of their
respective owners. For a list of RSA trademarks, go to www.rsa.com/legal/trademarks_list.pdf.

License agreement
This software and the associated documentation are proprietary and confidential to EMC, are furnished under license, and may be
used and copied only in accordance with the terms of such license and with the inclusion of the copyright notice below. This
software and the documentation, and any copies thereof, may not be provided or otherwise made available to any other person.
No title to or ownership of the software or documentation or any intellectual property rights thereto is hereby transferred. Any
unauthorized use or reproduction of this software and the documentation may be subject to civil and/or criminal liability.
This software is subject to change without notice and should not be construed as a commitment by EMC.

Third-party licenses
This product may include software developed by parties other than RSA.

Note on encryption technologies

This product may contain encryption technology. Many countries prohibit or restrict the use, import, or export of encryption
technologies, and current use, import, and export regulations should be followed when using, importing or exporting this product.

Note on Section 508 Compliance

The RSA Archer GRC is built on web technologies which can be used with assistive technologies, such as screen readers,
magnifiers, and contrast tools. While these tools are not yet fully supported, RSA is committed to improving the experience of
users of these technologies as part of our ongoing product road map for the RSA Archer GRC.

Distribution
Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.
EMC believes the information in this publication is accurate as of its publication date. The information is subject to change
without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED "AS IS." EMC CORPORATION MAKES NO
REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS
PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.

2
Copyright © 2010-2016 EMC Corporation All Rights Reserved. Published in the USA.
RSA Archer GRC Sizing and Performance Guide

Contents

Preface...........................................................................................................................6
About This Guide ..............................................................................................................................6
Support and Service ..........................................................................................................................6
RSA Archer GRC Platform Documentation .....................................................................................7
Chapter 1: Architecture Overview..............................................................................9
Platform Architecture ........................................................................................................................9
Advanced Workflow Feature ..............................................................................................9
Deployment Options ....................................................................................................................... 10
Single-Host Deployment................................................................................................... 10
Multi-Host Deployment .................................................................................................... 10
High-Availability Multi-Host Deployment ....................................................................... 12
Chapter 2: Sizing Considerations ........................................................................... 14
System Complexity ......................................................................................................................... 14
Records ............................................................................................................................. 14
Users ................................................................................................................................. 15
Data Feeds ........................................................................................................................ 15
Advanced Workflow ......................................................................................................... 15
APIs .................................................................................................................................. 16
Platform Component Considerations .............................................................................................. 16
Web Servers ...................................................................................................................... 16
Services Servers ................................................................................................................ 17
Database Servers ............................................................................................................... 17
Chapter 3: Sizing Guidelines ................................................................................... 19
Very Small Single-Host Environment............................................................................................. 19
Small Single-Host Environment ..................................................................................................... 21
Small Environment ......................................................................................................................... 23
Database Server ................................................................................................................ 23
Web / Services Server ....................................................................................................... 24
Medium Environment ..................................................................................................................... 25
Database Server ................................................................................................................ 25
Web Servers ...................................................................................................................... 26
Services Server ................................................................................................................. 26

3
RSA Archer GRC Sizing and Performance Guide

Large Environment ......................................................................................................................... 27

Database Server ................................................................................................................ 27
Web Servers ...................................................................................................................... 28
Services Servers ................................................................................................................ 28
Very Large Environment ................................................................................................................ 29
Offline Access Laptop .................................................................................................................... 29
Disk Sizing ...................................................................................................................................... 30
Audit Logging ................................................................................................................................. 31
Chapter 4: Performance Considerations ............................................................... 33
Browser Choice ............................................................................................................................... 33
Asynchronous Jobs and the Job Engine .......................................................................................... 34
Peak User Load ............................................................................................................................... 34
Record Count .................................................................................................................................. 35
Database Best Practices .................................................................................................................. 35
Solution Design Best Practices ....................................................................................................... 36
High Availability ............................................................................................................................ 36
Fast Response Time ........................................................................................................................ 37
Database Encryption ....................................................................................................................... 37
Solutions in Use .............................................................................................................................. 37
File Attachments ............................................................................................................................. 38
Data Feeds ....................................................................................................................................... 39
Virtualization .................................................................................................................................. 39
External Vendor Interfaces ............................................................................................................. 40
Reverse Proxy ................................................................................................................... 40
Direct Mapping/Single Environment ................................................................................ 41
Custom Web Forms .......................................................................................................... 42
Two Separate Environments ............................................................................................. 43
Scalability Options .......................................................................................................................... 44
Vertical Scaling (Scaling up) ............................................................................................ 44
Horizontal Scaling (Scaling out) ....................................................................................... 44
Web Services API ........................................................................................................................... 44
REST API ....................................................................................................................................... 45
RSA Archer Mobile ........................................................................................................................ 45
BCM Mobile ................................................................................................................................... 45
Offline Access ................................................................................................................................. 45
Relationship Visualization .............................................................................................................. 46
IP Whitelist ..................................................................................................................................... 46

4
RSA Archer GRC Sizing and Performance Guide

In-line Editing ................................................................................................................................. 46

Caching ........................................................................................................................................... 46
Instrumentation Service .................................................................................................................. 46
Advanced Workflow Service .......................................................................................................... 46
Chapter 5: Job Engine Service Performance Considerations ............................ 48
Job Engine Service Performance Q&A ........................................................................................... 49
Job Engine Service Performance Testing Environments ................................................................ 50
Job Engine Service Performance Testing Results ........................................................................... 51
Job Engine Service Testing: Observations, Caveats, and Best Practices: ......................... 53
Appendix A: Sizing Quick Reference Chart........................................................... 54
Appendix B: Java Settings for Advanced Workflow ............................................ 56
Before you begin ............................................................................................................................. 56
JRE Memory Settings ..................................................................................................................... 56
JDBC Connection Pool Settings ..................................................................................................... 57

5
RSA Archer GRC Sizing and Performance Guide

Preface
About This Guide ............................................................................................................................................6
Support and Service ........................................................................................................................................6
RSA Archer GRC Platform Documentation ...................................................................................................7

About This Guide

This guide describes sizing and performance considerations for the RSA® Archer® GRC Platform. This
document is intended for system administrators who are responsible for installing and managing the GRC
Platform.

Support and Service

Customer Support Information www.emc.com/support/rsa/index.htm

Customer Support E-mail archersupport@rsa.com

Other Resources
RSA Archer GRC Community on RSA Link: Our public forum, on the new RSA Link Community
platform, brings together customers, prospects, consultants, RSA Archer GRC thought leaders, partners
and analysts to talk about GRC as a practice, and includes product demos, GRC videos, white papers,
blogs and more. https://community.rsa.com/community/products/ArcherGRC
RSA Archer Community on RSA Link: Our private community, is a powerful governance, risk and
compliance online network that promotes collaboration among Archer customers, partners, industry
analysts, and product experts. Engaging with the RSA Archer Community on RSA Link enables you to
collaborate to solve problems, build best practices, establish peer connections and engage with RSA
Archer GRC Thought Leaders. https://community.rsa.com/community/products/ArcherGRC
RSA Ready: RSA's Technology Partner Program is where 3rd parties gain access to RSA Software in
order to develop an interoperability and have it documented and certified. RSA Ready certifications are
posted to an online Community and supported by RSA Support.
https://community.rsa.com/community/products/rsa-ready

Preface 6
RSA Archer GRC Sizing and Performance Guide

RSA Archer GRC Platform Documentation

You can access the RSA Archer GRC documentation for Platform, Solutions, Applications, and Content
from the RSA Archer GRC Community on RSA Link.
https://community.rsa.com/community/products/ArcherGRC

Document Description

Release Notes Overview of the new and updated features in the release. A list of issues fixed in
the release and a list of issues known at the time of the release are also provided.
Available in PDF format.

Migration Guide Overview of the differences between RSA Archer GRC version 5.x and version
6.0. The differences that an administrator will encounter and a user will encounter
are discussed. Suggestions on planning for moving your users to 6.0 are included.
Available in PDF format.

Installation and Instructions for installing RSA Archer GRC 6.0, and upgrading from 5.x to
Upgrade Guide version 6.0. Available in PDF format.

Online All of the information for using RSA Archer GRC Platform and the Operational
Documentation Risk Management solution. A new holistic approach to the documentation
provides both Platform and solutions content in one searchable online system.
Available from within the product using context-sensitive links, as well as in a Zip
format for local installation.

Archer Control Information for managing the internal settings of the Platform, such as license
Panel (ACP) Online keys, global paths and settings. Available from within the ACP module.
Help

Web Services API List of the available web services for programmatically interfacing with RSA
Reference Help Archer GRC, in a searchable online system. Available in a Zip format for local
installation.

REST API List of the available resources for programmatically interfacing with the product
Reference Help through RESTful API calls to RSA Archer GRC, in a searchable online system.
Provides formatting guidelines for field results, field inputs, and search inputs;
provides sample code for searching, adding and updating users, and updating
assets. Available in a Zip format for local installation.

Security and Overview of the security configuration settings available in the RSA Archer GRC
Configuration Platform and the security best practices for using those setting to help ensure
Guide secure operation of the Platform. Available in PDF format.

Preface 7
RSA Archer GRC Sizing and Performance Guide

RSA continues to assess and improve the documentation. Check the RSA Archer GRC Community on
RSA Link for the latest documentation.

Preface 8
RSA Archer GRC Sizing and Performance Guide

Chapter 1: Architecture Overview

Platform Architecture ......................................................................................................................................9
Advanced Workflow Feature ............................................................................................................9
Deployment Options ..................................................................................................................................... 10
Single-Host Deployment ................................................................................................................. 10
Multi-Host Deployment .................................................................................................................. 10
High-Availability Multi-Host Deployment ..................................................................................... 12

Platform Architecture
The RSA Archer GRC Platform contains three software components that may be deployed on either a
single server or among a set of related servers. These components include the Web Application, Services,
and Instance Database. The GRC Platform also encompasses three server roles, which include the Web
Role, Services Role, and Database Role. The following figure introduces the iconography used to
illustrate how the platform software components relate to the server roles in the various installation
configuration diagrams shown throughout this document.

Advanced Workflow Feature

Advanced Workflow is a new feature in the 6.0 release of the RSA Archer GRC Platform. The Advanced
Workflow service needs to communicate locally with the Web Application. As a result, for 6.0, Advanced
Workflow functionality should be regarded as belonging to the Web Role, and any references to the Web
Role in this document encompass the new Advanced Workflow features.

Architecture Overview 9
RSA Archer GRC Sizing and Performance Guide

Deployment Options
Organizations can deploy the GRC Platform in a variety of configurations based on the expected user
load, utilization, and availability requirements. As business needs evolve, you can adapt and scale the
environment to meet the new demands.

Single-Host Deployment
A single-host configuration represents the simplest and least-complex type of environment to deploy and
maintain. With a single-host configuration, all of the key roles exist on one server. A single-host
configuration is well-suited for smaller organizations, or for GRC practitioners who need to quickly
deploy a basic environment for demonstration, training, development, or testing purposes.

Multi-Host Deployment
In a multi-host configuration, the Web Application, Services, and Instance Database components reside
on different servers. This configuration provides greater flexibility in terms of scalability because each
role can be scaled out separately.

For enhanced security, the multi-host configuration can incorporate a double-firewall. This configuration
places a firewall in front of the web server and one in front of services and database servers. For a list of
the ports used by different services, see the Security Configuration Guide in the RSA Archer GRC
Community on RSA Link.

For production multi-user environments, RSA recommends hosting the Instance Database component
separately on its own dedicated server, as is shown on the following diagram.

Architecture Overview 10
RSA Archer GRC Sizing and Performance Guide

The diagram below illustrates a multi-host configuration with the web, services, and database roles hosted
on separate servers. In this configuration, there are two servers serving in the Web Role, two in the
Services Role, and one in the Database Role.

Architecture Overview 11
RSA Archer GRC Sizing and Performance Guide

The following diagram illustrates a multi-host configuration in which one server runs only the web
application, one server runs both the web application and services, and the instance database is hosted on
another server. In this configuration, one server performs the Web Role and Services Role, one server
performs only the Web Role, and the other only performs the Database Role.

High-Availability Multi-Host Deployment

For high-availability environments, it is possible to deploy a minimum of two web applications, two
services servers, and two database servers. Incoming http or https requests may be directed across the
web servers via a load balancer.

Architecture Overview 12
RSA Archer GRC Sizing and Performance Guide

The following diagram illustrates a high-availability, multi-host configuration:

To improve availability in the event of a database failure, the GRC Platform supports a number of high-
availability options such as failover clustering, availability groups, database mirroring, log shipping,
and replication. For more information on high-availability options, go to the following article from
MSDN: http://msdn.microsoft.com/en-us/library/ms190202.aspx

Architecture Overview 13
RSA Archer GRC Sizing and Performance Guide

Chapter 2: Sizing Considerations

This chapter provides the information you will need to determine sizing requirements. It includes
guidelines for identifying any special use case and/or unique requirements specific to the desired
deployment. If any of the requirements fall under the “Very Large” deployment type, contact your RSA
sales representative for additional sizing assistance.

System Complexity ....................................................................................................................................... 14

Records ........................................................................................................................................... 14
Users ............................................................................................................................................... 15
Data Feeds ....................................................................................................................................... 15
Advanced Workflow ....................................................................................................................... 15
APIs ................................................................................................................................................ 16
Platform Component Considerations ............................................................................................................ 16
Web Servers .................................................................................................................................... 16
Services Servers .............................................................................................................................. 17
Database Servers ............................................................................................................................. 17

System Complexity
The GRC Platform complexity can vary based on several factors, including, but not limited to, the
number of content records, complex keys, calculations, Advanced Workflow processes, and data driven
events, as well as the number of parent, child, and sub-form mappings. Your deployment size may vary
depending on the complexity of the data feeds and the number of jobs to be processed to support the
needs of the business. The GRC Platform performs better when you size the system resources
appropriately.

The following deployment categories are based on number of content records, number of concurrent
users, number of data feeds, and number of applications with Advanced Workflow processes enabled.
The number of concurrent users refers to the number of users simultaneously logged in to the GRC
Platform who are actively performing an action that accesses or modifies data.

Records
The following table provides the recommended record capacity based on deployment size.

Size Number of Content Records

Small Deployment Less than 100,000

Medium Deployment 100,000 to 250,000

Large Deployment 250,000 to 750,000

Sizing Considerations 14
RSA Archer GRC Sizing and Performance Guide

Size Number of Content Records

Very Large Deployment More than 750,000

Users
The following table provides the recommended user capacity based on deployment size.

Size Number of Concurrent Users

Small Deployment Up to 100

Medium Deployment 100 to 250

Large Deployment 250 to 750

Very Large Deployment More than 750

Data Feeds
The following table provides the recommended capacities for various deployment sizes based on the
number of significant data feeds. Significant data feeds are those that run for at least an hour and which
affect thousands of content records.

Size Number of Significant Data Feeds

Small Deployment 1 to 2

Medium Deployment 3 to 5

Large Deployment 6 to 9

Very Large Deployment 10 or more

Important: If your deployment meets the criteria of a very large deployment for any of the categories,
contact your RSA sales representative for additional hardware sizing assistance.

Advanced Workflow
The following table provides recommended capacities for various deployment sizes based on the number
of applications with Advanced Workflow processes enabled. The numbers shown assume the Advanced
Workflow processes are of moderate complexity.

Sizing Considerations 15
RSA Archer GRC Sizing and Performance Guide

Size Number of Applications Enabled for Advanced Workflow

Small Deployment 0

Medium Deployment 1 to 4

Large Deployment 5 to 9

Very Large Deployment 10 or more

Important: If your deployment meets the criteria of a very large deployment for any of the categories,
contact your RSA sales representative for additional hardware sizing assistance.

APIs
The Web Services API and REST API have a very small impact on server performance and are exposed
via the same web server with which end users will interact. No additional hardware allocation is
necessary for installations.

Platform Component Considerations

Web Servers
When planning the configuration of the web server, consider the following:

 The recommended configuration for the web server varies depending on the number of concurrent
users, the activities of those users, and the amount of data stored on the GRC Platform.

 If the environment heavily uses services or shared storage, RSA recommends dedicating more than one
services server.

 When there are multiple web servers, a network share that is accessible to all web and services servers
is required to store keyword search indexes, document repository, and appearance files. For security
purposes, RSA recommends that the network share be hosted on a dedicated file server outside of a
web or services server.

 For more details, see the “Pre-Installation Process” section in the RSA Archer GRC Platform
Installation and Upgrade Guide in the RSA Archer GRC Community on RSA Link.

 For additional recommendations for disk sizing, see Disk Sizing.

 HTTP compression is enabled by default. If using a load balancer, RSA recommends disabling HTTP
compression from the Web Servers and to configure HTTP compression to occur on the load balancer.

Sizing Considerations 16
RSA Archer GRC Sizing and Performance Guide

 For web servers, RSA recommends a RAID5 or RAID10 array spanning four or more 10K or 15K
RPM spindles or an attachment to a storage area network (SAN) logical unit number (LUN).

Services Servers
When planning the configuration of the services server, consider the frequency, scope, and volume of
the following activities:

 Data Feeds

 Transactions involving creation and deletion of both Content and Metadata

 Notifications

 Calculations

 Packages

 Search Indexes

 LDAP Synchronization

 Offline Access Synchronization

 Other asynchronous Job Engine activities

For more information, see Job Engine Performance Considerations.

Database Servers
When planning the configuration of the database server, consider the following:

 Many clients choose to use SANs for database storage. However, be sure to create the SANs and
LUNs. Typically, requests for multiple LUNs are on the same set of spindles. These configurations are
not ideal and can counteract the performance advantages of the SAN. Use caution when making the
decision of SAN or Direct Attached Storage (DAS) to consider the use and abstraction of the SAN
environment.

 RSA recommends separating the volumes to store the SQL data, SQL Log, and TempDB components
because SQL Server produces one writer thread for each physical disk. While it is preferable to also
use separate spindle sets for each of these storage volumes, the separate writer thread improves
performance even though these components are on the same spindle set. Note that creating multiple
drive letters on the same physical disk does not allow SQL Server to produce multiple threads. The
components must appear to the GRC Platform as completely separate disks.

 RSA recommends RAID10 arrays with at least separate 15K RPM spindles, solid state drives (SSD),
or SSD-cached drives (e.g., EMC FAST Cache) for the SQL data, SQL log, and TempDB components.

Sizing Considerations 17
RSA Archer GRC Sizing and Performance Guide

 RSA recommends 64-bit versions of Windows Server and SQL Server. The 64-bit editions can access
up to 2 TB natively and can use that memory penalty-free for any operation the DBMS chooses. Even
on servers with less memory (e.g., 8 GB), the 64-bit editions provide access to all of that instead of just
a portion.

Sizing Considerations 18
RSA Archer GRC Sizing and Performance Guide

Chapter 3: Sizing Guidelines

The sizing metrics shown in this chapter represent the minimum recommendations. If any of the
requirements fall under the “Very Large” deployment type, contact your RSA sales representative for
additional sizing assistance.

Important: These sizing metrics are derived based on the performance tests conducted in the RSA lab
environment. Results may vary based on your environment setup and configuration.

Very Small Single-Host Environment ........................................................................................................... 19

Small Single-Host Environment .................................................................................................................... 21
Small Environment ........................................................................................................................................ 23
Database Server .............................................................................................................................. 23
Web / Services Server ..................................................................................................................... 24
Medium Environment.................................................................................................................................... 25
Database Server .............................................................................................................................. 25
Web Servers .................................................................................................................................... 26
Services Server ................................................................................................................................ 26
Large Environment ........................................................................................................................................ 27
Database Server .............................................................................................................................. 27
Web Servers .................................................................................................................................... 28
Services Servers .............................................................................................................................. 28
Very Large Environment ............................................................................................................................... 29
Offline Access Laptop ................................................................................................................................... 29
Disk Sizing .................................................................................................................................................... 30
Audit Logging ............................................................................................................................................... 31

Very Small Single-Host Environment

The following specifications should be regarded as the minimum requirements for a very small single-host
environment. In this configuration, the Web, Services, and Database layers are hosted together on the same
server. This environment is suitable for development work, basic functionality testing, or demonstration
purposes, but not as a production environment.

 Up to ten (10) concurrent users.

 One (1) Archer instance.

 Do not require a high-performance or high-availability solution.

 Have fewer than 75,000 content records.

Sizing Guidelines 19
RSA Archer GRC Sizing and Performance Guide

 10,000 or fewer new content records added per year.

The recommended system requirements may vary based on the number of concurrent users and the
amount of data stored in the GRC Platform database.

The following table lists the minimum recommended specifications for various hardware and software
components.

Component Single Server Configuration

Processor At least 2 total processor cores (note that Hyper threading

technology does not count as two cores).

Operating System Windows Server 2012 or Windows Server 2012 R2

Memory At least 8 GB RAM

Disk Space Required: 50 GB

Recommended: 100 GB
Network Interface 1 Gbps

Video SVGA compatible (1280x1024) (for installer and RSA

Archer Control Panel)
DB Version SQL Server 2012 or SQL Server 2014
X64 editions of SQL Server recommended
Dedicated system No

Disk File System Formatted to NTFS

SQL Server Mixed Mode Authentication Mixed mode enabled

Administrator account
SQL Server Memory Settings 1/2 to 2/3 of system memory

Data Files (SQL) If possible, the SQL Server data files should be installed
on spindle set(s) separate from the Operating System
Other Requirements Administrator-level account

Required Services Microsoft SQL Server

Microsoft SQL Agent (to run the recommended scripts)

Sizing Guidelines 20
RSA Archer GRC Sizing and Performance Guide

Small Single-Host Environment

A small single-host configuration is the smallest environment specification for production work and
is suitable for organizations with:

 50 or fewer concurrent users.

 Up to three (3) Archer instances.

 Do not require a high-performance or high-availability solution.

 Have fewer than 75,000 content records.

 10,000 or fewer new content records added per year.

 Up to two (2) significant data feeds per day.

The recommended system requirements may vary based on the number of concurrent users and the
amount of data stored in the GRC Platform database.

The following table lists the minimum recommended specifications for various hardware and
software components.

Component Single Server Configuration

Processor At least 4 total processor cores (note that Hyper threading

technology does not count as two cores).
Operating System Windows Server 2012 or Windows Server 2012 R2
Memory At least 16 GB RAM
Disk Space Required: 50 GB
Recommended: 100 GB
Network Interface 1 Gbps
Video SVGA compatible (1280x1024) (for installer and RSA
Archer Control Panel)
DB Version SQL Server 2012 or SQL Server 2014
X64 editions of SQL Server recommended
Dedicated system Yes
Disk File System Formatted to NTFS
SQL Server Mixed Mode Authentication Mixed mode enabled
Administrator account
SQL Server Memory Settings 1/2 to 2/3 of system memory
Data Files (SQL) Installed on spindle set(s) separate from the Operating
System

Sizing Guidelines 21
RSA Archer GRC Sizing and Performance Guide

Component Single Server Configuration

Other Requirements Administrator-level account

Required Services Microsoft SQL Server
Microsoft SQL Agent (to run the recommended scripts)

Sizing Guidelines 22
RSA Archer GRC Sizing and Performance Guide

Small Environment
A small environment is suitable for organizations with the following requirements:

 Up to 100 concurrent users.

 Fewer than 100,000 content records.

 10,000 or fewer new content records added per year.

 Up to two (2) significant data feeds per day.

A small environment is comprised of one (1) database server and one (1) Web/Services server with the
following configurations:

Database Server
The following table lists the minimum requirements for the database server.

Component Minimum Recommended Configuration

Processor At least 4 total processor cores (note that Hyper threading technology
does not count as two cores).
Memory 16 GB RAM

Operating System Windows Server 2012 or Windows Server 2012 R2

DB Version SQL Server 2012 or SQL Server 2014

x64 editions of SQL Server recommended
Disk Space 50 GB (Instance databases)
2 GB (Configuration database)
Disks 15K spindles should be the minimum for the DB tier, though we
strongly recommend using a SAN with SSDs, either as regular
disks, caching (for example, EMC FAST Cache), or for automated
tiering. Distinct spindles for data, transaction logs, and tempdb are
a necessity if SSDs are not available.
Network Interface 1 Gbps

Important: For a system that supports a highly-available and fail-over system, you need two servers
with the above configuration servers as a SQL Server cluster.

Sizing Guidelines 23
RSA Archer GRC Sizing and Performance Guide

Web / Services Server

The following table lists the minimum sizing requirements for the servers hosting the Web Application
and Services components.

Component Minimum Recommended Configuration

Processor At least 4 total processor cores (note that Hyper threading technology does
not count as two cores).
Memory 16 GB RAM

Operating System Windows Server 2012 or Windows Server 2012 R2

Disk Space 50 GB

Network Interface 1 Gbps

Important: For a system that supports a high-available system, configure one more web servers with the
recommended specifications, and distribute the load between the web servers using a load balancer.

Sizing Guidelines 24
RSA Archer GRC Sizing and Performance Guide

Medium Environment
A medium environment is suitable for organizations with the following requirements:

 Up to 250 concurrent users.

 Fewer than 250,000 content records.

 20,000 or fewer new content records added per year.

 Up to five (5) significant data feeds per day.

 Up to four (4) applications with Advanced Workflow processes enabled.

A medium, environment is comprised of one (1) database server, two (2) web servers, and one (1)
services server with following configurations:

Database Server
The following table lists the minimum requirements for the database server.

Component Minimum Recommended Configuration

At least 8 total processor cores (note that Hyper threading technology

Processor
does not count as two cores

Memory 48 GB RAM

Operating System Windows Server 2012 or Windows Server 2012 R2

SQL Server 2012 or SQL Server 2014

DB Version
x64 editions of SQL Server recommended
250 GB (Instance databases)
Disk Space
2 GB (Configuration database)
Disks 15K spindles should be the minimum for the DB tier, though we
strongly recommend using a SAN with SSDs, either as regular disks,
caching (for example, EMC FAST Cache), or for automated tiering.
Distinct spindles for data, transaction logs, and tempdb are a
necessity if SSDs are not available.

Network Interface 1 Gbps

Important: For a system that supports a high-availability and fail-over system, you need two servers
with the recommended configured servers as a SQL Server cluster.

Sizing Guidelines 25
RSA Archer GRC Sizing and Performance Guide

Web Servers
The following table lists the minimum requirements for the Web Application.

Component Minimum Recommended Configuration

Processor At least 4 total processor cores (note that Hyper threading technology does not
count as two cores).
Memory 16 GB RAM

Operating System Windows Server 2012 or Windows Server 2012 R2

Disk Space 50 GB

Network Interface 1 Gbps

Services Server
The following table lists the minimum sizing requirements for the Services server.

Component Minimum Recommended Configuration

Processor At least 4 total processor cores (note that Hyper threading technology does not
count as two cores).
Memory 16 GB RAM

Operating System Windows Server 2012 or Windows Server 2012 R2

Disk Space 50 GB

Network Interface 1 Gbps

Sizing Guidelines 26
RSA Archer GRC Sizing and Performance Guide

Large Environment
A large environment is suitable for organizations with the following requirements:

 Up to 750 concurrent users.

 Fewer than 750,000 content records.

 50,000 or fewer new content records added per year.

 Up to nine (9) significant data feeds per day.

 Up to nine (9) applications with Advanced Workflow processes enabled.

A large environment is comprised of one (1) database server, four (4) web servers, and two (2) services
server with following configurations:

Database Server
The following table lists the minimum requirements for the database server.

Component Minimum Recommended Configuration

Processor At least 16 total processor cores (note that Hyper threading technology does
not count as two cores).
Memory 96 GB RAM

Operating System Windows Server 2012 or Windows Server 2012 R2

DB Version SQL Server 2012 or SQL Server 2014

x64 editions of SQL Server recommended
Disk Space 1 TB ( for 600K to 750K content records)
800 GB (for 400K to 600K content records)
600 GB (for 250K to 400K content records)
2 GB (Configuration database)
Disks 15K spindles should be the minimum for the DB tier, though using a SAN
with SSDs is strongly recommend, either as regular disks, caching (for
example, EMC FAST Cache), or for automated tiering. Distinct spindles
for data, transaction logs, and tempdb are a necessity if SSDs are not
available.
Network Interface 1 Gbps

Important: For a system that supports a high-availability and fail-over system, you need two servers
with the recommended configured servers as a SQL Server cluster.

Sizing Guidelines 27
RSA Archer GRC Sizing and Performance Guide

Web Servers
The following table lists the minimum sizing requirements for the Web Application.

Component Minimum Recommended Configuration

Processor At least 8 total processor cores (note that Hyper threading technology does not
count as two cores).
Memory 24 GB RAM

Operating System Windows Server 2012 or Windows Server 2012 R2

Disk Space 50 GB

Network Interface 1 Gbps

Services Servers
The following table lists the minimum sizing requirements for the Services server.

Component Minimum Recommended Configuration

Processor At least 8 total processor cores (note that Hyper threading technology does not
count as two cores).
Memory 24 GB RAM

Operating System Windows Server 2012 or Windows Server 2012 R2

Disk Space 50 GB

Network Interface 1 Gbps

Sizing Guidelines 28
RSA Archer GRC Sizing and Performance Guide

Very Large Environment

Contact your RSA sales representative for recommendations for the GRC Platform that supports more
than 750 concurrent users, more than 750,000 content records, more than four data feeds per day, or more
than ten applications with Advanced Workflow processes enabled.

Offline Access Laptop

The Archer Offline Access feature is intended for Auditors and other similar work roles which require
access to GRC Platform data while disconnected from the primary network. The core architecture of Offline
Access is roughly parallel to that of the GRC Platform itself, and as such, Offline Access requires a
relatively robust machine. The specifications below should be regarded as the minimum requirements for a
single-user mobile computer capable of running Offline Access, assuming that 1,000 or fewer content
records (including related content) are configured for synchronization to the laptop. System requirements
will be greater, in proportion to the actual number of content records (including related content)
configured for synchronization.

The following table lists the minimum recommended specifications for various hardware and
software components.

Component Single Server Configuration

Processor At least 2 total processor cores (note that Hyper threading technology does
not count as two cores).
Operating System Windows Server 2012 or Windows Server 2012 R2

Memory Minimum of 6 GB RAM

Disk Space Required: 50 GB

Recommended: 100 GB
Network Interface 1 Gbps

Video SVGA compatible (1280x1024) (for installer and RSA Archer Control
Panel)
DB Version SQL Server 2012 or SQL Server 2014
X64 editions of SQL Server recommended
Dedicated system No

Disk File System Formatted to NTFS

SQL Server Mixed Mode Mixed mode enabled

Authentication Administrator account
SQL Server Memory 1/2 to 2/3 of system memory
Settings

Sizing Guidelines 29
RSA Archer GRC Sizing and Performance Guide

Component Single Server Configuration

Data Files (SQL) If possible, the SQL Server data files should be installed on spindle
set(s) separate from the Operating System
Other Requirements Administrator-level account

Required Services Microsoft SQL Server

Microsoft SQL Agent (to run the recommended scripts)

Disk Sizing
The following table provides general disk space sizing guidelines.

Typical Expected
Files Stored Typical Size High-Usage Size
Annual Growth
Appearance files 1 to 20 MB 60 MB Zero to little

Search indexes 100 MB to 1 GB 4 GB 500 MB

Document repository 500 MB to 10 GB 10 to 50 GB Varies greatly

Database (data files 5 to 25 GB 150 GB Less than 25 GB

only)
Database (with full 40 to 100 GB 400 GB Varies greatly
recovery logging)

Actual disk usage requirements vary depending upon specific customer needs. In particular, the amount
of space required by the File Repository is highly dependent upon an individual use case. For example,
a customer who makes extensive use of large media files (such as high resolution photos) clearly
requires more disk space than a customer whose data content is mostly confined to small and simple
text. Also, with larger and more numerous files, the limitations of a slow disk subsystem will become
more apparent and may create a performance bottleneck. Finally, the system is negatively impacted if
any file storage area runs out of space.

Sizing Guidelines 30
RSA Archer GRC Sizing and Performance Guide

Audit Logging
Enabling the Audit Logging feature has implications for environment sizing. Audit Logging produces
traffic over a TCP/IP or UDP port, destined for a monitoring tool that can consume the syslog format
(for example, RSA Security Analytics). Audit Logging allows deep analysis and monitoring of activity
within the RSA Archer GRC Platform and thus each user transaction generates multiple log items. The
following list provides an estimate for the number of items logged based on typical user activity. The
numbers are reflective of a single user.

Type of Transaction Approximate # of Monitoring Tool Entries

Data Feed / Data Import 4 x # of items in source file

Logging into default workspace 240

Switching workspace 150

Display All 35

Advanced Search 40

View or Edit a Record 50

Lookup and Add a Cross Reference 55

Apply/Save 95

Delete a record 60

Execute a Search or Report 25

Modify Report 10

Save Report 55

Export Report 40

Print Record 15

Access Quick Links 35

Administrative Functions 50-60*

Sizing Guidelines 31
RSA Archer GRC Sizing and Performance Guide

*Average. Creating a simple questionnaire has a log entry rate of 500, but most administrative functions
are much smaller. Since few users typically perform administrative functions their impact is limited.

Audit Logging has a propensity to generate a large amount of network traffic between the servers an the
monitoring tool. Depending on retention policies, additional disk space for storing log data may be
required. Please consult the sizing documentation for the chosen monitoring tool to predict this storage
requirement based on an analysis of expected activities. For example, RSA Security Analytics requires
between 1/2kb and 2kb storage for each syslog message.

Audit Logging has no impact on the database server, but increases CPU utilization on the web and
services servers. In a large environment with hundreds of concurrent users CPU utilization could double.
If Audit Logging is required for a deployment, factor this into the hardware design and acquire
additional cores to ensure performance is acceptable. If the increased CPU usage does not cause
contention (for example, when adequate cores are available), there is no noticeable impact on end-user
page load times.

Sizing Guidelines 32
RSA Archer GRC Sizing and Performance Guide

Chapter 4: Performance Considerations

Common factors which may impact system performance are described below.

Browser Choice ............................................................................................................................................. 33

Asynchronous Jobs and the Job Engine ........................................................................................................ 34
Peak User Load ............................................................................................................................................. 34
Record Count................................................................................................................................................. 35
Database Best Practices ................................................................................................................................. 35
Solution Design Best Practices ...................................................................................................................... 36
High Availability ........................................................................................................................................... 36
Fast Response Time ...................................................................................................................................... 37
Database Encryption ..................................................................................................................................... 37
Solutions in Use ............................................................................................................................................ 37
File Attachments ........................................................................................................................................... 38
Data Feeds ..................................................................................................................................................... 39
Virtualization ................................................................................................................................................. 39
External Vendor Interfaces ............................................................................................................................ 40
Reverse Proxy ................................................................................................................................. 40
Direct Mapping/Single Environment .............................................................................................. 41
Custom Web Forms ........................................................................................................................ 42
Two Separate Environments ........................................................................................................... 43
Scalability Options ........................................................................................................................................ 44
Vertical Scaling (Scaling up) .......................................................................................................... 44
Horizontal Scaling (Scaling out) ..................................................................................................... 44
Web Services API ......................................................................................................................................... 44
REST API...................................................................................................................................................... 45
RSA Archer Mobile ...................................................................................................................................... 45
BCM Mobile ................................................................................................................................................. 45
Offline Access ............................................................................................................................................... 45
Relationship Visualization ............................................................................................................................ 46
IP Whitelist.................................................................................................................................................... 46
In-line Editing ............................................................................................................................................... 46
Caching ......................................................................................................................................................... 46
Instrumentation Service ................................................................................................................................. 46
Advanced Workflow Service ........................................................................................................................ 46

Performance Topics 33
RSA Archer GRC Sizing and Performance Guide

Browser Choice
For the 6.0 release, RSA recommends using Microsoft Internet Explorer version 11. For more
information on which browsers are supported for each version of the GRC Platform, see the RSA
Archer GRC Community on RSA Link.

Asynchronous Jobs and the Job Engine

The Job Engine is a Windows service that is part of the Services component. The Job Engine facilitates
the asynchronous execution of background routines such as notifications and cleanup tasks. Given the
nature of these types of tasks, you should expect some degree of latency. Some asynchronous jobs are
purely administrative, whereas others are directly related to the type of activity that users perform, for
example saving content.

Asynchronous jobs generated by user activity include recalculation jobs, notification jobs, and
CAST scorecard calculations. As the number of users increase, any Solution that heavily uses
notifications or calculations (including inherited record permissions) will generate more
asynchronous jobs.

If the Services servers become overwhelmed, causing jobs to become backed up, it may result in
stale data, and expected notifications being delayed, or both. Ensure ample resources are provided
for this type of installation.

If you expect to experience heavy Job Engine utilization, see Job Engine Performance Considerations.

Peak User Load

User load is critical to properly sizing the environment. When assessing the expected average user load,
ensure that the deployment is sized to handle the expected peak user loads.

Sizing metrics provided in the previous chapter assume that all users are logged in with an active session
and performing basic actions such as:

 Adding new content

 Updating existing content

 Viewing dashboards and iViews

 Browsing reports

If you encounter any performance issues, monitor the performance of the GRC Platform during the peak
user loads and consider the scaling up options. For more information on performance issues and
scalability options, see Scalability Options.

Certain user actions are more intensive than others. As a general rule, users who perform a significant
number of view, edit, and save activities cause less impact on system resources than users who browse
workspaces and dashboards. Exports are more resource-intensive than browsing workspaces and
dashboards.

Performance Topics 34
RSA Archer GRC Sizing and Performance Guide

In a typical day, user activity includes all three, with most activity associated with the lower impact type
of activity. If expected user activity does not match this profile, sizing adjustments might be required.

Record Count
Record count is one of the most critical aspects to consider when sizing the environment. Always keep the
short term and long term growth in perspective. If you anticipate a high influx of data, consider scaling up
the database and web servers. For more information on performance issues and scalability options, see
Scalability Options.

Database Best Practices

As data volume grows, an improperly configured or neglected database server can have a cumulative
negative impact on the overall performance of the RSA Archer GRC Platform. Proper SQL Server
maintenance and configuration settings are crucial.

RSA suggests that you implement the following RSA recommended best practices for SQL Server
maintenance and configuration:

 Run a currently supported version of Microsoft SQL Server, and use the most recent service pack from
Microsoft.

 Do not set Max Degree of Parallelism to the default value of 0. A value of 1 is generally appropriate
for a database server dedicated to the GRC Platform.

 Configure the GRC Platform database server for one tempdb data file per physical CPU core, up to a
maximum of 8 tempdb data files.

 Regular processes must be in place to back up both the GRC Platform instance database and the GRC
Platform Configuration database.

 Regular periodic processes must be in place to rebuild the GRC Platform instance database's indexes
and update statistics.

 Implement regular processes to manage the transaction log properly if the recovery model for the GRC
Platform instance database is not set to Simple.

 Set Auto Shrink for the GRC Platform instance database to False.

 Set Autogrowth for the data and log files of both the GRC Platform instance database and tempdb to
grow by absolute amounts (not percentages).

Additional documentation on how to apply these settings is available from the RSA Archer Community
and from the Customer Support team.

Performance Topics 35
RSA Archer GRC Sizing and Performance Guide

Solution Design Best Practices

When designing applications in the GRC Platform, administrators should be aware of the impact design
decisions can have on the end-user experience. Rather than limit the user, the GRC Platform can support
highly complicated solution designs, keeping in mind there may be a trade-off in terms of end-user
experience.

As a general rule the following choices may lead to degraded performance:

 Allowing N-tier searches over five or more levels

 Returning or exporting over 10,000 records

 Using more than seven filters in a report

 Displaying more than 500 fields in an application or questionnaire

 Displaying more than 10 root tabs, or 20 child tabs in an application or questionnaire

 Implementing more than 100 Data Driven Events (or more than 25 Apply Conditional Layout Data
Driven Events) in an application or questionnaire

 Using more than 10 record permissions fields in an application or using more than 20 inherited record
permission rules

 Allowing cross-reference or history log display grids to display every record slows load times in
certain records

 Setting cross-reference fields on records to return more than 20 fields or more than 500 records slows
the record lookup process

 In general, avoid placing a history log field on the cross-reference side of any relationship containing
large numbers of records; a better choice is on the related record side

 Adding Text Area Fields to application or questionnaire slows page load times

In isolation any of these options may be the right approach, but administrators should be aware of the
implications.

High Availability
To meet high-availability requirements, the GRC Platform web tier should run on multiple web servers
and use load balancer technology. In addition, shared, UNC-accessible storage locations may be
specified for:

 GRC Platform document repository

 Keyword search index files

Performance Topics 36
RSA Archer GRC Sizing and Performance Guide

 Appearance (company_files) files

High-availability is typically implemented using a pre-existing, highly-available network attached

storage (NAS) appliance/clustered file server. Keep in mind that keyword search index performance
may be slower if search indexes are stored on NAS as opposed to being stored locally.

Alternately, you may choose to create shares on one of the participating services servers, although this
option may not satisfy the requirements for high availability. If you choose this option, you should
upgrade the disk spindle speed and capacity for that server.

Several options are available for the database tier. A clustered configuration is generally recommended
due to industry prevalence, front-end configuration simplicity, and fast automatic fail-over. You can
also use other high-availability techniques, such as log shipping or native mirroring. Generally, you
can independently implement SQL Server high-availability practices in pre-existing environments.

Fast Response Time

Some actions require more time than others. Viewing a record should be quicker than executing a large
search or report, saving a record, or viewing a workspace with numerous report-based iViews. The
simplest method to increase response time is to use higher-end current-generation processors. Also,
disk performance can play a large role. Using separate 15K RPM spindles, solid state drives (SSD), or
SSD-cached drives (e.g., EMC FAST Cache) may improve response times.

Database Encryption
You can encrypt the database using one of the following methods:

 Microsoft Encrypting File System (EFS)

 Transparent Data Encryption (TDE)

The additional overhead of encrypting the database causes a 5 to 30 percent loss of performance.
Generally, the overhead associated with TDE is less than with EFS. RSA suggests that you upgrade to
processors with higher clock speeds, more cores, and sufficiently fast disks.

Solutions in Use
Various RSA Archer GRC solutions place different demands on the environment. For example, in the
RSA Archer GRC Policy Management, users open and view a limited number of records in read-only
mode. As a result, this activity requires a less robust environment. In contrast, solutions with heavy write
and update activity, such as the RSA Archer GRC Incident Management Solution and the RSA Archer
GRC Enterprise Management Solution, require a more robust environment. In the RSA Archer GRC
Incident Management Solution, users frequently upload digital evidence to the document repository. In
the RSA Archer GRC Enterprise Management Solution, large amounts of records are typically
populated via automatic feed.

The following table provides general guidelines for the demands of each solution. However, ultimately
the demands on the GRC Platform will vary depending on your unique needs. If you anticipate using

Performance Topics 37
RSA Archer GRC Sizing and Performance Guide

many high and medium complex solutions, consider scaling up database and web servers with extra cores
and memory. For more information on performance issues and scalability options, see Scalability
Options.

RSA Archer GRC Solution Typical Impact Notes / Exceptions

Audit Management Medium

Authentication and Low / Medium Medium if running Archer-to-Archer Data

Authorization (Federal) Feeds
Business Continuity Low
Management
Compliance Management Low

Continuous Monitoring Low / Medium Medium if running Data Feeds

(Federal)
Enterprise Management High High if performing frequent imports/updates
of asset data
Enterprise Management High
(Federal)
Incident Management High High based on the inclusion of significant
digital evidence or a large number of incidents
Operational Risk Management Medium

Policy Management Low / High Typically low impact, but can temporarily
reach high when a new policy is introduced
and a high number of users access the solution
simultaneously.
Risk Management Medium

Threat Management Low / Medium Medium when running a threat intelligence

feed
Vendor Management Low

File Attachments
The number and types of file attachments can impact sizing guidance for the document repository
storage location. (This location is specified when an instance is added and can be changed using the
RSA Archer Control Panel. For more information, see the RSA Archer Control Panel Help.) RSA
suggests that you estimate your growth for the next one to three years.

Performance Topics 38
RSA Archer GRC Sizing and Performance Guide

Some types of file attachments can be indexed for keyword search, such as text, HTML, Word, and
PDF files. These files increase the size of the keyword search indexes and induce more load on the
Services server for maintaining the indexes. It is unlikely that high-indexing load alone would result in
a recommendation of splitting off the services processing tasks to a dedicated server. RSA suggests
splitting off services if there are other factors that also suggest high-services load.

Data Feeds
You may want to dedicate a server to the job engine under either of the following conditions:

 If more than eight data feeds are executed on a frequent basis

 When the data feeds process more than 50,000 records a day

This server should closely match the configuration of a web server, without the requirement to respond
to web requests from users.

Due to improved (and therefore more onerous) scrubbing of incoming text data to prevent cross-site
scripting attacks, data feeds that process a large number of text fields (or large strings into Text Area
fields) exhibit a slower throughput in GRC Platform Release 5.4 SP1 than in earlier versions.

Virtualization
Consider the following if you plan to implement virtualization for any of the servers in your RSA
Archer GRC Platform environment:

 Follow generally-accepted IT industry best practices for configuring, monitoring, and maintaining
virtual servers.

 Do not over-allocate the virtual machine host beyond 100% of its physical capacity.

 Leave at least 20% of the underlying host machine’s physical capacity available to absorb usage spikes
if you are virtualizing a database server.

 Use at least 24 GB RAM on dedicated VM host hardware for a large environment configuration. If
your virtual environment configuration does not support 24 GB RAM, consider adding more virtual
machines (VMs) to compensate the physical system configuration requirements.

 Multiple processor cores for the web server. Microsoft Hyper-V and VMware vSphere products are
capable of supporting four or more virtual processors in guest mode, but default to one. RSA
suggests adding at least one virtual processor (for a total of two or more) to virtualized environments
due to extensive multi-threading in the GRC Platform itself and by virtue of thread pooling by
running under ASP.NET.

 Setting resource reservations for processor and memory to ensure that those resources are always
available for the VMs running the GRC Platform. You can adjust the level of that reservation as
necessary.

Performance Topics 39
RSA Archer GRC Sizing and Performance Guide

 Dedicated spindles or a SAN are recommended to lessen the likelihood of this contention. As
permanent storage resources typically are shared across VMs, there is a much greater potential to
encounter disk or I/O contention issues as compared to a physical server.

External Vendor Interfaces

You can open up an external vendor interface to the GRC Platform using one of the following methods:

 Reverse Proxy

 Direct Mapping/Single Environment

 Custom Web Forms

 Two Separate Environments

Each method has distinct advantages and disadvantages.

RSA suggests implementing the reverse proxy option because it provides the cleanest, least
complicated solution, and requires only HTTP/HTTPS traffic to traverse the firewall.

Reverse Proxy
This method involves creating a reverse proxy in the DMZ to provide the external interface for users
outside the trusted network.

Advantages Disadvantages

 Lightweight  Requires a firewall rule for HTTP/HTTPS traffic to

pass from the external proxy server to the inside
 Does not allow direct access to server
GRC Platform servers
 Benefits from all flexibility and  May require some further security configuration
features present in the GRC changes if using Single Sign-On
Platform
 Integrated access control and
authentication mechanisms

Performance Topics 40
RSA Archer GRC Sizing and Performance Guide

The proxy then routes those requests to the internal server environment as shown in the following
diagram.

Direct Mapping/Single Environment

This method involves configuring the GRC Platform to be directly accessible to both external and
internal users, either in an internal, trusted environment, or in the DMZ.

Advantages Disadvantages

 Lightweight  Security concerns involving allowing direct access

to environment
 Typically better availability, since
establishing an HA environment
applies to all users, regardless of
source
 Benefits from all flexibility and
features present in the GRC
Platform
 Integrated access control and
authentication mechanisms

Performance Topics 41
RSA Archer GRC Sizing and Performance Guide

The following diagram illustrates an external vendor interface in a direct mapping in a single
environment:

Custom Web Forms

This method involves creating a custom web form that runs on an external web server. There is no
database back end. When a vendor submits the form, the data is sent to the internal instance via the
Web Services API.

Advantages Disadvantages

 Lightweight  Does not benefit from the GRC Platform access

control mechanisms
 Reasonably secure (only one port
needs to be opened up to allow the  Does not take advantage of the GRC Platform
external server to communicate feature set
with the Web Services API on the
internal instance)  Authentication can be a challenge

 Requires custom integration code

 Does not natively allow intermediate saves before

final form submission

 Form is static; changes require code modifications

to the external form

 Requires special provisions for file attachments

Performance Topics 42
RSA Archer GRC Sizing and Performance Guide

The following diagram illustrates an external vendor interface in a custom web forms environment:

Two Separate Environments

This method involves running two independent GRC Platform environments with separate SQL
databases. Vendors interact only with the external instance, and that information is transferred to the
internal instance of the GRC Platform.

There are a few forms of data transfer:

 Manual data export/import

 Automated submission upon record save

 Scheduled synchronizations

Both automated submission upon record save and scheduled synchronizations require an RSA
Professional Services engagement to create the custom data transportation component.

Advantages Disadvantages

 Highly secure (when using transfer option  Requires custom code for the sync
a) to reasonably secure (options b and c component or a user to manually
require only a single port) export/import data
 Draft stages available  Requires more robust external hardware
and requires a SQL database
 Benefits from all flexibility and features
present in the GRC Platform  Requires special provisions for file
attachments
 Integrated access control and
authentication mechanisms

Performance Topics 43
RSA Archer GRC Sizing and Performance Guide

The following diagram illustrates an external vendor interface in two separate environments:

Scalability Options
If you are experiencing performance issues or anticipating heavy system usage due to an inflow of a
significant number of content records or user activity, consider the scalability option.

 If the performance of the system is considerably low, monitor the utilization of the GRC Platform
resources.

 If one or more system resources are consistently over utilized, consider scaling the GRC Platform.

For example, if the overall system performance is low and the CPU utilization or Memory utilization is
consistently over 80%, it is worth investigating the scalability options. The GRC Platform requirements
can be scaled vertically or horizontally.

Vertical Scaling (Scaling up)

Vertical scaling involves adding additional resources, or upgrading resources on an existing system.
Vertical scaling is usually a good approach if the application bottlenecks are processor, memory and disk
related. This simple option can be cost-effective.

Horizontal Scaling (Scaling out)

For high-availability requirements, horizontal scaling is the better option. Adding additional web and
services server nodes is the best way to achieve required performance and scalability.

Web Services API

The Web Services API is another mechanism for loading data into the GRC Platform. This API is
designed for transactional integrations with other systems, rather than for bulk loading. During bulk
loading of data, it performs approximately 30% slower than a data feed. However, it has a lighter

Performance Topics 44
RSA Archer GRC Sizing and Performance Guide

resource footprint than running a data feed and will operate very effectively on smaller hardware than
is recommended elsewhere in this guide.

REST API
The REST API is another mechanism for loading data into the GRC Platform. The REST API call loads
records one at a time, but because of its extremely light network footprint, it can loop these calls in such a
way as to load very large quantities of data quickly. The REST API is called via an endpoint on any of the
web servers in a given deployment and has a minimal effect on any other users accessing the system at
the same time (save for the normal behavior around recalculations which any bulk load of data into the
system may trigger).

RSA Archer Mobile

The RSA Archer Mobile application communicates with the main RSA Archer GRC Platform
environment via a REST API, which is exposed on any of the web servers in a deployment. Having
mobile-enabled users syncing content to or from their devices causes some load on the system in two
places:

 Communicating with the web server over the API

 Processing of tasks related to preparing the data for downward sync in the Job Engine

Neither of these activities is resource intensive and a significant number of users can be enabled for
mobile off the main (or only) web server without any noticeable impact on the other users of the system.
Generally performance degradation was only observed when over 100 users were simultaneously syncing
data. Those anticipating a large enough rollout of the mobile app to create that level of concurrent sync
activities should allocate a separate web server instance to act as the API endpoint. The other precaution
to take is that the dependency for downward sync on the job engine means that environments with very
busy job servers may want to assess whether this will negatively impact their user’s experience.

BCM Mobile
The BCM Mobile application communicates with the main RSA Archer GRC Platform environment
through the Web Services API. BCM Mobile has no Job Engine jobs associated with it.

Offline Access
The Offline Access feature may have a moderate to heavy performance impact on both clients and servers
when the data synchronization actions between the RSA Archer GRC Platform and the remote devices
occur. The degree of impact for this feature is dependent on the complexity of the applications subject to
synchronization, the volume of content data within the synced applications, and the number of concurrent
users engaged in the synchronization process. Offline Access uses the REST API and Job Engine service
for upward and downward synchronization processes. Environments experiencing heavy Offline Access
usage may benefit from dedicating a Job Engine service server to Offline Sync activity.

Performance Topics 45
RSA Archer GRC Sizing and Performance Guide

Relationship Visualization
The Relationship Visualization feature provides the ability to display content relationships graphically.
This feature may have a minor impact on the performance of the server layer, and a minor to moderate
impact on the performance of the client layer. At the server layer, data retrieval time for visualized data is
proportional to the amount of related data associated with the element being visualized. Similarly, the
amount of time required to render visualization graphics on the client layer is also proportional to the
amount related data associated with the element being visualized. For the best user experience, be sure to
use an up-to-date and fully-supported web browser.

IP Whitelist
The IP Whitelist feature allows the GRC Platform administrator to limit access to the GRC Platform to a
specific list of known IP addresses. Testing revealed that this feature did not have a noteworthy impact on
the performance of the client or server layer.

In-line Editing
In-line editing is an interface feature that enables users to make changes to data content directly from
search pages. In-line editing can have a minor to moderate impact on the performance of both the client
and server layers, depending upon how many fields are returned in the underlying search pages and
whether Expand All is enabled.

Caching
The use of data caching software facilitates the reuse of commonly-requested datasets, thereby reducing
resource contention at the database layer. In particular, larger-scale environments that experience heavy
database-layer resource utilization may benefit from implementing caching. Correspondingly, larger-scale
environments often require higher-end hardware for the database layer if a data caching solution is not
present.

Instrumentation Service
When enabled, the Archer Instrumentation Service generates detailed runtime information about system
processes such as data feeds. As a best practice, do not configure the Instrumentation Service to use the
same database that is used for Archer Instance or Configuration data as doing so may cause the processes
to compete with each other for database resources. The Instrumentation Service and database are shared
among all Archer instances of a multi-instance environment.

Advanced Workflow Service

The Advanced Workflow Service communicates locally with the Archer Web application. This means the
Advanced Workflow Service must run on a host that is also running the Archer Web application.

The Advanced Workflow Service is a Java Runtime Edition (JRE) application which requires its own
allocation of physical memory. For a multi-instance installation, this memory allocation is shared among
the Archer instances of the installation. By default, the JRE memory allocation is set to a minimum of
1GB with a 2GB maximum. The default JRE memory settings should be sufficient for most

Performance Topics 46
RSA Archer GRC Sizing and Performance Guide

implementations and can be adjusted if necessary. See Appendix B: Java Settings for Advanced
Workflow for further details on these settings.

The Advanced Workflow Service connects to the SQL Server database through a pool of JDBC
connections. The default setting for the number of JDBC connection pools is 10 minimum and 200
maximum per Archer instance. The default JDBC connection pool settings can be adjusted if the expected
number of concurrent user connections for Advanced Workflow activities is expected to exceed 200. See
Appendix B: Java Settings for Advanced Workflow for further details on changing these settings.

The Advanced Workflow Service may take several minutes to finish starting after a service or system
restart. During startup time the CPUs of the machine hosting the Advanced Workflow Service may
experience a spike in activity while the Java runtime files are deployed.

Load balanced environments must allow HTTP_REQUEST traffic to use sticky sessions in order for
some of the Advanced Workflow administrative features to function properly.

New tables have been added to the Archer instance database to support Advanced Workflow
functionality. These tables contain metadata about workflow processes as well as transactional details
about enrolled content. Some of these tables may accumulate significant amounts of data, depending upon
the amount of Advanced Workflow activity occurring. By default, Advanced Workflow transactional
data associated with completed or canceled content records older than 30 days are automatically purged.
Administrators have the ability to change the Advanced Workflow data retention period.

Exercise caution when initiating data feed or data import actions against applications enabled for
Advanced Workflow as the Advanced Workflow transaction tables could accumulate data rapidly.
Depending upon individual use cases, it may be desirable to inactivate the target application’s Advanced
Workflow process in advance of a bulk data action, and then re-enable it afterwards.

Performance Topics 47
RSA Archer GRC Sizing and Performance Guide

Chapter 5: Job Engine Service Performance

Considerations
This chapter provides guidance for customers who have (or expect to have) relatively heavy
asynchronous job engine use and who are contemplating changes to the default Job Engine service
configuration settings for performance reasons.

This chapter contains the following sections:

Job Engine Service Performance Q&A ......................................................................................................... 49

Job Engine Service Performance Testing Environments ............................................................................... 50
Job Engine Service Performance Testing Results ......................................................................................... 51
Job Engine Service Testing: Observations, Caveats, and Best Practices: ....................................... 53

Smaller RSA Archer GRC Platform environments with less intensive workloads can be configured
with the Job Engine service running on the same server as the Web components. Under these
circumstances, the default Job Engine configuration settings provide an adequate degree of
asynchronous job throughput and acceptable job queue lengths

On the other hand, larger-scale RSA Archer GRC Platform environments with heavier workloads
can often yield performance improvements from modifying the default Job Engine service settings.
Separating the Job Engine service from the Web platform components may yield still further
performance improvements for larger-scale environments. In addition, it is possible to configure a
Job Engine server to be dedicated for a particular type (or subset) of activities, such as processing
Offline Access synchronization or notifications.

Chapter 5: Job Engine Service Performance Considerations 48

RSA Archer GRC Sizing and Performance Guide

Job Engine Service Performance Q&A

What are the most important resources to consider when configuring a Job Engine service
server?
Memory (RAM) is the most important resource for the Job Engine service, followed very closely by the
number of available CPU cores. Data Feed and Calculation jobs are most impacted by CPU and RAM
resources. Calculation jobs are mostly RAM-intensive, whereas Data Feeds (depending on how they are
designed) can be all-around resource consumers (memory, CPU, and disk i/o). Individual notifications are
not resource-consumers by themselves but, like any other job, can become burdensome when they are put
into the job queue in large numbers because each individual job consumes a worker process and requires
an incremental allocation of memory.

When might I want to consider changing the number of Job Engine service threads to a setting
other than the default?
The default number of Job Engine service threads is 10. This setting is generally appropriate for small to
medium-sized systems with average workloads. In most cases, there is no need to change the threads
setting unless you consistently experience slow asynchronous job throughput or excessively-long job
queue lengths. If the server running the Job Engine service is not resource constrained, then gradually
increasing the number of configured threads may improve job throughput and reduce job queue lengths.
Correspondingly, decreasing the number of threads can alleviate the Job Engine service CPU and memory
pressure, with the tradeoff being longer job queues and less job throughput.

What do I need to know about making changes to the Job Engine service thread settings?
It is possible to either under-allocate or over-allocate Job Engine service threads. Thread over-allocation
occurs when the increases made to the number of configured Job Engine threads begin to have a negative
effect on job completion and job queue lengths. On the other hand, thread under-allocation occurs when
the number of threads is set so low that the queue of jobs waiting to process becomes increasingly lengthy
over time.

How should I approach making changes to the Job Engine service thread settings?
When making changes to Job Engine service threads, do so gradually. For example, if your Job Engine
service is currently set for 10 threads and you believe you may benefit from a higher setting, try a setting
of 12. Then, take time to observe how the system performs, and make any further desired adjustments
following the same prudent approach. Correspondingly, it would not be advisable, for example, to change
the threads setting from 10 to 20 without first observing the effects of the interim settings.

When is it beneficial to add additional Job Engine service servers?

You may want to consider adding an additional Job Engine service server if you find you have exhausted
the amount of performance gain from increasing Job Engine service threads. Additionally, if the Job
Engine service memory and CPU pressure on the Job Engine service server is persistently excessive,
adding another Job Engine service server can reduce the pressure on available resources. Also, it is
possible to dedicate a Job Engine service server to a particular type (or several types) of Job Engine
activity.

Chapter 5: Job Engine Service Performance Considerations 49

RSA Archer GRC Sizing and Performance Guide

Job Engine Service Performance Testing Environments

The initial Job Engine service performance testing used two different types of hardware environments:

Environment #1: Lower-end. The first environment was over-balanced in RAM but relatively under-
weighted in terms of CPU. The following table lists the RAM in the first testing environment.

Job Server RAM

Version 5.5.1038

Database Server 6 CPU with 96 GB RAM

Services Server 5 vCPU with 64 GB RAM

Web Server 1 6 vCPU with 32 GB RAM

Web Server 2 6 vCPU with 32 GB RAM

Environment #2: Higher-end. The second environment was of larger scale. The following table lists the
RAM in the second testing environment.

Job Server RAM

Version 5.5.1183

Database Server 24 CPU with 24 GB RAM

Services Server 24 CPU with 24 GB RAM

Web Server 1 24 CPU with 24 GB RAM

Web Server 2 24 CPU with 24 GB RAM

Chapter 5: Job Engine Service Performance Considerations 50

RSA Archer GRC Sizing and Performance Guide

Job Engine Service Performance Testing Results

The following table lists the testing results for Environment #1 Lower-end:

# of Job # of Threads per Avg jobs completed per Avg jobs enqueued per
Servers Server minute minute
1 5 62.65 139.35

1 10 109.20 107.70

1 20 85.92 0.08

2 5 142.29 147.29

2 10 190.55 63.09

2 20 146.79 -0.07

3 5 211.86 158.57

3 10 246.83 -0.42

3 20 236.77 0.38

The following table lists the testing results for Environment #2 Higher-end:

# of Job # of Threads per Avg jobs completed per Avg jobs enqueued per
Servers Server minute minute
1 5 52.56 172.56

1 10 124.33 195.00

1 15 205.00 205.89

1 20 230.91 156.45

1 30 295.22 65.44

1 50 349.11 0.22

2 5 127.31 173.19

2 10 260.89 193.56

2 15 351.67 64.78

2 20 374.11 0.11

2 30 381.78 -

Chapter 5: Job Engine Service Performance Considerations 51

RSA Archer GRC Sizing and Performance Guide

# of Job # of Threads per Avg jobs completed per Avg jobs enqueued per
Servers Server minute minute
2 50 391.40 (0.20)

3 5 190.86 212.57

3 10 331.78 109.22

3 15 412.89 (0.22)

3 20 423.11 (0.67)

3 30 428.18 0.18)

3 50 421.00 (0.22)

Chapter 5: Job Engine Service Performance Considerations 52

RSA Archer GRC Sizing and Performance Guide

Job Engine Service Testing: Observations, Caveats, and Best Practices:

Category Findings
General Observations  Under-allocating threads can cause job queue lengths to
increase, which in turn may result in a backlog of jobs. Be
aware that at very low thread settings, it could be possible to
create a queue of backlogged of jobs that will cause
significant delay till completion.

 Over-allocating threads can cause the Job Engine service

server to utilize a significant amount of CPU. If you find your
average CPU utilization during Job Engine activity is range-
bound above 80%, it would be advisable to back off on the
number of configured threads and (possibly) consider adding
another Job Engine service server.

 For environments utilizing more than one Job Engine service

server, please be aware that the "Discontinue Job Processing"
option within the RSA Archer Control Panel Job Engine
Plug-in affects all configured Job Engine service servers (not
just the currently-selected one).

 The use of virtualized Job Engine service servers is

acceptable as long as they are configured according to best
practices and the CPU and memory resources are not over-
allocated.

Environment 1 (“lower-end”): 1. At 5 threads, Environment 1 (which features more RAM)

consistently out-performed Environment 2.

2. At 20 threads, the CPUs were consistently above 80%.

3. At 20 threads, job completion diminishes due to thread over-

allocation.

Environment 2 (“higher-end”): 1. Between 10 and 50 threads, adding more threads scaled well.

2. At 50 threads, the CPUs got extremely busy (but did not max
out).

3. At 50 threads, job completion diminishes due to thread over-

allocation.

Chapter 5: Job Engine Service Performance Considerations 53

RSA Archer GRC Sizing and Performance Guide

Appendix A: Sizing Quick Reference Chart

Environment # of Concurrent CPU

Description RAM
Size Instances Users cores

Very Small 1 Up to 10 web, services, and database all 2 8GB

Single-Host on the same server; suitable for
DEV/TEST work or on
demonstrations (not production)

Small Single- Up to 3 Up to 50 web, services, and database all 4 16GB

Host on the same server

Environment # of Concurrent CPU

Description RAM
Size Instances Users cores

Offline Access 1 1 web, services, and database 2 6GB

Laptop all on the same mobile
computer

Services & Database

Web Server Server
Environment # of Concurrent
Description
Size Instances Users
CPU CPU
RAM RAM
cores cores

Small Up to 5 Up to 100 web and 4 16GB 4 16GB

services
together but
with a separate
database server

Appendix A: Sizing and Quick Reference Chart 54

RSA Archer GRC Sizing and Performance Guide

Services Database
Web Servers
Server(s) Server
Environment # of Concurrent
Description
Size Instances Users
CPU CPU CPU
cores RAM cores RAM cores RAM

Medium Up to 10 Up to 250 One database 4 16GB 4 16GB 8 48GB

server, two
web servers,
and one
services
server

Large Up to 25 Up to 750 One database 8 24GB 8 24GB 16 96GB

server, four
web servers,
and two
services
servers

Very Large Up to 50 750+ One database 16 32GB 16 32GB 32 128GB

server, four or
more web
servers, and
two or more
services
servers (one
of which is a
dedicated job
engine
server);
customers
with “Very
Large”
deployment
requirements
are asked to
contact their
Sales Rep for
additional
hardware
sizing
assistance

Note: All hosts that run the RSA Archer Advanced Workflow service must also run an instance of the
RSA Archer Web server.

Appendix A: Sizing and Quick Reference Chart 55

RSA Archer GRC Sizing and Performance Guide

Appendix B: Java Settings for Advanced Workflow

Before you begin
Only make changes to these settings when there is direct evidence of their necessity or after receiving
specific guidance from RSA Customer Support. Always test changes in a non-production environment
before attempting changes in a production environment. Always make precautionary backups of files
before altering them. Make any changes gradually and incrementally. Carefully observe the effects of
previous changes before proceeding with future changes. The Advanced Workflow service must be
restarted in order for changes to these settings to take effect.

JRE Memory Settings

The default JRE memory settings for Advanced Workflow are 1GB minimum and 2GB maximum. In a
multi-instance installation, any changes to the JRE memory settings affect all instances as the JRE
memory is shared among all of the instances of the installation.

Settings for Advanced Workflow JRE memory are found in the following location:

Folder Name: ..\Program Files\RSA Archer\Services

File Name: ArcherTech.Services.WorkflowServices.exe.config

Default Values: –Xms1G –Xmx2G

Change Scenario # 1: “I have a large system with plenty of physical memory. My company
performs a lot of Advanced Workflow activity, and I have noticed on
several occasions during peak usage periods that the Java process
associated with the Advanced Workflow service was consuming an
amount of physical memory that was very close to my configured
maximum JRE memory setting of 2GB. Additionally, I sometimes see
messages in log files indicating Java is running low on memory.” A
possible setting for this scenario might be:

–Xms1G –Xmx3G

Change Scenario # 2: “I have a small to medium-sized server where we expect to do a small

amount of Advanced Workflow activity. I want to configure the
Advanced Workflow service to use exactly 256MB.” A possible setting
for this scenario might be:

–Xms256M –Xmx256M

Appendix B: Java Settings for Advanced Workflow 56

RSA Archer GRC Sizing and Performance Guide

JDBC Connection Pool Settings

The default JDBC connection pool settings for Advanced Workflow are 10 minimum and 200 maximum.
Settings for Advanced Workflow JDBC connection pools are found in the following location:

Folder Name: ..\Program Files\RSA Archer\Workflow\jboss-as\standalone\configuration

File Name: standalone-rsa-archer.xml

Default Values:

<min-pool-size>10</min-pool-size>
<max-pool-size>200</max-pool-size>

Please note that in a multi-instance installation, changes to JDBC connection pool settings need to be
made on an instance-by-instance basis as each instance has its own connection pool settings. Because of
this, it is of great importance that you identify the correct section of the file corresponding with the
Archer instance you intend to change.

To do this you must first determine the WorkPoint DataSource (WPDS) entry associated with your
Archer instance. Start by searching the file for the name of your Archer instance database. Your instance
database name will appear on a line that begins with:

<xa-datasource-property name="DatabaseName">

Above the line containing your instance database name, look for a line that begins with:

<xa-datasource jndi-name=”java:/jdbc/

The name of the WPDS entry will appear on that line. Examples of WPDS entries include “WPDS2”, or
“WPDS13”, or simply “WPDS”.

Next, find the “<xa-pool>” section that appears in the <xa-datasource section for your instance. This will
appear a few lines below the entry containing the name of your instance database.

The <xa-pool> section contains the settings for the minimum and maximum number of JDBC
connections for the instance.

Change Scenario: “I have a large Archer environment where I know I will have 225
concurrent users actively performing Advanced Workflow activity
almost all of the time.” A possible setting for this example might be:

<min-pool-size>10</min-pool-size>

Appendix B: Java Settings for Advanced Workflow 57