Connectivity

Alliance Access 7.1

System Configuration Recommendations

and Guidelines
This document provides minimum system requirements and guidelines for running Alliance Access 7.1.

27 March 2015
Alliance Access 7.1

Table of Contents

.Preface .............................................................................................................................................................................3

1 Introduction ....................................................................................................................................................... 4

2 Reference Platforms ...................................................................................................................................... 5

3 High-End Systems .......................................................................................................................................... 7

3.1 FIN Test Configuration ............................................................................................................................. 7
3.2 CPU Usage for FIN Traffic ....................................................................................................................... 8
3.3 InterAct Test Configuration ...................................................................................................................... 9
3.4 CPU Usage for InterAct Traffic ............................................................................................................... 9
3.5 FileAct Test Configuration ..................................................................................................................... 12
3.6 CPU Usage for FileAct Traffic ............................................................................................................... 12

4 Low-End and Medium-End Systems .................................................................................................... 15

4.1 FIN Test Configuration ........................................................................................................................... 15
4.2 CPU Usage for FIN Traffic ..................................................................................................................... 16
4.3 InterAct Test Configuration .................................................................................................................... 17
4.4 CPU Usage for InterAct Traffic ............................................................................................................. 17
4.5 FileAct Test Configuration ..................................................................................................................... 19
4.6 CPU Usage for FileAct Traffic ............................................................................................................... 19

5 Disk Sizing Guidelines ................................................................................................................................ 21

5.1 Daily Message Traffic (MX and MT Messages) ................................................................................. 22
5.2 Daily Journal Logging (MX and MT Messages) ................................................................................. 23
5.3 FileAct Traffic ........................................................................................................................................... 24

6 Impact of Specific Activity ........................................................................................................................ 26

6.1 Database Recovery ................................................................................................................................ 26
6.2 Hosted Database ..................................................................................................................................... 27
6.3 Impact of Using Alliance Access 7.0.75 or Higher ............................................................................. 27
.Legal Notices ...............................................................................................................................................................29

2 System Configuration Recommendations and Guidelines

 Preface

Preface
Purpose
The purpose of this document is to provide the following information:

guidelines for minimum system requirements on which to run Alliance Access 7.1 with the
following committed throughputs:

up to 40, 20, 10, and 5 Transactions Per Second (UNIX and Windows)

an outline of the impact on CPU usage when processing these throughputs

guidelines for disk space sizing

outline the effect of usage of certain features on system resources

Intended audience
This document is intended for new and existing customers who require recommendations for
sizing a system that is capable of handling a certain message throughput.

Significant changes in the previous version

This document was updated to:

Remove the section "CPU Utilisation Comparison with Previous Alliance Access Versions",
which is no longer relevant.

Remove the measurements for T5120 machines, as they are no longer available in the list of
recommended systems for the low-end and medium-end ranges.

Significant changes in this version

This document has been updated to:

Include minimum system requirement guidelines and CPU utilisation for the Linux platform for
up to 40, 20, 10, and 5 TPS transactions.

Show the impact on CPU when using Alliance Access 7.0.75 or higher.

Related documentation
You can find a full list of related documents in the Documentation section of the Alliance Access
Release Letter.

27 March 2015 3
Alliance Access 7.1

1 Introduction
Overview

Section Describes

Reference Platforms on page The reference platforms that were used to perform the benchmarking
5 tests.

High-End Systems on page Information about systems with a throughput of 20 or 40 Transactions

7 Per Second.
CPU usage was compared between:

running 20 or 40 Transactions Per Second sustaining traffic with the

MQ Host Adapter

running 20 or 40 Transactions Per Second sustaining traffic with the

SOAP Host Adapter

Low-End and Medium-End Information about systems running 5 or 10 Transactions Per Second.
Systems on page 15 CPU usage was compared between running 5 or 10 Transactions Per
Second.

Disk Sizing Guidelines on page Guidelines for disk sizing for FIN, InterAct, and FileAct messaging
21 services.

Impact of Specific Activity on
page 26
Information about the impact of recovering the database.
General guidelines are provided to minimise the recovery time and to
configure the mirror and backup disks. Furthermore, the impact on
system resources when running a full recovery backup was measured.
This was performed on the reference platforms for a throughput of 40
FIN Transactions Per Second.

