Benchmark Testing Results: SunGard Front Arena Running on Microsoft SQL Server

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.

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. Benchmark Testing Results: Microsoft SQL Server 2008 R2 Enterprise and SunGard Front Arena ii

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, highspeed, 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 enterpriseclass 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.

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, coarsegrained 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. Benchmark Testing Results: Microsoft SQL Server 2008 R2 Enterprise and SunGard Front Arena 2

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 Arena Extension Framework (AEF) Arena Integration Framework (AIF) Arena Data Model (ADM) Arena Market Access Server (AMAS) Arena Data Server (ADS) Arena Message Broker Adapter (AMBA) Description AEF is a complete set of development tools, programming interfaces, and extension points that enable functional enhancements to Front Arena. AIF provides access to data streams and services. 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. AMAS is responsible for handling the two-way traffic flow from and into an exchange (for example, NASDAQ). ADS is the application server responsible for event propagation, logging, and interaction with the underlying database. 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. Benchmark Testing Results: Microsoft SQL Server 2008 R2 Enterprise and SunGard Front Arena 3

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 costs 3 SQL Server database administrators (DBAs) can typically manage three times as many physical databases as a competitor s DBAs. 4 Lower maintenance costs 5 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/ Benchmark Testing Results: Microsoft SQL Server 2008 R2 Enterprise and SunGard Front Arena 4

POWER POWER SUPPLY SUPPLY DIMMS UID PROC FANS PROC DIMMS 1 2 PPM INTER LOCK OVER TEMP I-PPM PCI RISER CAGE 1 2 3 4 5 6 7 8 HP ProLiant DL385 G5 POWER POWER SUPPLY SUPPLY DIMMS UID POWER POWER SUPPLY SUPPLY DIMMS UID PROC PROC FANS FANS PROC PROC DIMMS DIMMS 1 2 1 2 PPM PPM INTER LOCK OVER TEMP I-PPM INTER LOCK OVER TEMP I-PPM PCI RISER CAGE PCI RISER CAGE 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 System x3550 HP ProLiant DL385 G5 HP ProLiant DL385 G5 POWER POWER SUPPLY SUPPLY DIMMS UID PROC FANS PROC DIMMS 1 2 PPM INTER LOCK OVER TEMP I-PPM PCI RISER CAGE 1 2 3 4 5 6 7 8 HP ProLiant DL385 G5 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. Back-End Tier (Database) Middle Tier (Application) Front-End Tier (Clients) App1 HP ProLiant DL380 G7 12 x 2.8 GHz (Hyper-threading on) 64 GB RAM Database Server HP ProLiant DL380 G7 12 x 2.8 GHz 64 GB RAM Brocade Silkwom Switch Database 100 x 15k RPM drives RAID10 800 GB 1GB/s Network App2 HP ProLiant DL380 G7 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 Temp DB 48 x 15k RPM drives RAID10 600 GB Logs 26 x 15k RPM drives RAID10 400 GB Xiotech Magnitude3D 3000s Domain Controller Dell PowerEdge 1850 4 x 3.40 GHz 4 GB RAM Figure 2. Benchmark test infrastructure Benchmark Testing Results: Microsoft SQL Server 2008 R2 Enterprise and SunGard Front Arena 5

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 RAM NICs Storage Area Network: Xiotech Magnitude 3D 3000 SSD storage 12 x 2.8 GHz (2 x 6 cores) 64 GB Broadcom NC3821 1 GbE 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 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 RAM NICs Local storage 12 x 2.8 GHz (2 x 6 cores, hyper-threading enabled) 64 GB Broadcom NC3821 1 GbE 200 GB 2 x 300 GB, 10k SAS drives, RAID10 Software Windows Server 2008 R2 Enterprise SunGard Front Arena Benchmark Testing Results: Microsoft SQL Server 2008 R2 Enterprise and SunGard Front Arena 6

