Академический Документы
Профессиональный Документы
Культура Документы
27 March 2015
Alliance Access 7.1
Table of Contents
.Preface .............................................................................................................................................................................3
1 Introduction ....................................................................................................................................................... 4
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)
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.
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.
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.
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 Information about the impact of recovering the database.
page 26 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.
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.
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:
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.
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.
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.
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
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
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.
27 March 2015 9
Alliance Access 7.1
27 March 2015 11
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.
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.
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
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.
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.
27 March 2015 17
Alliance Access 7.1
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.
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.
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.
daily journal 16 MB 64 MB
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
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:
Note For a high-end configuration, the sizing will require less space because less
information is stored for messages in the daily datafiles.
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
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)
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.
The information about the payload file (routing history, interventions, HeaderInfo) will be
stored in the daily message datafiles.
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).
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).
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 (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:
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
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.
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.
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.
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.
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