Definition of Transactions per Second

The term Transaction Per Section is defined as one of the following:

the reception of a message from the back office, the input of that message into SWIFTNet,
and the output of the network ACK to the back office.

the reception of a message from SWIFTNet and the output of that message to the back
office.

4 System Configuration Recommendations and Guidelines

 Reference Platforms

2 Reference Platforms
Overview
The reference systems are available on www.swift.com, under Products & Services >
Introducing SWIFTNet 7.0 and Alliance 7.0 > Details > Hardware requirements for release 7.0.
Reference systems are available for running the following scenarios:

Alliance Access up to 40 TPS

Alliance Access up to 20 TPS

Alliance Access up to 10 TPS

Alliance Access up to 5 TPS

all SWIFT software (that is, SWIFTNet Link, Alliance Gateway, Alliance Access/Entry, and
Alliance Web Platform) on one system (for less than 1000 messages per day).
The hardware memory requirements on swift.com have been updated for 5 TPS systems, as
well as for systems with two or more SWIFT software packages installed on the same server.
For details, refer to "Impact of Using Alliance Access 7.0.75 or Higher" on page 27.
You must contact SWIFT if your institution requires a TPS greater than 40 TPS.

Note Measurements for Linux are done in the scope of Alliance Access 7.0.75, while
those for all other operating systems are the original measurements taken with
base release 7.0.

Additional CPUs, RAM, and storage capacity

You must also consider additional CPUs, RAM, and storage capacity on top of the hardware
requirements provided, if the following circumstances apply to your institution:

Multiple back-office connections are used (for example, file based message partners).

More complex routing is defined (multiple instances per message, additional interventions).

Additional services, like AML filtering, are provided on messages via ADK applications.

The system is also used by operators to search for messages and events in the database.

Disk configuration for high-end systems

For high-end systems, the disk configuration must have enough persistent write cache.
Disk striping is highly recommended (for example, RAID 0, RAID 5, RAID 6). The selection of
the level depends on performance, resiliency, and cost considerations.
The bandwidth between the Alliance Access host and the disk subsystem must be adequate
and guaranteed.
If you use synchronous replication, then ensure that this has the least possible impact on the
disk performance and ensure that sufficient bandwidth is available between the locations.
If you use asynchronous replication, then the technology used must ensure dependent-write
order consistency across the Alliance Access file systems. Data can be lost in a disaster
situation, which can result in messages being sent twice without a Possible Duplication
Emission (PDE) trailer.

27 March 2015 5
Alliance Access 7.1

Note As measured by the disk_test tool on Alliance Access, the global disk
performance on SWIFT reference systems is under one second. You can find the
tool in $ALLIANCE/common/bin/$ARCH/disk_test on UNIX or %ALLIANCE%
\common\bin\%ARCH%\disk_test.exe on Windows.

Database memory allocation

The underlying Oracle database is configured with default memory size (target size of Oracle
SGA and PGA) of 1500 MB. This value is suitable for Alliance Access configured in pipe mode
or with low user interactions.
If Alliance Access is used by multiple operators or used to extensively search messages, then it
is recommended to tune the memory allocated for the database based on your actual system
usage. For more information about the procedure to change the memory allocated for the
database, see "Configuring the Embedded Database" in the Administration Guide for AIX,
Linux, Oracle Solaris, and Windows.

6 System Configuration Recommendations and Guidelines

 High-End Systems

3 High-End Systems
Overview
This section provides data for systems running 20 or 40 Transactions Per Second.
The section first describes the test configuration implemented on the benchmarking platforms.
Then, it gives a summary of the impact on CPU when running Alliance Access 7.1 at 20 or 40
Transactions Per Second.
Alliance Access is configured to process quickly a large volume of messages that are
exchanged with back-office applications (with no system interventions on the system, some
events disabled). For more information, see Knowledge base tip 5017911. The messages
received from the back-office applications are sent directly to the SWIFT interface. The
messages received from SWIFT and the transmission notifications are sent directly to the back
office

Alliance Access disk configuration

This table outlines the distribution of Alliance Access over the different file systems:

Ref Alliance Access 7.1

saarls Release tree

Database: system, data, journal, undo

saaredo Database: redo logs