Table 4 provides details of the hardware and software in the client servers. Table 4. Details of client servers Client Servers Hardware CPU RAM NICs Local storage 12 x 2.8 GHz (2 x 6 cores, hyper-threading enabled) 64 GB Broadcom NC3821 1 GbE 200 GB, 2 x 300 GB, 10k SAS drives, RAID10 Software Windows Server 2008 R2 Enterprise 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 AMAS Description 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 PRIME client Subscription load generators Price update load generator AMBA was used to simulate the incoming exchange trade messages and persist these as trades into the database through the ADS. The PRIME client is the proprietary Front Arena trading and risk management tool. 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). 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 Testing Results: Microsoft SQL Server 2008 R2 Enterprise and SunGard Front Arena 7

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 Count Size Threads Bulk copy (BCP) setting Pack count Description Number of messages to insert Size of each message Number of threads used for inserting messages into the database Set at 0 for stored procedure inserts and at 1 for bulk inserts 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. Benchmark Testing Results: Microsoft SQL Server 2008 R2 Enterprise and SunGard Front Arena 8

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. Benchmark Testing Results: Microsoft SQL Server 2008 R2 Enterprise and SunGard Front Arena 9

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 BCP SeqNoPrefix Number of applications* Results (Message inserts per second) 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 Benchmark Testing Results: Microsoft SQL Server 2008 R2 Enterprise and SunGard Front Arena 10

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 BCP SeqNoPrefix Number of applications* Results (Message inserts per second) 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. Benchmark Testing Results: Microsoft SQL Server 2008 R2 Enterprise and SunGard Front Arena 11

Figure 3 shows test configuration 1. Client Tier Application Tier Database Tier Client Load Server Application Server 1 Application Server Subscribers (PRIME) AMBA SQL Server Price Updates (APH) ADS ADM 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. Figure 4 shows test configuration 2. Client Tier Application Tier Database Tier Client Load Server Subscribers (PRIME) Application Server AMBA SQL Server Price Updates (APH) ADS ADM Figure 4. Test configuration 2 Benchmark Testing Results: Microsoft SQL Server 2008 R2 Enterprise and SunGard Front Arena 12

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. Client Tier Application Tier Database Tier Client Load Server Subscribers (PRIME) Application Server 1 AMBA ADS SQL Server ADS ADM Price Updates (APH) Figure 5. Test configuration 3 Table 10 shows the measured results for configurations 1, 2, and 3 running various number of AMBA instances against one ADS. Benchmark Testing Results: Microsoft SQL Server 2008 R2 Enterprise and SunGard Front Arena 13

Table 10. Results for AMBA instances running against a single ADS Test Description Configuration 1 Results (message inserts per second) Configuration 2 Results (message inserts per second) Configuration 3 Results (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. Figure 6 shows test configuration 4. Client Tier Application Tier Database Tier Client Load Server Subscribers (PRIME) Application Server 1 AMBA Price Updates (APH) ADS SQL Server Subscribers (PRIME) Application Server 2 AMBA ADM Price Updates (APH) ADS Figure 6. Test configuration 4 Benchmark Testing Results: Microsoft SQL Server 2008 R2 Enterprise and SunGard Front Arena 14

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. Figure 7 shows test configuration 5. Client Tier Application Tier Database Tier Client Load Server Subscribers (PRIME) Application Server 1 AMBA ADS SQL Server ADS Application Server 2 ADM AMBA Price Updates (APH) ADS Figure 7. Test configuration 5 Table 11 shows the measured results for configurations 4 and 5 running various number of AMBA instances against two ADS application servers. Benchmark Testing Results: Microsoft SQL Server 2008 R2 Enterprise and SunGard Front Arena 15

Table 11. Results for AMBA instances running against two ADSs Test Description Configuration 4 Results (message inserts per second) Configuration 5 Results (message inserts per second) 2 x 2 AMBA instances 373.67 657.14 2 x 4 AMBA instances 629.26 920.77 2 x 8 AMBA instances 832.63 1039.59 2 x 16 AMBA instances 902.37 883.94 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. Benchmark Testing Results: Microsoft SQL Server 2008 R2 Enterprise and SunGard Front Arena 16

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 Position control performance More than 160,000 message inserts per second 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. Benchmark Testing Results: Microsoft SQL Server 2008 R2 Enterprise and SunGard Front Arena 17

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 o Pre-size tempdb to a sufficiently large size. 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 o Ensure you have the right number of spindles for the I/O load. 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: Benchmark Testing Results: Microsoft SQL Server 2008 R2 Enterprise and SunGard Front Arena 18

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. Benchmark Testing Results: Microsoft SQL Server 2008 R2 Enterprise and SunGard Front Arena 19

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. Benchmark Testing Results: Microsoft SQL Server 2008 R2 Enterprise and SunGard Front Arena 20

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. Benchmark Testing Results: Microsoft SQL Server 2008 R2 Enterprise and SunGard Front Arena 21