front arena on sql server - microsoft · pdf filefront arena running on sql server 2008 r2...

Benchmark Testing Results: SunGard

Front Arena Running on Microsoft SQL Server

Benchmark testing confirms the enterprise-class performance and scalability of SunGard Front Arena running on Microsoft SQL Server 2008 R2 Enterprise

Technical White Paper Published: January 2012 Applies to: Microsoft SQL Server 2008 R2 Enterprise Abstract

SunGard and Microsoft worked together in March and April of 2011 at the Microsoft Platform Adoption

Center in Redmond, Washington, to confirm the performance and scalability of SunGard’s Front Arena

running on Microsoft SQL Server 2008 R2 Enterprise and Windows Server 2008 R2 Enterprise.

The team designed a benchmark test to simulate a real-world, enterprise-class financial workload, running

the software on industry-standard hardware typically used in data centers today. The test results exceeded

the goals set by the team, confirming that SQL Server 2008 R2 Enterprise is the right choice for SunGard

customers who want performance, scalability, and value from their trading solution.

Benchmark Testing Results: Microsoft SQL Server 2008 R2 Enterprise and SunGard Front Arena ii

©2012 Microsoft Corporation. All rights reserved. This document is provided “as-is.” Information and views

expressed in this document, including URL and other Internet Web site references, may change without notice.

You bear the risk of using it.

This document does not provide you with any legal rights to any intellectual property in any Microsoft product.

You may copy and use this document for your internal reference purposes.

Table of Contents

Introduction .................................................................................................................................................. 1

A Brief Introduction to SunGard Front Arena ................................................................................................... 2

SQL Server 2008 R2 Enterprise: Ideal for Front Arena ...................................................................................... 3

Benchmark Testing Setup .............................................................................................................................. 5

Test Hardware and Software Details ............................................................................................................ 6 Front Arena Components ............................................................................................................................. 7

Benchmark Test Scenarios ............................................................................................................................. 8

Exchange Trade Performance Scenario ............................................................................................................ 8 Performance Goals ....................................................................................................................................... 8 Test Simulation ............................................................................................................................................. 8 Performance Measurement ......................................................................................................................... 9

Position Control Performance Scenario ............................................................................................................ 9 Performance Goals ....................................................................................................................................... 9 Test Simulation ............................................................................................................................................. 9 Performance Measurements ....................................................................................................................... 9

The Benchmarking Tests .............................................................................................................................. 10

Exchange Trade Performance Tests ............................................................................................................... 10

Position Control Performance Tests ............................................................................................................... 11

Summary ..................................................................................................................................................... 17

Appendix: Best Practice Guidance ............................................................................................................... 18

Standard SQL Server Best Practices ................................................................................................................ 18

Additional Best Practices ................................................................................................................................ 18

Additional Information ................................................................................................................................ 21

Introduction

Today's investors demand a wider variety of asset classes, more complex financial instruments, and

a broader geographical range of products than ever before. In their pursuit of aggressive, high-

speed, sophisticated trading strategies, traders are taking advantage of global markets to exploit

the variety of available asset classes and to create new opportunities. These changing requirements

result in exponential growth of transaction volumes and trading complexity, prompting the need

for a powerful and responsive trading infrastructure.

SunGard’s Front Arena is an integrated cross-asset platform for sales, trading and risk management,

operations, and distribution. The modular Front Arena software offers trading capabilities that

integrate money markets, FX, and FX options with capital markets trading, brokerage, and order

management. Front Arena was designed to handle very large data flows; in high-volume

environments such as equities exchange trading, Front Arena customers routinely enter as many as

130,000 trades per day.

Such high-volume workloads and aggressive scalability requirements necessitate an enterprise-

class database platform. Front Arena running on Microsoft SQL Server 2008 R2 Enterprise can

support a large number of concurrent users with fast, nonstop performance on a cost-effective,

standards-based server platform. The solid reliability, superior performance, and low total cost of

ownership (TCO) of SQL Server—combined with the processing and intelligent workflow capabilities

of Front Arena—help firms provide greater control over their entire capital markets trading

process.

In March and April of 2011, engineers from SunGard and Microsoft worked together to confirm the

performance and scalability of Front Arena on SQL Server 2008 R2 Enterprise. Testing was

performed at the Microsoft Platform Adoption Center in Redmond, Washington.

The team designed a benchmark test that simulated a real-world, enterprise-class financial