saamesg Database: messages, archives

saaback Message archive backups

wmq IBM WebSphere MQ

saafile FileAct (payload files)

saaredo2 Mirror disk for database recovery

saarman Backup disk for database recovery

3.1 FIN Test Configuration

Message capacity and throughput
During the 40 FIN Transactions Per Second tests, the following message capacity and
throughput was simulated on Alliance Access 7.1:

Daily capacity: 1,000,000 messages per day

Overall throughput: 144,000 FIN messages per hour or 40 FIN Transactions Per Second
peak traffic, with an average text size of 850 bytes per FIN message

Communication with back-office applications was done through either the native MQ Host
Adapter or the SOAP Host Adapter. This resulted in the emission of 72,000 FIN messages,
and the reception of 72,000 transmission notifications and 72,000 FIN messages. For this
test, when using the MQ Host Adapter, the MQ queues are configured in non-persistent
mode and the system is running in MQ server mode. The XMLv2 message format was used.
For the tests with 20 FIN Transactions Per Second, divide by 2 the numbers in these results.

27 March 2015 7
Alliance Access 7.1

3.2 CPU Usage for FIN Traffic

Alliance Access 7.1 tests
During these tests, CPU measures were taken when processing 20 and 40 FIN Transactions
Per Second, on the 40 FIN Transactions Per Second reference platform, on UNIX and
Windows.
The throughput was achieved by sending FIN messages through either the MQ Host Adapter or
the SOAP Host Adapter to SWIFT.

8 System Configuration Recommendations and Guidelines

 High-End Systems

3.3 InterAct Test Configuration

Alliance Access configuration
During the tests with 40 InterAct Transactions Per Second, the following message capacity and
throughput was simulated onAlliance Access 7.1:

Overall throughput: 144,000 InterAct messages per hour or 40 InterAct Transactions Per
Second peak traffic, with an average payload size of 4 KB, 10 KB and 100 KB per InterAct
message.

Communication with the back-office applications was done through either the native MQ Host
Adapter or the SOAP Host Adapter. This results in the emission of 72,000 InterAct
messages, and the reception of 72,000 transmission notifications and 72,000 InterAct
messages. For this test, when using the MQ Host Adapter, the MQ queues are configured in
non-persistent mode and the system is running in MQ server mode. The XMLv2 message
format is used.
For the tests with 20 Transactions Per Second, divide by 2 the numbers in these results.

3.4 CPU Usage for InterAct Traffic

Alliance Access 7.1 tests
During these tests, CPU measurements were taken when processing 20 and 40 InterAct
Transactions Per Second, on UNIX and Windows.
The throughput was achieved by sending InterAct messages through either the MQ Host
Adapter or through the SOAP Host Adapter to SWIFT.

27 March 2015 9
Alliance Access 7.1

10 System Configuration Recommendations and Guidelines

 High-End Systems

27 March 2015 11
Alliance Access 7.1

3.5 FileAct Test Configuration

Alliance Access configuration
During the FileAct tests, the following was simulated on Alliance Access 7.1:

Overall throughput: average payload size of 20KB x 5000 files, 50KB x 2000 files and 1MB x
100 files.

Communication with back-office applications was done through either the native MQ Host
Adapter or the SOAP Host Adapter using full and mixed modes.
For this test, when using the MQ Host Adapter, the MQ queues are configured in non-persistent
mode and the system is running in MQ server mode. The XMLv2 message format is used.

3.6 CPU Usage for FileAct Traffic

Alliance Access 7.1 tests
During these tests, CPU measures were taken when processing payload files of 20 KB, 50 KB,
and 1 MB, on UNIX and Windows.
This was achieved by sending FileAct messages through either the MQ Host Adapter (mixed or
Full Mode) or through the SOAP Host Adapter (Mixed or Full Mode) to SWIFT.

12 System Configuration Recommendations and Guidelines

 High-End Systems

27 March 2015 13
Alliance Access 7.1

Measurements for Linux were made for 10 TPS FileAct using the MQHA and SOAPHA adapters
in full mode, using a high-end configuration.
In addition, based on previous benchmarks done for FileAct, note the following:

The larger the payload file size, the less CPU will be consumed.

The CPU consumption for FileAct in mixed mode is close to or lower than FileAct in full
mode.