workload. The software was run on industry-standard hardware routinely found in a data centers

today. (Note that using high-end hardware can deliver even better results, because Front Arena

and SQL Server can benefit from the capabilities of more powerful hardware.)

Front Arena running on SQL Server 2008 R2 Enterprise and Windows Server 2008 R2 Enterprise

exceeded the goals set by the team, confirming that SQL Server 2008 R2 Enterprise is the right

database choice for companies who want performance, scalability, and value from their trading

solution.

This white paper describes the methodology used to run the benchmark tests, and discusses the

test results in detail. The paper also describes best practice guidance that can be used to optimize

implementations of Front Arena running on SQL Server.

Benchmark Testing Results: Microsoft SQL Server 2008 R2 Enterprise and SunGard Front Arena 2

A Brief Introduction to SunGard Front Arena

Front Arena is one of the most open trading solutions ever designed. Its layered architecture

separates functional areas, which makes the system highly flexible and configurable. Components

can easily be replaced, updated, or duplicated for scalability, without compromising the overall

architecture.

Figure 1 shows a schematic of the Front Arena functionality.

Figure 1. SunGard Front Arena schematic

Since 1998, Front Arena has been based on a service-oriented architecture (SOA), which means that

the functionality of the system is re-packaged into services. These services are stand-alone, coarse-

grained components with self-describing, extensible interfaces that are typically defined in a

portable format such as XML.

To achieve the level of performance required for high-volume trading, Front Arena implements SOA

using a service bus with support for high-performance messaging. A key feature of the new service

bus architecture is its built-in grid-style distribution capabilities, dividing large processing jobs into

small tasks that can automatically be distributed over a large number of processing engines. This

functionality is particularly suitable for processor-intensive tasks such as Monte Carlo simulations

or scenario-based risk reporting.


The combination of messaging and coarse-grained interfaces means that system components are

loosely coupled; they can easily be replaced, updated or duplicated for scalability without

compromising the overall architecture.

Table 1 provides a summary of some of the features and components of Front Arena.

Table 1. Front Arena solution components

Front Arena

Component Description

Arena Extension

Framework

(AEF)

AEF is a complete set of development tools, programming interfaces, and

extension points that enable functional enhancements to Front Arena.

Arena Integration

Framework

(AIF)

AIF provides access to data streams and services.

Arena Data Model

(ADM)

All financial contracts, ranging from standard securities to OTC derivatives, are

represented in a generic model based on the concept of instrument, trade, and

cash flows. Unlike most other cross-asset trading systems, Front Arena ADM is

small and tight, minimizing maintenance costs and facilitating system

extension.

Arena Market

Access Server

(AMAS)

AMAS is responsible for handling the two-way traffic flow from and into an

exchange (for example, NASDAQ).

Arena Data Server

(ADS)

ADS is the application server responsible for event propagation, logging, and

interaction with the underlying database.

Arena Message

Broker Adapter

(AMBA)

AMBA is responsible for receiving and sending messages into and out of Front

Arena.

For more information about SunGard Front Arena, visit www.sungard.com/positioncontrol.

SQL Server 2008 R2 Enterprise: Ideal for Front Arena

At the heart of Front Arena is the database, where not only deals, static data, and market data are

stored, but also valuation settings, user preferences, and customer extensions. Keeping all this

information in a central location makes Front Arena independent of the local file systems and

allows users and services to roam between locations without losing context.

http://www.sungard.com/positioncontrol


A lot is required from the database infrastructure: high-availability, redundancy, transaction and

data integrity, consistency, predictability, and the balancing of proactive prevention with effective

recovery.

In the past, only mainframes could meet these needs. However, current versions of SQL Server

running on industry-standard hardware can provide the enterprise-class scalability and

performance Front Arena customers need. SQL Server offers many benefits:

Scalability and performance

SQL Server includes many features that help SunGard customers scale up and scale out

as their businesses grow.1

Lower hardware costs

SQL Server runs on standard commodity server hardware, providing dramatically lower

total cost of ownership (TCO) for utilities compared to mainframe computers.

Lower software costs

With SQL Server, customers can typically enjoy a 3:1 reduction over the largest

competitor in licensing costs.2

Simpler systems management and lower staffing costs3

SQL Server database administrators (DBAs) can typically manage three times as many

physical databases as a competitor’s DBAs.4

Lower maintenance costs5

SQL Server first-year maintenance costs are up to 77 percent less than those of the

largest competitor solutions.

Fewer security vulnerabilities

SQL Server has consistently had fewer security vulnerabilities than the largest

competitor solutions.6

SQL Server 2008 R2 Enterprise can deliver the high levels of performance, scalability, and reliability

that financial organizations require to support their critical business functions. With SQL Server,

SunGard customers can save with reduced licensing, hardware, administration, and support fees,

which translate into substantially lower costs over the life of the system.

1 http://www.microsoft.com/sqlserver/2008/en/us/performance-scale.aspx 2 http://www.microsoft.com/sqlserver/2008/en/us/value-calc.aspx 3 http://www.microsoft.com/sqlserver/2008/en/us/compare-oracle.aspx 4 http://www.alinean.com/PDFs/Microsoft_SQL_Server_and_Oracle-Alinean_TCA_Study_2010.pdf 5 http://www.microsoft.com/sqlserver/2008/en/us/compare-oracle-calc.aspx 6 NIST National Vulnerability Database, http://nvd.nist.gov/


For more information, visit the SQL Server home page at

http://www.microsoft.com/sqlserver/en/us/default.aspx.

Benchmark Testing Setup Benchmark tests were run on commodity hardware representing real-customer scenarios to

confirm the performance, scalability, and value of Front Arena on SQL Server. An additional goal of

the benchmark testing was to develop tuning and optimization recommendations applicable to

existing customer environments. (Note that using a more powerful hardware configuration than

that used in the tests will improve the results.)

Figure 2 shows the benchmark test infrastructure. 1

GB

/s N

etw

ork

Database

100 x 15k RPM drives

RAID10

800 GB

Temp DB

48 x 15k RPM drives

RAID10

600 GB

Logs

26 x 15k RPM drives

RAID10

400 GB

Brocade Silkwom Switch

Database Server

HP ProLiant DL380 G7

12 x 2.8 GHz—64 GB RAM

Xiotech

Magnitude3D 3000s

UID 1 2

1 2 3 4 5 6 7 8

DIMMS

PCI

RISER

CAGE

FANS

POWER

SUPPLY

POWER

SUPPLY

PROCPROC

DIMMS

I-PPM

OVERTEMP

INTERLOCK

PPM

HPProLiant

DL385 G5

UID 1 2

1 2 3 4 5 6 7 8

DIMMS

PCI

RISER

CAGE

FANS

POWER

SUPPLY

POWER

SUPPLY

PROCPROC

DIMMS

I-PPM

OVERTEMP

INTERLOCK

PPM

HPProLiant

DL385 G5

App1


12 x 2.8 GHz (Hyper-threading on)

64 GB RAM

Clients

HP ProLiant DL380 G7 12 x 2.8 GHz (Hyper-threading on)

64 GB RAM

Front-End Tier

(Clients)

Middle Tier

(Application)

Back-End Tier

(Database)

UID 1 2

1 2 3 4 5 6 7 8

DIMMS

PCI

RISER

CAGE

FANS

POWER

SUPPLY

POWER

SUPPLY

PROCPROC

DIMMS

I-PPM

OVERTEMP

INTERLOCK

PPM

HPProLiant

DL385 G5

System x3550

Domain Controller

Dell PowerEdge 1850

4 x 3.40 GHz—4 GB RAM

UID 1 2

1 2 3 4 5 6 7 8

DIMMS

PCI

RISER

CAGE

FANS

POWER

SUPPLY

POWER

SUPPLY

PROCPROC

DIMMS

I-PPM

OVERTEMP

INTERLOCK

PPM

HPProLiant

DL385 G5

App2


12 x 2.8 GHz (Hyper-threading on)

64 GB RAM

Figure 2. Benchmark test infrastructure

http://www.microsoft.com/sqlserver/en/us/default.aspx


Test Hardware and Software Details

Tables 2 provides details of the hardware and software in the database server.

Table 2. Details of database server

Database Server

Hardware

CPU 12 x 2.8 GHz

(2 x 6 cores)

RAM 64 GB

NICs Broadcom NC3821 1 GbE

Storage Area Network:

Xiotech Magnitude 3D 3000

Data volume (F drive):

48 x 15k FC RPM drives, RAID10, 600 GB

Log volume (E drive):

100 x 15k RPM FC drives, RAID10, 800 GB

Tempdb volume (G drive):