Note The CPU numbers in these results are the maximum possible values for sending
concurrent files to the local simulator.
Therefore, this does not reflect the impact of the bandwidth nor the time needed for
processing on the central system. The CPU values of sending the traffic through
the SWIFT network are expected to be much lower based on the actual network
transient time and the number of Alliance Gateway connections that are used.

14 System Configuration Recommendations and Guidelines

 Low-End and Medium-End Systems

4 Low-End and Medium-End Systems

Overview
This section provides data for systems running 5 or 10 Transactions Per Second on Alliance
Access 7.1.
The section first describes the test configuration implemented on the reference platforms. It then
gives a summary of the impact on CPU usage when running Alliance Access 7.1 at 5 or 10
Transactions Per Second.
Alliance Access is configured in the default configuration (routing, and interventions). The
routing is modified only to send messages immediately through Alliance Access.

Alliance Access disk configuration

The complete Alliance Access database is installed on the same file system.

4.1 FIN Test Configuration

Alliance Access configuration
During the 10 FIN Transactions Per Second tests, the following message capacity and
throughput is simulated on Alliance Access 7.1:

Daily capacity: 250,000 messages per day

Overall throughput: 36,000 FIN messages per hour or 10 FIN Transactions Per Second peak
traffic, with an average text size of 850 bytes per FIN message

Communication with back-office applications is done through either the native MQ Host
Adapter or the SOAP Host Adapter. This results in the emission of 18,000 FIN messages,
and the reception of 18000 transmission notifications and 18000 FIN messages. For this test,
when using the MQ Host Adapter, the MQ queues are configured in non-persistent mode and
the system is running in MQ server mode. The XMLv2 message format is used.
For the tests with 5 FIN Transactions Per Second, divide by 2 the numbers in these results.

27 March 2015 15
Alliance Access 7.1

4.2 CPU Usage for FIN Traffic

Alliance Access 7.1 tests
During these tests, CPU measures were taken when processing 5 and 10 FIN Transactions Per
Second, on the reference platforms for 10 Transactions Per Second, on UNIX and Windows
reference systems. The throughput was achieved by sending FIN messages through either the
MQ Host Adapter or the SOAP Host Adapter.

16 System Configuration Recommendations and Guidelines

 Low-End and Medium-End Systems

On all platforms, the CPU average load increases when traffic increases from 5 to 10
Transactions Per Second, although this is not linear.

Note The CPU numbers are higher on the POWER 6 platform because there are fewer
hardware processing threads on the system, and the test scenarios do not use all
available threads on the other systems.
The 5 TPS figures on the POWER 7 system have been extrapolated.

4.3 InterAct Test Configuration

Alliance Access configuration
During the tests with 10 InterAct Transactions Per Second, the following message capacity and
throughput is simulated on Alliance Access 7.1:

Overall throughput: 36,000 InterAct messages per hour or 10 InterAct Transactions Per
Second peak traffic, with an average text size of 4KB per InterAct message

Back-office communication is done via the native MQ Host Adapter or the SOAP Host
Adapter. This results in the emission of 18,000 InterAct messages, and the reception of
18,000 transmission notifications and 18,000 InterAct messages. For this test, when using
the MQ Host Adapter, the MQ queues are configured in non-persistent mode and the system
is running in MQ server mode. The XMLv2 message format is used.
For the tests with 5 Transactions Per Second, divide by 2 the numbers in these results.

4.4 CPU Usage for InterAct Traffic

Alliance Access 7.1 tests
During these tests, CPU measures were taken when processing 5 and 10 InterAct Transactions
Per Second, on UNIX and Windows.
The throughput was achieved by sending InterAct messages through either the MQ Host
Adapter or the SOAP Host Adapter to SWIFT.

27 March 2015 17
Alliance Access 7.1

18 System Configuration Recommendations and Guidelines

 Low-End and Medium-End Systems

Note The CPU numbers are higher on the POWER 6 platform because there are fewer
hardware processing threads on the system, and the test scenarios do not use all
available threads on the other systems.

4.5 FileAct Test Configuration

Alliance Access configuration
During the FileAct tests, the following has been simulated on Alliance Access 7.1:

Overall throughput: average payload size of 20 KB x 5000 files, 50KB x 2000 files and 1 MB
x 100 files.

Communication with back-office applications is done through the native MQ Host Adapter
using full mode. For this test, when using the MQ Host Adapter, the MQ queues are
configured in non-persistent mode and the system is running in MQ server mode. The XMLv2
message format is used.

The test has been done using FileAct in store-and-forward and not real-time communication
modes to be able to measure Alliance Access with no other factors that can influence the
performance. For real-time communication, other factors, like counterparty bandwidth, will
have an impact.

4.6 CPU Usage for FileAct Traffic

Alliance Access 7.1 tests
During these tests, CPU measures were taken when processing payload files of 20 KB, 50 KB,
and 1 MB, on UNIX and Windows.
This was achieved by sending FileAct messages through the MQ Host Adapter (Full Mode) to
SWIFT.

Note Measurements for FileAct on Linux under a low-end configuration for 6 TPS will be
made available in a future version of this document. The CPU utilisation for file
sizes up to 50 KB should be approximately 5%.

27 March 2015 19
Alliance Access 7.1

Note The CPU numbers reached are the maximum possible when sending 30
concurrent files to the local simulator.
Therefore, this does not reflect the impact of the bandwidth nor the time to process
on the central system. The values reached when sending the traffic through the
SWIFT network are expected to be much lower based on the actual network
transient time and the number of Alliance Gateway connections that are used.

20 System Configuration Recommendations and Guidelines

 Disk Sizing Guidelines

5 Disk Sizing Guidelines

Overview
In addition to the default setup of the Alliance Access database, SWIFT created daily message
and journal tablespaces per datafile to occupy additional space on disk.
Also, a permanent datafile for FileAct traffic was created. Datafiles were created with an initial
size. The size is extended when the initial size is exhausted.

Datafile Initial Size Next Increment

daily message 32 MB 128 MB

daily journal 16 MB 64 MB

FileAct 128 MB 100 MB

Note The FileAct datafile is a permanent datafile. It is not a daily table.

Depending on the configuration and the messaging service (FIN, InterAct or FileAct), the size of
the message can affect the amount of disk space that is required for the datafile. For low daily
volumes, the initial size of the datafiles should be enough.
This sizing represents the minimal space usage, based on an Alliance Access server with low-
end configuration (default routing and interventions) and 2 instances per input message, and 1
instance per output message.

Note All calculations are very conservative and have been done considering the worst
case scenario (last extent barely used and using a low-end configuration). If your
institution requires more complex routing or additional message instances, then
more space will be required. In that case, contact SWIFT.

Archives
With Alliance Access 7.1, the daily message archives are still stored in the database. These
archives can occupy approximately up to 10 percent more disk space than the original day of
traffic (depending on the traffic distribution across the messaging services FIN, InterAct, and
FileAct). This extra disk space is required for additional data created to improve the
performance of message searches in archives. On the other hand, once the daily table is
archived, the daily table will be resized to only use the necessary disk space (the same applies
to restored archives).

Backups
During the backup operation, the archived messages are backed up to external files. During
operations to remove backups, the archived messages are backed up to external files and then
they are removed physically from the database. The space occupied by the backup of a
message archive on the external file system is approximately 40 percent less than the disk
space occupied by the live original day of traffic (depending on the traffic distribution across the
messaging services FIN, InterAct, and FileAct) stored in the database.

27 March 2015 21
Alliance Access 7.1

5.1 Daily Message Traffic (MX and MT Messages)

Overview
The calculation of disk space for messages is very similar between MX and MT. Therefore, the
guidelines provided below can be used for both types.

Concepts
To use the formula properly for calculating the disk space for messages, the following concepts
are important
LOB segment: If the size of the message payload is below 4 KB, then the message payload
will be stored in-line. Therefore, the space occupied is equal to the actual size of the payload. If
the size of the message payload is greater than or equal to 4 KB, then the message payload will
be stored in segments of 8 KB. For example, a payload of 10 KB will be stored in 16 KB (two 8
KB segments).
Message overhead: Based on our calculations, each message that is stored in the database
will have an overhead of 10 KB. This is for a low-end configuration and is a conservative
guideline.
Adjusted table size: For daily messages, the initial size of the daily datafile will be 32 MB with
additional extents of 128 MB. This means that 130 MB of data will be stored in 160 MB (initial
size plus the next increment)