26 x 15k RPM FC drives, RAID10, 400 GB

SSD storage Fusion-io 320 GB SLC, PCIe card, 300 GB

Software Windows Server 2008 R2 Enterprise

Microsoft SQL Server 2008 R2 Enterprise Cumulative Update 6 (CU6)

Table 3 provides details of the hardware and software in the application servers.

Table 3. Details of application servers

Application Servers

Hardware

CPU 12 x 2.8 GHz

(2 x 6 cores, hyper-threading enabled)

RAM 64 GB


Local storage 200 GB

2 x 300 GB, 10k SAS drives, RAID10


SunGard Front Arena


Table 4 provides details of the hardware and software in the client servers.

Table 4. Details of client servers

Client Servers

Hardware

CPU 12 x 2.8 GHz

(2 x 6 cores, hyper-threading enabled)

RAM 64 GB


Local storage 200 GB, 2 x 300 GB, 10k SAS drives, RAID10


SunGard Front Arena

Front Arena Components

Table 5 describes the Front Arena components used in the benchmark testing.

Table 5. Front Arena components used in testing

Front Arena

Component Description

AMAS

The official test tool MCLogPerf was used to represent the AMAS against the

underlying database. While MCLogPerf can be thought of as a simplified sub-set

of an AMAS, it is complete.

Note that MCLogPerf is also available to customers.

AMBA AMBA was used to simulate the incoming exchange trade messages and persist

these as trades into the database through the ADS.

PRIME client The PRIME client is the proprietary Front Arena trading and risk management

tool.

Subscription load

generators

The subscription load generators provided synthetic emulation of the PRIME

desktop clients, subscribing to trade update events from the ADS and generating

background workload on the application servers (ADS).

Price update load

generator

The price update load generator provided synthetic emulation of price feeds (for

example, Thomson Reuters or Bloomberg). It pushes price updates into the ADS,

generating background workload on the application servers (ADS) and database.

The load generator is an internal component (part of the Front Arena

development and quality assurance environment).


Benchmark Test Scenarios Two test scenarios were used in the benchmarking test: exchange trade performance and position

control performance.

Exchange Trade Performance Scenario

This scenario simulated the exchange trading performance throughput of the AMAS, which handles

the inbound and outbound traffic between a trade exchange and the rest of Front Arena. The

AMAS throughput is measured in Multicast Log (MCLog) inserts per second.

Performance Goals

AMAS throughput is typically around 30,000 message inserts per second. Based on recent trends on

the exchange markets, it is expected that the volume of trade messages will rapidly grow over the

next few years.

The goal for the performance benchmark was defined as 100,000 AMAS MCLog message inserts per

second.

Test Simulation

The MCLogPerf tool was used to simulate the throughput of AMAS during the benchmark tests.

MCLogPerf is a C++ application that uses the open database connectivity (ODBC) interface to

connect to the database.

MCLogPerf uses various parameters to simulate different workloads, as shown in Table 6.

Table 6. MCLogPerf parameters

Parameter Description

Count Number of messages to insert

Size Size of each message

Threads Number of threads used for inserting messages into the database

Bulk copy (BCP)

setting Set at 0 for stored procedure inserts and at 1 for bulk inserts

Pack count Number of messages handled in one transaction

MCLogPerf is an official test tool available to customers for evaluating system performance on site.

While MCLogPerf does not provide exactly the same functionality of an AMAS, the performance is

very similar.


Performance Measurement

The AMAS throughput was measured for different combinations of batch size, message size, and

number of threads. The database was dropped and recreated after each test.

Position Control Performance Scenario

This scenario measured the position control performance throughout of the AMBA, ADS, and the

database.

The AMBAs received and translated incoming messages into the internal ADM trade format, and

then transmitted the resulting trades to ADS. The ADS stored the trades in the underlying ADM

schema within the SQL Server database and updated the subscribing clients.

Performance Goals

The throughput of this channel component is typically in the range of 200–400 trade inserts per

second.

The goal of the performance benchmark was defined as 1,000 trade inserts per second for a

workload consisting of 10,000 messages per AMBA client.

Test Simulation

The position control performance benchmark was simulated at the application server layer. The

client workload was divided into two categories:

Background workload

The background workload used scripts and tools to simulate a typical to heavy client

workload made up of PRIME clients and price updates.

Test workload

The test workload was simulated using multiple AMBAs, which sent trades that varied