Formula

Disk Space (MB) = Adjusted table size [msg overhead (KB) + adjusted payload (KB)] x # msgs / 1024

The following table shows the average space allocated for live messages based on the number
of messages per day:

Disk space (in MB) required for FIN and MX messages

Payload # messages per day

KB
1,000 5,000 10,000 50,000 100,000 500,000 1,000,000

1 32 160 160 544 1,184 5,408 10,784

4 32 160 288 928 1,824 8,864 17,696

10 32 160 288 1,312 2,592 12,704 25,504

100 (MX 160 672 1,184 5,664 11,168 55,712 111,392

only)

Note For a high-end configuration, the sizing will require less space because less
information is stored for messages in the daily datafiles.

22 System Configuration Recommendations and Guidelines

 Disk Sizing Guidelines

5.2 Daily Journal Logging (MX and MT Messages)

Overview
The calculation of disk space for the journal datafile is different for MT and MX:

In a low-end configuration, the FIN message payload is logged and message flow events are
logged.

In a high-end configuration, the FIN message payload is not logged and message flow events
are not logged.

For MX messages, the payload is never logged regardless of the configuration used.

Concepts
To use the formula properly for calculating the disk space for the Event Journal, the following
concepts are important
LOB segment: If the size of the message payload is below 4 KB, then the message payload
will be stored in-line. Therefore, the space occupied is equal to the actual size of the payload. If
the size of the message payload is greater than or equal to 4 KB, then the message payload will
be stored in segments of 8 KB. For example, a payload of 10 KB will be stored in the Event
Journal in 16 KB (two 8 KB segments).
Event Journal overhead: Based on our calculations, each message that is logged in the Event
Journal in the database will have an overhead of 2.5 KB (FIN messages only). This is for a low-
end configuration and is a conservative guideline.
Based on our calculations, we can conservatively say that for each message logged in the
event journal that is stored in the database, using a low-end configuration, will have an
overhead of 2.5KB (FIN messages only)
Adjusted table size: For daily journal events, the initial size of the daily datafile will be 16 MB
with additional increments of 64 MB. This means that 50 MB of data will be stored in 80 MB
(initial size plus the next increment).

Formula
This formula is for the Event Journal for FIN traffic message flow with a low-end configuration:

Disk Space (MB) = Adjusted table size [event overhead (KB) + adjusted payload (KB)] x # msgs / 1024

The following table shows the average space allocated for the event journal based on the
number of messages per day and the payload being logged (FIN only):

Disk space (in MB) required for events for FIN message flow

Payload # messages per day

KB
1,000 5,000 10,000 50,000 100,000 500,000 1,000,000

1 16 80 80 208 400 1,744 3,472

4 16 80 144 528 1,040 5,136 10,256

10 80 144 208 912 1,808 9,040 18,128

27 March 2015 23
Alliance Access 7.1

Formula
This formula is for the Event Journal for FIN or MX traffic message flow with a low-end
configuration, and when a message payload is not logged:

Disk Space (MB) = Adjusted table size [event overhead (KB)] x # msgs / 1024

The following table shows the average space allocated for the event journal based on the
number of messages per day and the payload is not logged (FIN and MX):

Disk space (in MB) required for events for FIN or MX message flow (no payload logged)

Payload # messages per day

KB
1,000 5,000 10,000 50,000 100,000 500,000 1,000,000

1 16 16 80 144 272 1,232 2,448

4 16 16 80 144 272 1,232 2,448

10 16 16 80 144 272 1,232 2,448

Note For a high-end configuration, the sizing required for FIN or MX message flow will
be 16 MB (initial increment), as no message flow events are logged.

5.3 FileAct Traffic

Overview
The calculation of disk space for FileAct messages measures the impact on the daily message
datafile as well as on the FileAct datafile:

The information about the payload file (routing history, interventions, HeaderInfo) will be
stored in the daily message datafiles.

The message payload file is stored in the datafile for FileAct.