across different asset classes to the ADS.

The test data was a mix of trades: 50 percent of the trades were normal trades, and 50 percent

were trades that use the “Additional Info” feature of ADM, which represents a more complex task

for SQL Server than a normal trade.

The database was pre-populated to include approximately 10 million trades.

Performance Measurements

The throughput measured different numbers of ADS and AMBA instances. The measurements for

each individual configuration were recorded after a “cold” start of the system, which included

restarting SQL Server and restoring the database to its initial state.


The Benchmarking Tests Baseline test were run for the multicast log inserts and for the trade message inserts, with and

without background loads. Information from these baseline tests was then used to establish the

benchmark testing parameters.

Exchange Trade Performance Tests

Based on the baseline tests, the parameters shown in Table 7 were used.

Table 7. Settings used for the exchange trade performance tests

Parameter Setting

Count 10,000,000 messages

Size 512

Threads 16

Bulk copy (BCP) setting Both on and off

Pack count 100

The database was in “full recovery” mode. Between test runs, SQL Server was re-started and the

database was restored. In addition, SeqNoPrefix, a new setting added to the MCLogPerf

application, was used. The SeqNoPrefix option causes inserts to be scattered around the clustered

index rather than grouped at the end of the index.

The exchange trade performance tests were first run using the storage area network (SAN). The

results are shown in Table 8.

Table 8. Results of exchange trade performance tests on SAN

Settings Results

(Message inserts per second) BCP SeqNoPrefix Number of applications*

Off Off 1 12,649

On Off 1 21,348

Off On 1 83,327

On On 1 111,706

Off On 2 105,982

On On 2 152,526

Off On 3 110,408

On On 3 160,338

* Each application wrote to a different database


As shown in Table 8, the benchmarking tests achieved a throughput of 111,706 message inserts per

second with a single database with BCP on and SeqNoPrefix on.

The tests achieved 160,338 messages per second with three applications writing to three

databases, even with all of the data files residing on the same volume and all of the log files

residing on the same volume. Splitting these files up onto separate volumes could increase the

performance even further.

The tests were then run on Fusion-io storage. The results are shown in Table 9. Note that eight

threads were used for the Fusion-io test runs. These test results confirm that using “faster” storage

further improves the performance.

Table 9. Results of exchange trade performance tests on Fusion-io

Settings Results

(Message inserts per second) BCP SeqNoPrefix Number of applications*

Off Off 1 17,178

On Off 1 95,863

Off On 1 73,293

On On 1 195,499

* Each application wrote to a different database

Position Control Performance Tests

For the position control tests, the following configuration and parameters were used:

Tests were run with a background workload.

A pre-sized database was used.

Clustered indexes were used on trade, additional_info, and trans_hst tables.

The SAN write cache was enabled.

Partitioned trade and additional_info tables on user creat_usrnbr with 32+2 partitions

were used.

The benchmark tests were run for a variety of configurations using various deployment scenarios

and various numbers of ADSs. The tests were run in the following sequence:

Configuration 1

Configuration 1 used multiple AMBAs running on a single application server with 2, 4, 8, and 16

instances. The background workload was generated by seven subscribers on the client load server

and five price feeds on the application server.


Figure 3 shows test configuration 1.

SQL Server

Application ServerClient Load Server Application Server 1

ADM

Database TierApplication TierClient Tier

ADS

AMBA

Price Updates

(APH)

Subscribers(PRIME)

Figure 3. Test configuration 1

Configuration 2

Configuration 2 used multiple AMBAs running on a single application server. The background

workload was generated against the ADS by seven subscribers and five price updates running on

the client load server with 2, 4, 8, and 16 instances.


Application ServerClient Load Server

SQL Server

ADM


ADS

AMBA

Price Updates

(APH)

Subscribers(PRIME)



Configuration 3

Configuration 3 used multiple AMBAs running on a single application server. The background

workload was generated against a dedicated ADS by seven subscribers and five price updates

running on the client load server with 2, 4, 8, and 16 instances.

Figure 5 shows the test configuration 3.

Application Server 1Client Load Server

SQL Server

ADM


ADS

ADS

AMBASubscribers

(PRIME)

Price Updates

(APH)


Table 10 shows the measured results for configurations 1, 2, and 3 running various number of

AMBA instances against one ADS.


Table 10. Results for AMBA instances running against a single ADS

Test Description

Configuration 1 Results

(message inserts

per second)


(message inserts

per second)


(message inserts

per second)

2 AMBA instances 216.85 279.81 351.89

4 AMBA instances 274.18 342.62 610.34

8 AMBA instances 340.25 473.75 790.07

16 AMBA instances 522.49 538.92 1011.90

Configuration 4

Configuration 4 used multiple AMBAs running on two application servers. The background

workload was generated against both ADSs by seven subscribers and five price updates running on

the client load server with 2, 4, 8, and 16 instances.


Application Server 1

Application Server 2

Client Load Server

SQL Server

ADM


ADS

AMBA

ADS

AMBA

Price Updates

(APH)

Subscribers(PRIME)

Price Updates

(APH)

Subscribers(PRIME)



Configuration 5

Configuration 5 used multiple AMBAs running on two application servers. The background

workload was generated by seven subscribers and five price updates against a dedicated ADS, all

running on the client load server.


Application Server 1Client Load Server

SQL Server

Application Server 2ADM


ADS

ADS

AMBASubscribers

(PRIME)

Price Updates

(APH) ADS

AMBA


Table 11 shows the measured results for configurations 4 and 5 running various number of AMBA

instances against two ADS application servers.


Table 11. Results for AMBA instances running against two ADSs

Test Description


(message inserts

per second)


(message inserts

per second)

2 x 2 AMBA instances 373.67 657.14




Configuration 6

Using the same deployment scenario as configuration 5 and running four AMBA instances, various

compression options on the trade, additional_info, and trans_hst tables were tested to explore

performance gains.

The configuration that performed best used PAGE compression on the trade, additional_info, and

trans_hst tables, resulting in 981.54 message inserts per second. This configuration was therefore

used to demonstrate the influence of using Fusion-io storage for the data and log files, as shown in

Table 12.

Table 12. Results of position control performance benchmark, configuration 6

Test Description

Results

(message inserts

per second)

2 x 4 AMBA instances (with table compression) 981.54

2 x 4 AMBA instances (with table compression; data on Fusion-io) 831.98

2 x 4 AMBA instances (with table compression; log on Fusion-io) 1117.16

These results confirmed that the overall performance was already optimized and depended on the

speed of the underlying IO system. Moving the transaction log file to a faster storage (Fusion-io) did

improve the performance.


Summary The results of the benchmark testing, highlighted in Table 13, demonstrate that SQL Server 2008 R2

Enterprise provides an excellent database platform for Front Arena.

Table 13. Benchmark testing results

Test Metric Benchmark Results

Exchange trade performance More than 160,000 message inserts per second

Position control performance More than 1,000 trade inserts per second

The high levels of performance and scalability, coupled with the ability to run on industry-standard

servers, confirms that SQL Server 2008 R2 Enterprise is the right database platform for Front Arena

customers who want performance, scalability, and value.


Appendix: Best Practice Guidance This appendix provides some best practices that can be used to optimize Front Arena on a SQL

Server database.

Standard SQL Server Best Practices

Standard best practices apply when deploying Front Arena on SQL Server. For example:

Use a dedicated database server and instance.

Pre-size the database.

Pre-sizing the database to a proper size prevents auto-growth of the database files, which

can cause delays in committing transactions and degrades the throughput. Pre-sizing the

database files also minimizes physical file fragmentation, which can increase disk latency

over time. In particular:

o Pre-size tempdb to a sufficiently large size.

o Ensure that all the files in tempdb are identical in size because SQL Server 2008 R2

Enterprise uses a proportional fill algorithm.

Increase the Filegrowth setting to 50 MB, and ensure that the files have identical

properties.

Add multiple data files to the tempdb filegroup.

Check database integrity regularly.

Use a backup strategy.

Maintain the indexes.

Monitor and address logical fragmentation in the databases.

Watch for conflicting job schedules.

Note that underlying SAN configuration is important, not just the RAID levels.

o Ensure you have the right number of spindles for the I/O load.

o Note that shared and combined SANs might not be optimal.

Additional Best Practices

The following are some additional best practices you should keep in mind when deploying Front

Arena on SQL Server.

Clustered Indexes

Create meaningful clustered indexes on the tables. Clustered indexes change how the database

engine works in several ways. For information on heaps versus clustered indexes, see the following

references:


Comparing Tables Organized with Clustered Indexes versus Heaps, at

http://technet.microsoft.com/en-us/library/cc917672.aspx.