Concepts
To use the formula properly for calculating the disk space for FileAct messages, the following
concepts are important
LOB segment: If the size of the FileAct payload is below 4 KB, then the payload will be stored
in-line. Therefore, the space occupied is equal to the actual size of the payload. If the size of the
message payload is greater than or equal to 4 KB, then the message payload will be stored in
segments of 8 KB. For example, a payload of 10 KB will be stored in the database in 16 KB (two
8 KB segments).
FileAct message overhead: Based on our calculations, each message that is stored in the
database, will have an overhead of 10 KB. This is for a low-end configuration and is a
conservative guideline.
FileAct payload overhead: Based on our calculations, each message that is stored in the
database, will have an overhead of 0.2 KB. This is for a low-end configuration and is a
conservative guideline.
Adjusted table size (daily messages datafile): For daily messages, the initial size of the daily
datafile will be 32 MB with additional extents of 128 MB. This means that 130 MB of data will be
stored in 160 MB (initial size plus the next increment).

24 System Configuration Recommendations and Guidelines

 Disk Sizing Guidelines

Adjusted table size (FileAct payload datafile): For FileAct payload files, the initial size of the
daily datafile will be 128 MB with additional extents of 100 MB. This means that 130 MB of data
will be stored in 228 MB (initial size plus the next increment).

Formula for FileAct messages (daily message datafile)

Disk Space (MB) = Adjusted table size [msg overhead (KB) + adjusted HeaderInfo (KB)] x # msgs / 1024

The following table shows the average space allocated for the FileAct live messages based on
the number of messages per day:

Disk space (in MB) required for FileAct messages

HeaderInfo KB # messages per day

1,000 10,000 100,000 1,000,000

5 32 288 1,824 17,696

10 32 288 2,592 25,504

50 160 672 6,560 64,544

Formula for FileAct payload (FileAct datafile)

Disk Space (MB) = Adjusted table size [FileAct overhead (KB) + adjusted payload (KB)] x # msgs / 1024

The following table shows the average space allocated for the FileAct payload files based on
the number of messages per day:

Disk space (in MB) required for FileAct payload files

FileAct Payload # messages per day

KB
1,000 10,000 100,000 1,000,000

20 128 328 2,428 23,728

50 128 628 5,528 54,928

1,024 1,028 10,028 100,028 1,000,228

10,240 10,028 100,028 1,000,028 10,000,228

102,400 100,028 1,000,028 10,000,028 100,000,228

256,000 250,028 2,500,028 25,000,028 250,000,228

Note When the daily traffic is archived, the FileAct payload is removed from the FileAct
datafile, but the tablespace is not resized. To resize the tablespace, the tablespace
must be reorganised. For more information about how to resize the tablespace for
FileAct, see the saa_dbconfig command in the Administration Guide for AIX,
Linux, Oracle Solaris, and Windows.
For high-end configurations, the disk space sizing requires less space because
less information is stored for messages in the daily message datafiles.

27 March 2015 25
Alliance Access 7.1

6 Impact of Specific Activity

6.1 Database Recovery

Overview
The database recovery tests were run on the 40 FIN Transactions Per Second reference
platforms for UNIX and Windows.

Time to recover
The following table shows some examples of the recovery times that were required to restore a
database with one million live messages from a full recovery backup. For the tests including an
archive backup, the recovery backup contained one million live messages and one million
archived messages.

Compressed Include archive Windows AIX Oracle Solaris

backup

No No 0:04:06 0:04:10 0:02:00

Yes No 0:08:16 0:09:10 0:10:35

No Yes 0:04:43 0:05:15 0:02:32

Yes Yes 0:12:12 0:14:46 0:18:22

In general, the time needed to recover an Alliance Access database can be influenced as
follows:

Using compression for the recovery backup, which is an optional parameter, significantly
increases the time to recover. When compressing a backup of a database of 1 million
messages, the disk space required for this backup is compressed from 9.2 GB to 2.5 GB.

Including archive backups in the recovery backup, which is optional, increases the time to
recover.

Excluding archive backups in the recovery backup on a system with many archive backups
(in thousands), would increase the time to recover by approximately 3 seconds per archive
backup.
The figures in the table in this section are valid when recovering from a full recovery backup.
When the recovery is done either from incremental backups only or from redo logs only, this
influences the recovery time as follows:

Recovering from a full recovery backup is faster than recovering from incremental backups.