Heap Structures, at http://msdn.microsoft.com/en-us/library/ms188270.aspx.

Clustered Index Structures, at http://msdn.microsoft.com/en-us/library/ms177443.aspx.

Nonclustered Index Structures, at

http://msdn.microsoft.com/en-us/library/ms177484.aspx.

Table and Index Organization, at http://msdn.microsoft.com/en-us/library/ms189051.aspx.

Included Columns

Look for opportunities to use included columns when creating indexes. Included columns can

increase the chance that an index will cover a query, while also reducing the amount of storage

space used (the included columns are only stored at the leaf level of the index, whereas the key

columns are stored at all levels).

Missing Indexes

Check for missing indexes. These can be found from the following dynamic management views

(DMVs):

sys.dm_db_missing_index_groups

sys.dm_db_missing_index_group_stats

sys.dm_db_missing_index_details

Partitioning

In high-volume online transaction processing (OLTP) systems, there is frequently pagelatch

contention (sometimes referred to as a “hot page”). This occurs when there are large volumes of

data written to the end of a clustered index. One way to avoid this is to partition the data on a

secondary key that provides a fairly even distribution of data (it is important to avoid data skew).

You should also look for latch contention on index pages.

Compression

Consider using data compression to reduce disk IO. If IO is a bottleneck in a system and there are

spare CPU cycles, compression might be an option to reduce the amount of time the system is

bound by disk. Compression can be used on tables and indexes, and can be used at the row or page

level.

Disk Latency

For high-throughput OLTP systems, make sure that the write latency on the volume containing the

log file is as low as possible. In the benchmark testing, each trade that was written to the database

caused a log flush. This means that if the log volume write latency is 5 milliseconds, each trade

insert incurs a 5 millisecond stall.

http://technet.microsoft.com/en-us/library/cc917672.aspx

http://msdn.microsoft.com/en-us/library/ms188270.aspx





Disk Layout

If possible, do not put data and log files on the same volume. This is an easy way to improve disk

performance.

ADS Deployment Scenario

During the benchmark testing, better performance was achieved from two ADS instances with four

AMBAs each than from one ADS instance with eight AMBAs. It was also noted that transactional

throughput was impacted if the background workload was running against the same ADS as the

AMBAs.

Lock Pages in Memory

Consider using the “lock pages in memory” option if you are running a 64-bit server with a large

amount of memory. When this setting is enabled, the memory pages that SQL Server holds are not

paged to the disk if there is pressure on the memory.

Instant File Initialization

The “instant file initialization” option lets SQL Server allocate space for data files quickly, without

having to zero out the new space up front. Without this option, if a data file grows by 5 GB, all 5 GB

needs to be initialized with zeros before it can be used. With instant file initialization, the space is

allocated but not initialized until it is actually used. There is some security risk, however. Because

the space on disk is not initialized, anything that existed there before is part of the database file

and can be read with a hex editor. This is not acceptable in certain environments; this option

should therefore only be used when this security risk is not a concern.


Additional Information The following references provide more information about SunGard and Microsoft.

About SunGard SunGard is one of the world’s leading software and technology services companies. SunGard has

more than 20,000 employees and serves more than 25,000 customers in more than 70 countries.

SunGard provides software and processing solutions for financial services, higher education, and

the public sector. SunGard also provides disaster recovery services, managed IT services,

information availability consulting services, and business continuity management software. With

annual revenue of about $5 billion, SunGard is ranked 434 on the Fortune 500, and is the largest

privately held business software and IT services company.

For more information, visit the SunGard home page at www.sungard.com.

About Microsoft Founded in 1975, Microsoft (NASDAQ "MSFT") is the worldwide leader in software, services, and

solutions that help people and businesses realize their full potential.

Microsoft is motivated and inspired every day by how customers use Microsoft software to find

creative solutions to business problems, develop breakthrough ideas, and stay connected to what's

most important to them.

Microsoft runs its business in much the same way, and believes its five business

divisions―Windows & Windows Live, Server and Tools, Online Services, Microsoft Business, and

Entertainment and Devices―offer the greatest potential to serve customers.

For more information, visit the Microsoft home page at

http://www.microsoft.com/en-us/default.aspx.

http://www.sungard.com/

http://www.microsoft.com/en-us/default.aspx

front arena on sql server - microsoft · pdf filefront arena running on sql server 2008 r2...

Documents