Recovering from incremental backups is faster than recovering from the redo logs.

Taking a full recovery backup

To limit the impact of a creating recovery backup on the system performance, a new
configuration parameter Maximum Read Rate is available. This parameter specifies the disk
input/output (expressed in MB/sec) that can be used when a recovery backup is created.
When this parameter is set to zero (maximum I/O usage), there is no limitation on the disk I/O
that is used. In that case the time required to take a full recovery backup is equivalent to the
time that it takes to restore the database (see the table in the section Time to recover above).

26 System Configuration Recommendations and Guidelines

 Impact of Specific Activity

If you set the Maximum Read Rate parameter to 30, then the time that it takes for the backup
to complete is doubled on all platforms. However, the time depends on the disk infrastructure.

Note SWIFT advises you test other values for this parameter in addition to 30.

CPU impact
When activating the database recovery option, the increase in CPU is minimal. The biggest
increase is observed when the full recovery backup is being taken and the read rate is set to the
maximum. Even in this condition, the increase observed during our tests never exceeded 10
percent.

Mirror and backup disk

The mirror disk is used to mirror the redo logs. Updates on the database are written
simultaneously on the live disk (Online Redo Log) and the recovery mirror disk (Mirrored Redo
Log).
As the database transaction only commits when both disks are updated, it is important that the
recovery mirror disk is as fast as the live disk to avoid a slowdown of the data updates. The size
of this disk must be sufficient to store the three redo logs and one control file.
The recovery backup disk stores the different database backups and the archived redo log files.
Therefore, this should be a large-storage disk, with a size that is three times the size of the live
disk. This should only be considered as a rule of thumb, as the actual disk size depends on a
number of parameters such as the daily traffic volume and the database recovery configuration.
The speed of this disk is less important than the speed of the recovery mirror disk.

6.2 Hosted Database

More information will become available in a future version of this document.

6.3 Impact of Using Alliance Access 7.0.75 or Higher

Overview
Alliance Access 7.0.75 includes functional enhancements as well as software fixes. In addition,
it also includes a higher version of the Oracle database. All of this new functionality and
database update will be included in the MST 2014 mandatory patch (7.0.80).
As a result, these patches can require more CPU and memory as compared to the base release
7.0. The actual resource load will depend on the existing hardware you have as well as your
current system configuration and utilisation.
Measurements show that patch 7.0.75 resource utilisation can:

Increase CPU utilisation between 10-20%.

Require more RAM memory. For this reason, the hardware requirements for Release 7.0 in
swift.com have been updated to reflect the following:

Systems used for up to 5 TPS require at least 8 GB of RAM, rather than 4 GB.

Windows systems with up to 1,000 messages per day running Alliance Access, SWIFTNet
Link, Alliance Gateway, and Alliance Web Platform on the same host will require 12 GB of
RAM, rather than 8 GB.

27 March 2015 27
Alliance Access 7.1

UNIX systems running two or more Alliance software packages (such as Alliance Access,
SWIFTNet Link, Alliance Gateway, and Alliance Web Platform) combined on the same
host will require at least 12 GB of RAM, rather than 8 GB.

Note All of the measurements for AIX, Oracle Solaris, and Windows in sections 3 and 4
of this document were made using Alliance Access 7.0 with the original memory
requirements. The measurements for Linux were made using Alliance Access
7.0.75 with the new hardware published on swift.com for this operating system.

28 System Configuration Recommendations and Guidelines

 Legal Notices

Legal Notices
Copyright
SWIFT 2015. All rights reserved.

Restricted Distribution
Do not distribute this publication outside your organisation unless your subscription or order expressly grants
you that right, in which case ensure you comply with any other applicable conditions.

Disclaimer
The information in this publication may change from time to time. You must always refer to the latest
available version.

Translations
The English version of SWIFT documentation is the only official and binding version.

Trademarks
SWIFT is the trade name of S.W.I.F.T. SCRL. The following are registered trademarks of SWIFT: the SWIFT
logo, SWIFT, SWIFTNet, Accord, Sibos, 3SKey, Innotribe, the Standards Forum logo, MyStandards, and
SWIFT Institute. Other product, service, or company names in this publication are trade names, trademarks,
or registered trademarks of their respective owners.

27 March 2015 29