Performance Report PRIMERGY TX200 S4

Transcription

1 Performance Report PRIMERGY TX200 S4 Version 2.1 February 2008 Pages 28 Abstract This document contains a summary of the benchmarks executed for the PRIMERGY TX200 S4. The PRIMERGY TX200 S4 performance data are compared with the data of other PRIMERGY models and discussed. In addition to the benchmark results, an explanation has been included for each benchmark and for the benchmark environment. Contents Technical Data...2 SPECcpu SPECjbb StorageBench...8 OLTP Terminal Server...21 Literature...28 Contact...28

2 Technical Data The PRIMERGY TX200 S4 is a low-priced dual socket tower server with an Intel 5000Z chipset, two Intel Dual-Core or Quad-Core Xeon processors, up to 24 GB 2-way interleaved ECC DDR2-SDRAM PC2-5300F, a front-side bus with 1067 or 1333 MHz timing - depending on the processor used, an onboard 4-port SATA controller with RAID 0, 1 and RAID 10 as well as optional RAID 5 functionality for four 3.5 SATA hard disks or an onboard 8-port SAS controller with RAID 0, 1 and RAID 1E functionality or an onboard 8-port SAS controller with RAID 0, 1, 10, 5, 50, 6 and RAID 60 functionality for up to or six 3.5 hard disks, an onboard Broadcom GBit Ethernet controller and seven PCI slots (4 PCIe x8, 2 PCI-X 64-bit/100 MHz and 1 PCI 32-bit/33 MHz). As well as its forerunner PRIMERGY TX200 S3 it can be converted quickly and easily into a rack system for integration in 19-inch racks, but with its height of 5 units still requires more space than the PRIMERGY TX200 S3. See for detailed technical information. Fujitsu Technology Solutions 2009 Page 2 (28)

3 SPECcpu2006 Benchmark description SPECcpu2006 is a benchmark to measure system efficiency during integer and floating point operations. It consists of an integer test suite containing 12 applications and a floating point test suite containing 17 applications which are extremely computing-intensive and concentrate on the CPU and memory. Other components, such as disk I/O and network, are not measured by this benchmark. SPECcpu2006 is not bound to a specific operating system. The benchmark is available as source code and is compiled before the actual benchmark. Therefore, the compiler version used and its optimization settings have an influence on the measurement result. SPECcpu2006 contains two different methods of performance measurement: The first method (SPECint2006 and SPECfp2006) determines the time required to complete a single task. The second method (SPECint_rate2006 and SPECfp_rate2006) determines the throughput, i.e. how many tasks can be completed in parallel. Both methods are additionally subdivided into two measuring runs, "base" and "peak", which differ in the way the compiler optimization is used. The "base" values are always used when results are published, the "peak" values are optional. Benchmark Arithmetic Type Compiler optimization SPECint2006 integer peak aggressive SPECint_base2006 integer base conservative SPECint_rate2006 integer peak aggressive SPECint_rate_base2006 integer base conservative SPECfp2006 floating point peak aggressive SPECfp_base2006 floating point base conservative SPECfp_rate2006 floating point peak aggressive SPECfp_rate_base2006 floating point base conservative Measuring result speed throughput speed throughput Application single threaded multithreaded single threaded multithreaded The results represent the geometric mean of normalized ratios determined for the individual benchmarks. Compared with the arithmetic mean, the geometric mean results in the event of differingly high single results in a weighting in favor of the lower single results. Normalized means measuring how fast the test system runs in comparison to a reference system. The value of 1 was determined for the SPECint_base2006, SPECint_rate_base2006, SPECfp_base2006 and SPECfp_rate_base2006 results of the reference system. Thus a SPECint_base2006 value of 2 means for example that the measuring system has executed this benchmark approximately twice as fast as the reference system. A SPECfp_rate_base2006 value of 4 means that the measuring system has executed this benchmark about 4/[# base copies] times as fast as the reference system. # base copies here specifies how many parallel instances of the benchmark have been executed. We do not submit all SPECcpu2006 measurements for publication at SPEC. So not all results appear on SPEC s web sites. As we archive the log data for all measurements, we are able to prove the correct realization of the measurements any time. Benchmark results The PRIMERGY TX200 S4 was measured with three different processor versions of the Xeon series: Xeon E5205 (Wolfdale, 2 cores per chip, 6 MB L2 cache per chip) Xeon L5310 and L5335 (Clovertown, 4 cores per chip, 8 MB L2 cache per chip) Xeon E5405 and E5420 (Harpertown, 4 cores per chip, 12 MB L2 cache per chip) The benchmark programs were compiled with the Intel C++/Fortran compiler 10.1 and run under SUSE Linux Enterprise Server 10 SP1 (64-bit). SPEC, SPECint, SPECfp and the SPEC logo are registered trademarks of the Standard Performance Evaluation Corporation (SPEC). Fujitsu Technology Solutions 2009 Page 3 (28)

4 SPECint_rate_base2006 SPECint_rate2006 Processor Cores GHz L2 cache FSB TDP 1 chip 2 chips 1 chip 2 chips Xeon E MB per chip 1067 MHz 65 watt n/a 41.9 n/a 50.2 Xeon L MB per chip 1067 MHz 50 watt n/a 59.5 n/a 70.5 Xeon L MB per chip 1333 MHz 50 watt n/a 70.5 n/a 84.0 Xeon E MB per chip 1333 MHz 80 watt n/a 77.9 n/a 96.4 Xeon E MB per chip 1333 MHz 80 watt n/a 88.9 n/a 110 (est.) The SPECint_rate_2006 results with the Wolfdale processor are 20% above the SPECint_rate_base2006 results, with the Clovertown processors 18-19% above and with the Harpertown processors 24% above. SPECfp_rate_base2006 SPECfp_rate2006 Processor Cores GHz L2 cache FSB TDP 1 chip 2 chips 1 chip 2 chips Xeon E MB per chip 1067 MHz 65 watt n/a 32.8 n/a 36.1 Xeon L MB per chip 1067 MHz 50 watt n/a 40.5 n/a 44.2 Xeon L MB per chip 1333 MHz 50 watt n/a 46.8 n/a 51.7 Xeon E MB per chip 1333 MHz 80 watt n/a 49.6 n/a 55.8 Xeon E MB per chip 1333 MHz 80 watt n/a 56.5 n/a 63.6 (est.) The SPECfp_rate_2006 results with the Wolfdale processor are 10% above the SPECfp_rate_base2006 results, with the Clovertown processors 9-10% above and with the Harpertown processors 13% above. The Xeon processor versions of the PRIMERGY TX200 S4 not only differ in their internal clock rate, but also in the number of cores, the size of the L2 cache and in the timing of the front-side bus. Only within the group of Harpertown processors is the processor performance completely dependent on the processor clock rate. Here, with the integer Test Suite, the increase in the processor clock rate to 57% and 56% with the Floating Point Test Suite is converted into additional performance. Fujitsu Technology Solutions 2009 Page 4 (28)

5 When comparing the PRIMERGY TX200 S4 and its predecessor the PRIMERGY TX200 S3 both in their highest performance configurations, an increase is noted in the integer test suite of +21% with SPECint_rate_base2006 and +39% with SPECint_rate2006. Benchmark environment All SPECcpu2006 measurements were performed on a PRIMERGY TX200 S4 with the following hardware and software configuration: Hardware Model CPU PRIMERGY TX200 S4 Xeon E5205, Xeon L5310 and L5335, Xeon E5405 and E5420 Number of CPUs 2 Primary Cache 32 kb instruction + 32 kb data on chip, per core Xeon E5205: 6 MB (I+D) on chip, per chip Secondary Cache Xeon L5310 and L5335: 8 MB (I+D) on chip, per chip Xeon E5405 and E5420: 12 MB (I+D) on chip, per chip Other Cache none Memory 4 x 4 GB PC2-5300F DDR2-SDRAM Software Operating System SUSE Linux Enterprise Server 10 SP1 (64-bit) Compiler Intel C++/Fortran Compiler 10.1 Fujitsu Technology Solutions 2009 Page 5 (28)

6 SPECjbb2005 Benchmark description SPECjbb2005 is a Java business benchmark that focuses on the performance of Java server platforms. It is essentially a modernized version of SPECjbb2000 with the main differences being: The transactions have become more complex in order to cover a greater functional scope. The working set of the benchmark has been enlarged to the extent that the total system load has increased. SPECjbb2000 allows only one active Java Virtual Machine instance (JVM), whereas SPECjbb2005 permits several instances, which in turn achieves greater closeness to reality, particularly with large systems. On the software side SPECjbb2005 measures the implementations of the JVM, JIT (Just-In-Time) compiler, garbage collection, threads and some aspects of the operating system. As far as hardware is concerned, it measures the efficiency of the CPUs and caches, the memory subsystem and the scalability of shared memory systems (SMP). Disk and network I/O are irrelevant. SPECjbb2005 emulates a 3-tier client/server system that is typical for modern business process applications with emphasis on the middle tier system: Clients generate the load, consisting of driver threads, which on the basis of the TPC-C benchmark generate OLTP accesses to a database without thinking times. The middle-tier system implements the business processes and the updating of the database. The database takes on the data management and is emulated by Java objects that are in the memory. Transaction logging is implemented on an XML basis. The major advantage of this benchmark is that it includes all three tiers that run together on a single host. The performance of the middle tier is measured, thus avoiding large-scale hardware installations and making direct comparisons possible between SPECjbb2005 results of different systems. Client and database emulation are also written in Java. SPECjbb2005 only needs the operating system as well as a Java Virtual Machine with J2SE 5.0 features. The scaling unit is a warehouse with approx. 25 MB Java objects. Precisely one Java thread per warehouse executes the operations on these objects. The business operations are assumed by TPC-C: New Order Entry Payment Order Status Inquiry Delivery Stock Level Supervision Customer Report However, these are the only features SPECjbb2005 and TPC-C have in common. The results of the two benchmarks are not comparable. SPECjbb2005 has 2 performance metrics: bops (business operations per second) is the overall rate of all business operations performed per second. bops/jvm is the ratio of the first metrics and the number of active JVM instances. In comparisons of various SPECjbb2005 results it is necessary to state both metrics. The following rules, according to which a compliant benchmark run has to be performed, are the basis for these metrics: A compliant benchmark run consists of a sequence of measuring points with an increasing number of warehouses (and thus of threads) with the number in each case being increased by one warehouse. The run is started at one warehouse up through 2*MaxWhm but not less than 8 warehouses. MaxWhm is the number of warehouses with the highest operation rate per second the benchmark expects. Per default the benchmark equates MaxWH with the number of CPUs visible by the operating system. The metrics bops is the arithmetic average of all measured operation rates with between MaxWhm warehouses and 2*MaxWhm warehouses. SPEC, SPECjbb and the SPEC logo are registered trademarks of the Standard Performance Evaluation Corporation (SPEC). Fujitsu Technology Solutions 2009 Page 6 (28)

7 Benchmark results In November 2007 the PRIMERGY TX200 S4 was measured with two Xeon X5420 processors and a memory of 16 GB PC2-5300F DDR2-SDRAM. The measurement was taken under Windows Server 2003 Enterprise x64 Edition R2 + SP1. As JVM, one instance of JRockit(R) 6.0 P (build P _ windows-x86_64) by BEA was used. The benchmark results include all the measuring values from two to four warehouses. When the PRIMERGY TX200 S4 is compared to its predecessor the PRIMERGY TX200 S3, a throughput increase of +35% exists in the respective top performance configurations. Benchmark environment The SPECjbb2005 measurements were performed on a PRIMERGY TX200 S4 with the following hardware and software configuration: Hardware Model CPU Number of chips Primary Cache Secondary Cache Other Cache Memory Software Operating System JVM Version PRIMERGY TX200 S4 Xeon X chips, 8 cores, 4 cores per chip 32 kb instruction + 32 kb data on chip, per core 12 MB (I+D) on chip, per chip none 4 x 4 GB PC2-5300F DDR2-SDRAM Windows Server 2003 Enterprise x64 Edition R2 + SP1 BEA JRockit(R) 6.0 P (build P _ windows-x86_64) Fujitsu Technology Solutions 2009 Page 7 (28)

8 StorageBench Benchmark description To estimate the capability of disk subsystems Fujitsu Technology Solutions defined a benchmark called StorageBench to compare the different storage systems connected to a system. To do this StorageBench makes use of the Iometer measuring tool developed by Intel combined with a defined set of load profiles that occur in real customer applications and a defined measuring scenario. Measuring tool Since the end of 2001 Iometer has been a project at and is ported to various platforms and enhanced by a group of international developers. Iometer consists of a user interface for Windows systems and the socalled dynamo which is available for various platforms. For some years now it has been possible to download these two components under Intel Open Source License from or Iometer gives you the opportunity to reproduce the behavior of real applications as far as accesses to IO subsystems are concerned. For this purpose, you can among other things configure the block sizes to be used, the type of access, such as sequential read or write, random read or write and also combinations of these. As a result Iometer provides a text file with comma separated values (.csv) containing basic parameters, such as throughput per second, transactions per second and average response time for the respective access pattern. This method permits the efficiency of various subsystems with certain access patterns to be compared. Iometer is in a position to access not only subsystems with a file system, but also so-called raw devices. With Iometer it is possible to simulate and measure the access patterns of various applications, but the file cache of the operating system remains disregarded and operation is in blocks on a single test file. Load profile The manner in which applications access the mass storage system considerably influences the performance of a storage system. Examples of various access patterns of a number of applications: Application Database (data transfer) Database (log file) Backup Restore Video streaming File server Web server Operating system File copy Access pattern random, 67% read, 33% write, 8 kb (SQL Server) sequential, 100% write, 64 kb blocks sequential, 100% read, 64 kb blocks sequential, 100% write, 64 kb blocks sequential, 100% read, blocks 64 kb random, 67% read, 33% write (blocks 8 kb) random, 100% read, 64 kb blocks random, 40% read, 60% write, blocks 4 kb random, 50% read, 50% write, 64 kb blocks From this four distinctive profiles were derived: Load profile Access Access pattern Block Load read write size tool Streaming sequential 100% 64 kb Iometer Restore sequential 100% 64 kb Iometer Database random 67% 33% 8 kb Iometer File server random 67% 33% 64 kb Iometer All four profiles were generated with Iometer. Fujitsu Technology Solutions 2009 Page 8 (28)

9 Measurement scenario In order to obtain comparable measurement results it is important to perform all the measurements in identical, reproducible environments. This is why StorageBench is based, in addition to the load profile described above, on the following regulations: Since real-life customer configurations work only in exceptional situations with raw devices, performance measurements of internal disks are always conducted on disks containing file systems. NTFS is used for Windows and ext3 for Linux, even if higher performance could possibly be achieved with other file systems or raw devices. Hard disks are among the most error-prone components of a computer system. This is why RAID controllers are used in server systems in order to prevent data loss through hard disk failure. Here several hard disks are put together to form a Redundant Array of Independent Disks, known as RAID in short with the data being spread over several hard disks in such a way that all the data is retained even if one hard disk fails. The most usual methods of organizing hard disks in arrays are the RAID levels RAID 0, RAID 1, RAID 5, RAID 6, RAID 10, RAID 50 and RAID 60. Information about the basics of various RAID arrays is to be found in the paper Performance Report - Modular RAID for PRIMERGY. Depending on the number of disks and the installed controller, the possible RAID configurations are used for the StorageBench analyses of the PRIMERGY servers. For systems with two hard disks we use RAID 1 and RAID 0, for three and more hard disks we also use RAID 1E and RAID 5 and for four and more hard disks we also use RAID 6, RAID 10, RAID 50 und RAID 60 provided that the controller supports these RAID levels. Regardless of the size of the hard disk, a measurement file with the size of 8 GB is always used for the measurement. In the evaluation of the efficiency of I/O subsystems, processor performance and memory configuration do not play a significant role in today s systems - a possible bottleneck usually affects the hard disks and the RAID controller, and not CPU and memory. Therefore, various configuration alternatives with CPU and memory need not be analyzed under StorageBench. Measurement results For each load profile StorageBench provides various key indicators: e.g. data throughput in megabytes per second, in short MB/s, transaction rate in I/O operations per second, in short IO/s, and latency time or also mean access time in ms. For sequential load profiles data throughput is the normal indicator, whereas for random load profiles with their small block sizes the transaction rate is normally used. Throughput and transaction rate are directly proportional to each other and can be calculated according to the formula Data throughput [MB/s] Transaction rate [Disk-I/O s -1 ] = Transaction rate [Disk-I/O s -1 ] Block size [MB] = Data throughput [MB/s] / Block size [MB] Benchmark results The Modular RAID concept is used in the PRIMERGY TX200 S4. The specific RAID solutions that used to be normal for individual servers of the PRIMERGY family were replaced by a Modular RAID concept for all servers. The variety of the RAID solutions enables the user to choose the right controller for his application scenario. The PRIMERGY TX200 S4 has the following RAID solutions to offer: 1. SATA RAID Onboard Controller is directly implemented on the motherboard of the server in the chip set. This RAID solution is only foreseen for the connection of SATA hard disks. Support is provided for RAID levels 0, 1 and 10 as well as for RAID 5 with an additional ibutton. 2. RAID Controller LSI MegaRAID SAS 1068 is supplied as a PCI Express card. Both SATA and SAS hard disks can be connected. Support is provided for RAID levels 0, 1 and 1E. The controller does not have a cache. 3. RAID Controller LSI MegaRAID SAS 1078 is supplied as a PCI Express card and offers the user a complete RAID solution. Both SATA and SAS hard disks can be connected. Support is provided for RAID levels 0, 1, 5, 6, 10, 50 and 60. Two different versions of this controller are on offer with either a 256 MB or 512 MB cache. The controller cache can be protected against power failure by an optional BBU. The PRIMERGY TX200 S4 offers four hot-plug bays for 3½ SAS or SATA hard disks. Optionally, an extension box is available with additional hot-plug bays (2 or 4 3½ or 8 2½ ). SAS hard disks with a capacity of 36, 73 and 146 GB (2.5, 10 krpm) as well as 73, 146 and 300 GB (3.5, 10 krpm or 15 krpm) and SATA hard disks with a capacity of 160, 250, 500 and 750 GB (3.5, 7,200 rpm) can be used. Fujitsu Technology Solutions 2009 Page 9 (28)

10 In the measurements performed to compare the controllers and the RAID levels SAS hard disks from Seagate (ST373455SS, 3½, 15 krpm, maximum throughput 125 MB/s and ST973402SS, 2½, 10 krpm, maximum throughput 89 MB/s) were used. Both hard disks have a 16 MB disk cache and 73 GB capacity. SATA hard disks from Western Digital (WD1600AAJS) were used. The WD1600AAJS hard disk has an 8 MB disk cache, 160 MB capacity and a rotational speed of 7,200 rpm. Disk cache In most cases, enabling the disk cache entails an increase in throughput for write access. However, besides the increase in performance, enabling the disk cache (Disk Cache=enabled) also has disadvantages. If a fault occurs in the power supply, important data that has not yet been written from the disk cache to the hard disk may possibly be irrevocably lost. This is why it is advisable to ensure a continuous power supply for the hard disks by activating a UPS upstream. If the system is UPS-protected, enabling the disk cache for performance reasons is recommended. Controller cache In contrast to the LSI MegaRAID SAS 1068 controller, the LSI MegaRAID SAS 1078 controller provides a controller cache in both versions, which as an optional extra can be protected against power failure by a battery backup unit (BBU). The controller cache is used to increase write and read performance and can be influenced by three configuration parameters. Write Mode The term Write mode summarizes the write setting options of the controller cache. There are three possible write cache settings: write-through, write-back and write cache bad BBU. The option write-through ensures that each write order is only acknowledged by the controller when it has really been written onto the hard disk. With the options write-back and write cache bad BBU the orders are buffered in the controller cache and immediately acknowledged to the user as done, although in reality they do not exist on the hard disk at all, but are only written there later. This procedure allows the controller resources to be optimally utilized, a faster sequence in the write orders and thus a higher throughput. Any power failures can be bridged by an optional BBU so as to ensure data integrity in the controller cache. The write cache bad BBU option also enables the write cache when the battery of the BBU is empty or no BBU has been installed, whereas the write-back option automatically switches to write-through when the controller cache does not have a battery buffer. Read Mode The parameter Read mode can be used to influence the cache behavior during read. Three options are available No read ahead, Read ahead and Adaptive. In case a data block is requested by the operating system, Read ahead causes other sequential data blocks to already be prophylactically read from the hard disk into the controller cache in the hope that the operating system requests these in subsequent orders. With the setting Adaptive the controller itself attempts to determine whether a Read-ahead is sensible or not. With No read ahead the Read ahead function is disabled, that is to say no caching of any further sequential blocks takes place during read. Cache Mode The parameter Cache Mode - only referred to in short in the web BIOS of the controller with I/O Cache also influences the read behavior of the controller cache. The Direct option determines that the data to be read is read directly from the hard disk and is also not stored in the controller cache. The alternative Cached causes an attempt to be first made to find the data in the controller cache and to satisfy the read order before accessing the hard disk and with all the data being written into the controller cache in order to be available for subsequent read orders. RAID levels The best throughput can be achieved with a RAID 0. As the number of hard disks in an array increases, so does the throughput. The increase in throughput is achieved through the parallel accesses to the hard disks. RAID 0 makes the entire hard disk capacity available to the user (0% overhead). The disadvantage is that a RAID 0 has no redundancy whatever to offer. If a RAID 0 hard disk fails, all the data is lost. RAID 0 is typically only used when data security plays a subordinate role or the data is otherwise backed up. A RAID 1 ensures complete data redundancy on two hard disks. In the best case the read throughput is equivalent to the total of the throughput of the two hard disks. The write throughput is equivalent to the throughput of one hard disk in an array. The disadvantage is that only half the overall array capacity is available to the user (50% overhead). A RAID 1E ensures full data redundancy on more than two hard disks. The read and write throughput is as with a RAID 1. The advantage is that you can also mirror an uneven number of hard disks. The disadvantage, similar to that of RAID 1, is that only half the overall capacity is available to the user (50% overhead). A RAID 5 consists of at least three hard disks. The data and additionally calculated parity information are distributed over all existing hard disks. A RAID 5 provides a high degree of data security. The capacity overhead is 100 / number of hard disks in the RAID 5 array [%]. Fujitsu Technology Solutions 2009 Page 10 (28)

11 A RAID 6 is an extension to a RAID 5 and ensures that no data is lost if two hard disks fail at the same time. A RAID 6 ensures a high degree of security, but in comparison with a RAID 5 throughput is less with the RAID 6. The capacity overhead is 200 / number of hard disks in the RAID 6 array [%]. A RAID 10 is made up of at least two RAID 1s, which are in turn combined to form a RAID 0 and offers optimal performance with the best possible fail-safety. With a RAID 10 only half the overall capacity is available (capacity overhead 50%). A RAID 50 consists of at least two RAID 5s, which are in turn combined to form a RAID 0. The capacity overhead is twice as large as with a RAID 5. The RAID 60 is a combination of the RAID 6 and RAID 0. The features of the RAID 6 remain unchanged and the fail safety increases in comparison with the RAID 6 and RAID 50. However, throughput is lower than with a RAID 50 and the capacity overhead is twice as large as with the RAID 6. A detailed explanation of how the individual RAID levels work is in the white paper entitled Performance Report - Modular RAID for PRIMERGY. LSI MegaRAID SAS 1078 Controller There are two versions of the LSI MegaRAID SAS 1078 controller, one with a 256 MB and one with a 512 MB controller cache. The cache data can be backed up with a BBU. The controller supports all popular RAID levels: 0, 1, 5, 6, 10, 50 and 60. Up to eight SAS or SATA hard disks can be connected to the controller. The RAID array defines the way in which data is treated as regards availability. How quickly the data is transported in the respective RAID array context depends largely on the data throughput of the hard disks. Throughput can in part be considerably increased through the cache settings. However, this increase in throughput varies according to data structure and access pattern. The following diagram shows the throughputs in a RAID 0 array with two and four 3.5 SAS hard disks for the various load profiles and influences of the cache settings. LSI MegaRAID SAS 1078 with 512 MB cache By enabling the caches it is possible to increase the write throughput several times over. In this case enabling the disk cache makes a decisive contribution toward increasing the throughput. However, maximum write throughput is only achieved with the combination of the cache settings»disk-cache enabled«,»write-back«und»i/o cached«(see Cache Settings: Setting h ), which is equivalent to an optimal cache setting for sequential write access. In comparison with write throughput with the cache disabled three-fold throughput is achieved in this way. On the other hand, the read throughput in a RAID 0 array with two hard disks cannot be relevantly influenced with cache settings. Read throughput achieves the maximum possible throughput values of about 250 MB/s (2 125 MB/s) regardless of the cache setting. The increase in throughput with optimal cache settings is about 15% for random access with 67% read share and 8 kb blocks and about 20% for random access with 67% read share and 64 kb blocks. In a RAID 0 with four 3.5 hard disks you can see the negative impact of the Write-back setting. In this case, the read throughput falls - in comparison with the maximum possible value - by about 8%. The write throughput achieved with the optimal cache settings is only just below the maximum possible write throughput. In comparison with the throughput achieved with disabled caches throughput has been improved about 8.7-fold. Enabling the disk cache makes itself largely felt in random access with 67% read share and the increase in throughput amounts to about 25% with the 8 kb blocks and about 35% with the 64 kb blocks. Fujitsu Technology Solutions 2009 Page 11 (28)

12 The direct comparison of the RAID 0 arrays with two and four 3.5 hard disks shows that the throughput can be doubled with an increasing number of hard disks and an optimal cache setting for sequential read/write access. LSI MegaRAID SAS 1078 with 512 MB cache The throughput of the 2.5 hard disks shows the same dependence on the cache settings as with the 3.5 hard disks. The diagram shows the throughputs of the RAID 0 arrays with two and four 2.5 (10 krpm) and 3.5 (15 krpm) hard disks with optimal cache settings and disabled controller caching features. Here you can see that the 2.5 hard disks with optimal cache settings have achieved maximum possible throughput with read / write access and 64 KB blocks. A significant increase in performance through cache setting optimization can be achieved with sequential write in particular. The throughput of the 3.5 hard disks compared with the 2.5 hard disks with optimal cache settings is about 51% better for sequential read access, 45% for sequential write access and on average 14% better for random access with 8 KB blocks and 19% better with 64 KB blocks. Of course the 3.5 hard disks benefit above all here from the higher rotational speed of 15,000 rpm compared with the slower rotating 2.5 hard disks with 10,000 rpm. The following diagram shows the throughputs of the 3.5 hard disks in a RAID 1 with two hard disks. The read throughput has reached the maximum possible throughput value of 125 MB/s. The diagram shows that the cache settings only have marginal influence on the read throughput. On the other hand, write throughput depends very much on the cache settings. To achieve optimal performance you need to use the optimal cache settings Write-back, I/O direct and Disk- Cache enabled. The improvement achieved in this way is about 60%. The same marked dependence of throughput on the cache settings can also be seen in random access with 64 kb blocks. The optimal cache settings increase throughput by about 50%. LSI MegaRAID SAS 1078 with 512 MB cache Fujitsu Technology Solutions 2009 Page 12 (28)

13 The importance of optimal cache settings can be seen particularly clearly with RAID 5. The diagram shows that sequential write throughput increases considerably as a result of enabling the controller cache with the option Write-back and achieves even higher values than with sequential read, although an additional parity block has to be calculated and written for write. On the other hand, the cache settings have less impact on throughput with sequential read. It is interesting to see how counterproductive the effect of enabling the I/O cache is on throughput - particularly for reads. A marked dependence of throughput on the cache settings can also be found in random access with 64 kb blocks. The optimal cache settings increase throughput by about 40%. LSI MegaRAID SAS 1078 with 256 MB cache The RAID 6 is used in order to further improve fail-safety in comparison with the RAID 5. This ensures that that no data is lost even if two hard disks in an array fail. The dependence of throughput on the cache settings, as depicted in the diagram, is very similar in the RAID 5 and RAID 6. However, the impact of the enabled I/O cache is not as pronounced with the RAID 6 as is the case with the RAID 5. As a result of writing an additional parity block the read and write throughput with the RAID 6 is somewhat lower than with a RAID 5 array. Whereas the throughput for random access is approximately the same with both arrays, the differences in throughput for sequential read and write accesses are higher. The read throughput with optimal cache settings is about 24% higher with the RAID 5 and write throughput even 40% higher than with the RAID 6. LSI MegaRAID SAS 1078 with 256 MB cache Fujitsu Technology Solutions 2009 Page 13 (28)

14 A further solution that ensures high data security and high data throughputs is RAID 10. However, the capacity overhead is 50%. The following diagram compares the throughputs for a RAID 10 with four and six hard disks. The dependence of throughput on the cache settings, as depicted in the diagram, behaves in the same way for the RAID 10 with four or six LSI MegaRAID SAS 1078 with 256 MB cache hard disks. The read throughput for sequential read is approximately equivalent to the maximum throughput of the 2.5 hard disks. Extending the RAID 10 by two hard disks, in other words by 50%, also entails a 50% throughput increase. In the event of an optimal cache setting with a Write-back option, the same also applies for the throughput for sequential write. On the other hand, for random access with 67% read share the throughputs only increase on average by about 20%. The following diagram compares the throughputs of a RAID 50 and RAID 60. LSI MegaRAID SAS 1078 with 512 MB cache With optimal cache settings the RAID 50 achieves an approximately 55% better throughput for sequential read than the RAID 60. For sequential write, and if all caches are enabled, throughput is even 88% better. For random access with 67% read share the two RAID arrays are on average approximately level. Capacity load for the RAID 50 is higher than with the RAID 60. The capacity overhead for the RAID 50 in percent is / numbr of hard disks in the RAID 50 array and for the RAID / number of hard disks in the RAID 60 array. The RAID 60 compensates for the lower throughput and less memory capacity with better data security. Despite the simultaneous failure of up to two hard disks in each RAID 6 subset the data remains unaffected. In a RAID 50 one hard disk at most may fail at the same time in each RAID 50 subset. Fujitsu Technology Solutions 2009 Page 14 (28)

15 The following diagram compares as a summary the throughputs of RAID 5, 6, 10, 50 and 60 in a configuration with disabled controller features and optimal cache settings. LSI MegaRAID SAS 1078 with 512 MB cache At first glance, a RAID 5 and RAID 6 appear to be more efficient in comparison with the RAID 10. However, if you take a closer look at the measurement data, you can see that this only applies for a purely sequential access pattern, which in practice only occurs very seldom in this form. In the important access profiles with mixed write and read orders you can see that a RAID 10 provides in comparison with RAID 5 and RAID 6 a throughput that is up to 61% higher. LSI MegaRAID SAS 1068 Controller The LSI MegaRAID 1068 SAS Controller of the PRIMERGY TX200 S4 does not have a controller cache. Support is merely provided for RAID levels RAID 0, 1 and 1E. Up to eight SAS or SATA hard disks can be connected to such a controller. The diagram compares the throughputs of the supported RAID arrays. You can see that all hard disks achieve the maximum possible throughput with sequential read access, regardless of in which RAID array they are configured. On the other hand, the throughput for RAID 0 with sequential write achieves only 28% of the maximum possible throughput. A considerable increase in performance is only possible through the enabling of the disk cache thus achieving 90% of the maximum throughput specified for this hard disk. The throughput of the RAID 1 for sequential write achieves 62% of the maximum possible throughput. Enabling the disk cache achieves an improvement to 87% of the maximum possible write throughput. The throughput for sequential write in the RAID 1E only amounts to 11% of the maximum possible throughput. With sequential write access the throughput of a RAID 1E is lower than that of a RAID 1 and performance can also not be improved by enabling the disk cache. However, for random access an appreciable improvement of about 26% was achieved and the attained throughput is on the same level as with the RAID 0 and RAID 1. With the file-server load profile the RAID 1E throughput rate is about 30% above that of the RAID 1 and 50% above that of the RAID 0. Fujitsu Technology Solutions 2009 Page 15 (28)

16 Onboard SATA RAID Controller The onboard SATA controller of the PRIMERGY TX200 S4 is integrated in the chip set Intel ESB2 of the motherboard and does not have a controller cache. The RAID stack is handled by the server CPU. The controller supports RAID 0, 1 and 10 and with an optional ibutton also RAID 5. Up to eight SATA hard disks can be connected to the controller. Based on the 3.5 SATA hard disks from Western Digital, the diagram shows the dependence of throughputs on cache settings. The throughputs of a single hard disk are compared with the throughputs of two hard disks in the RAID 0 and RAID 1 array. Enabling the disk cache has no appreciable impact on read throughput in all configurations, but considerably improves the throughput for sequential write access, namely ten-fold for a single disk configuration, thirteen-fold for the RAID 0 and seven-fold for the RAID 1. Enabling the disk cache also increases the throughput values for random access with 64 KB blocks, namely by 16% for a single disk configuration, 22% for the RAID 0 and 20% for RAID 1. For random access with 8 KB blocks the increase in performance for the RAID 0 and RAID 1 is even more pronounced namely 38% and 22%. Controller comparison Where possible, the comparison depicts the throughputs of the same hard disk types in the same RAID arrays, but with different controllers. The diagram opposite shows the throughputs achieved with disabled caches (Off) and with optimal cache settings (Optimal). The cache settings do not have any impact on the throughput for sequential read access in the RAID 0 array with two hard disks. The throughput achieved is very close to the maximum possible values. In the throughput comparison it is of course necessary to take differences into account, such as the 7.2 krpm rotational speed of the SATA hard disks compared with the 15 krpm of the SAS hard disks. For sequential write access it is possible to achieve a relevant increase in throughput through the optimal cache settings. With the onboard SATA RAID controller the throughput in the RAID 0 array increases thirteen-fold and is thus just short of the maximum possible values. With the LSI MegaRAID SAS 1068 and LSI MegaRAID SAS 1078 controllers the throughput increases by about 3.7 and 3.4-fold. The LSI MegaRAID SAS controllers achieve approximately the same throughputs, regardless of whether the version with the larger or smaller controller cache is used and depending on the access pattern they offer an up to 9% better performance than an LSI MegaRAID SAS 1068 controller. For random access with 67% read share in an onboard SATA RAID controller throughput is improved through optimal cache setting by 38% with 8 KB blocks and by 24% with 64 KB blocks. For the same access pattern with LSI MegaRAID SAS 1068 controller the increase in throughput is 27% and 15%. The smallest relative increase in throughput with the same access pattern is achieved with the LSI MegaRAID SAS 1078 controller namely 23% and 14%. Fujitsu Technology Solutions 2009 Page 16 (28)

17 Similar to the RAID 0 array, the cache settings for sequential read in the RAID 1 array also do not have any or only a very minor influence on throughput, regardless of which controller is used. The throughput values achieved are equivalent to the maximum possible values. For sequential write access it is possible to achieve an increase in throughput with the optimal cache settings. However, it is not as pronounced as in the RAID 0 array. With the onboard SATA RAID controller throughput in the RAID 1 array increases five-fold. Throughput increases by about 40% with the LSI MegaRAID SAS 1068 controller. The best throughput values were achieved with the LSI MegaRAID SAS 1078 controller with a 512 MB controller cache. The difference in performance to the LSI MegaRAID 1078 controller with a 256 MB controller cache is about 8% with optimal cache settings and sequential write access. The difference in performance to the LSI MegaRAID SAS 1068 controller is approximately 13%. For random access with 67% read share with the onboard SATA RAID controller it is possible with the optimal cache setting to achieve a throughput improvement of about 6% with 8 KB blocks only. For the same access pattern with the LSI MegaRAID SAS 1068 controller the increase in throughput for 8 KB blocks comes to 23% and for 64 KB blocks to 16%. The maximum increase in throughput with the same access pattern can be achieved with the LSI MegaRAID SAS 1078 controllers namely of about 50%, regardless of whether a block size of 8 KB or 64 KB is used. Conclusion The Modular RAID concept of the PRIMERGY TX200 S4 offers a plethora of opportunities to meet the requirements of various application scenarios. The onboard SATA RAID controller with its great variety of RAID solutions and the option of being able to use the lowercost SATA hard disks offers the user excellent solution options with a very good price/performance ratio. The entry-level controller, represented by the LSI MegaRAID SAS 1068 controller, offers the basic RAID solutions RAID 0, RAID 1 and RAID 1E and at the same time supports these RAID levels with optimal performance. The high-end controller, represented by the LSI MegaRAID 1078 controller, offers all today s current RAID solutions RAID 0, 1, 5, 6, 10, 50 and 60. This controller is supplied with a 256 MB or 512 MB controller cache and can as an optional extra be backed up with a BBU. Various options for setting the use of the cache enable controller performance to be flexibly adapted to suit the RAID levels used. Use of RAID 5 or RAID 6 enables the existing hard disk capacity to be utilized economically for a good performance. However, we recommend a RAID 10 for optimal performance and security. Fujitsu Technology Solutions 2009 Page 17 (28)

18 Benchmark environment All the measurements presented here were performed with the hardware and software components listed below. PRIMERGY TX200 S4 System BIOS Phoenix Technologies Ltd Rev. 0.99M.2509, 11/11/2007 Onboard SATA RAID-Controller Product LSI Logical Embedded MegaRAID Chipset Intel ESB2 Driver name megasr.sys Driver version LSI MegaRAID SAS 1068 Controller Product LSI RAID 0/1 SAS 1068E SP8 Driver name lsi_sas.sys Driver version Firmware version BIOS version LSI MegaRAID SAS 1078 Controller Product LSI RAID 5/6 SAS 1078 Driver name msas2k3.sys Driver version Firmware package Firmware version BIOS version NT10 Software Operating system Windows Server 2003 Enterprise Edition Version Service Pack 1 Build 3790 File system NTFS Test tool Iometer Test data Measurement file of 8 GB Hard disks used Product Manufacturer FW version Type rpm Capacity ST373455SS Seagate 1651 SAS GB ST373402SS Seagate 1752 SAS GB WD1600AAJS Western Digital 05.06H05 SATA GB Fujitsu Technology Solutions 2009 Page 18 (28)

19 OLTP-2 Benchmark description OLTP stands for Online Transaction Processing. The OLTP-2 benchmark is based on the typical application scenario of a database solution. In OLTP-2 database access is simulated and the number of transactions achieved per second (tps) determined as the unit of measurement for the performance of the system measured. In contrast to benchmarks such as SPECint and TPC-E, which were standardized by independent bodies and for which adherence to the respective rules and regulations are monitored, OLTP-2 is an internal benchmark of Fujitsu Technology Solutions. Contrary to other database benchmarks, which partially require enormous hardware and time expenditure for the simulation, this has been reduced to a reasonable degree in OLTP-2 so that a variety of configurations can be measured within an acceptable period of time. Even if the two benchmarks OLTP-2 and TPC-E simulate similar application scenarios, the results cannot be compared or even treated as equal, as the two benchmarks use different methods to simulate user load. OLTP-2 values are typically similar to TPC-E values. A direct comparison, or even referring to the OLTP-2 result as TPC-E, is not permitted. Benchmark results The PRIMERGY TX200 S4 was measured with the Dual-Core Xeon processor E5205 and with the Quad-Core Xeon processors L5310, L5335, E5405 and E5420 with memory configurations of 8, 16 and 24 GB. All results were determined on the basis of the operating system Microsoft Windows Server 2003 Enterprise x64 Edition SP2 and the database SQL Server 2005 Enterprise x64 Edition SP2. OLTP benchmark results depend to a great degree on the configuration options of a system with hard disks and their controllers. Therefore, the system was equipped with three dual-channel Fibre Channel controllers that were connected to a total of 270 hard disks via three FibreCAT CX500. See the Benchmark environment section for further information on the system configuration. The diagram below shows the OLTP-2 performance data for the PRIMERGY TX200 S4. If performance gain relative to the number of processors is examined in combination with performance gain from memory scaling (e.g. 2 Xeon E5420 with 24 GB RAM compared with 1 Xeon E5420 with 12 GB RAM), the result is a growth in performance of between 86 and 92%. Fujitsu Technology Solutions 2009 Page 19 (28)

20 Benchmark environment Microsoft Windows Server 2003 Enterprise x64 Edition SP2 and SQL Server 2005 Enterprise x64 Edition SP2 Clients: 1 x PRIMERGY Econel 200 with 2 x Xeon 3.40 GHz, 2 MB L2 cache 2 GB RAM onboard LAN Server: PRIMERGY TX200 S4 1, 2 Xeon E5205, L5310, L5335, E5405 and E GB RAM 1 x LSI MegaRAID 1068 controller 3 log disks (72 GB, 15 krpm) 3 x 2-channel FC controllers QLA2362 onboard LAN Storage: 3 x FibreCAT CX data disks (36 GB, 15 krpm) 90 data disks (72 GB, 15 krpm) LAN Switch Fujitsu Technology Solutions 2009 Page 20 (28)

21 Terminal Server Benchmark description For Terminal Server measurements there are a number of load simulation tools, whose results cannot be compared with each other and which are not a standard benchmark. The existing load simulators are not in a position to measure Microsoft Terminal Services and Citrix Presentation Server under the same conditions or have other limitations. Fujitsu Technology Solutions therefore uses a self-developed program named T4US (Tool for User Simulation). This is a flexible tool that can simulate any terminal-server-based scenario independent of the operating system or application software used and that carries out an in-depth measuring of response times and utilization of all the different system components. User at real work T4US Record The T4US load simulator has three components. T4US Control centrally controls and monitors the entire simulation process and evaluates measurement data during the measurement. Several instances of T4US Playback run on the load generator. Each T4US Playback feeds keyboard and mouse inputs in real time to a terminal server client on the basis of T4US Scripts recorded with T4US Record, and monitors the display content of the terminal server client. Thus, the response time of the terminal server is determined by means of high-resolution Controller T4US Control T4US Script The T4US Record tool records user input as keyboard and mouse activities in real time as well as display outputs and stores it in a T4US Script. T4US Scripts are the load profiles used during the measurement. Load generator T4US Agent T4US Play T4US Play T4US Play System under Test (SUT) TS Client TS Client TS Client SUT Terminal Server timers. A T4US Agent runs on every load generator. The T4US Agent is responsible for handling communication with the controller, controls and monitors the instances of T4US Playback and transfers the measured response times to the controller. During the measurement the number of users working with Terminal Server is continuously increased. The Terminal Server response times are monitored by the T4US controller and compared with stored reference values which were determined from a previous reference measurement with only 5 users. If the response time of the application has deteriorated to such a degree that it no longer complies with the predefined rules, the measurement is terminated and the number of users is the result of this measurement. A medium user, who only works with one application at a time and enters data at a good pace, is used as the load profile. Our medium load profile uses Microsoft Word as an application, and the user enters an illustrated text at an average rate of 230 strokes per minute. Because the individual users start one after another with a delay, individual log-ins, application starts and log-offs take place continuously over the entire duration of the simulation. A study shows that many measuring tools, such as the previously used CSTK from Citrix, supply user quantities that were too high as compared to reality. With our new series of measurements, we considered this fact and can therefore assume that the user quantities determined come close to the quantities in real productive environments. To make a statement as regards absolute user quantities, it is nevertheless necessary to analyze the customer-specific load mix and to set it into relation with the performance data in this publication. Although the "number of users per server is the result of the measurements, the results should primarily be regarded as relative, that is, "a PRIMERGY System A is twice as efficient as a PRIMERGY System B or "the doubling of the main memory results in a x% increase in performance. The "Number of users per server" measured here is valid for medium users who work with precisely this load profile. This synthetic user need not correlate with a real user in all cases. Detailed information about the T4US measuring environment, the medium load profile and the results of the other PRIMERGY models is to be found in the Terminal Server Sizing Guide. Fujitsu Technology Solutions 2009 Page 21 (28)

22 Benchmark results The PRIMERGY TX200 S4 is available with one processor from the Intel Xeon series 52xx (code name: Wolfdale), with processors from the Intel Xeon series E53xx (code name: Clovertown) or with processors from Intel Xeon series E54xx (code name Harpertown). Since both 32-bit and 64-bit operating systems can be run on these processors, measurements were performed on one selected Clovertown processor under Windows Server 2003 R2 as a 32-bit and a 64-bit version. Measurements with the 32-bit version were omitted on the other processors. The 32-bit and 64-bit versions of Windows Server 2003 R2 are based on the same code basis and are therefore directly comparable. Furthermore, apart from a few additional services and tools, Windows Server 2003 R2 is identical to Windows Server 2003 Service Pack 1. For the 64-bit measurements, the same general conditions as for the 32-bit measurements were used. In both cases, the simulated users worked with the medium load profile when Microsoft Office 2003 was used. For the Harpertown measurements the medium load profile was used on the one hand and in addition a variation of the medium load profile with a reduction in logon/logoff transactions. Moreover, the different behavior of Microsoft Terminal Services and Citrix Presentation Server was also analyzed. All installations for which no optimizations were performed on the server or client are standard. The only settings that are changed to subject all PRIMERGYs to the same test conditions are the following ones: The page file of the operating system was set to a fixed size of 18 GB. With Citrix, the restriction to 100 users per server pre-set by the integrated load balancing had to be lifted. The following performance-relevant factors are critical for a terminal server system: Computing performance Main memory Disk subsystem Network Network A Terminal Server-based infrastructure is substantially influenced by the underlying network infrastructure. Because we are discussing the performance of an individual Terminal Server in this case, the network has been dimensioned in such a way that it does not represent a bottleneck. Disk subsystem The disk subsystem is a further performance-relevant component. In the measurement environment used here, the operating system, including swap file, is installed on one partition, while the users' data is stored on a second partition of the terminal server with the partitions being on a RAID-0 array of two hard disks each. This configuration is used to ensure that the measurement results between the various PRIMERGY systems are comparable and that the disk subsystem does not become a bottleneck during measuring. However, this does not mandatory correspond to the real customer configuration, because there the user data is typically placed on appropriate disk subsystems or external file servers and not on local hard disks of a terminal server. To achieve maximum throughput, all caches, including the write caches, have been activated. Hard-disk write caches make a considerable contribution toward increasing performance and it is recommended - also in productive use - to make use of this functionality, which is available on all hard disks. In this regard, it is advisable to use a UPS to protect against power failures and the data loss that these entail. Computing performance According to the requirements the PRIMERGY TX200 S4 can be equipped with various processors, which differ with regard to clock frequency, front-side bus speed, cache and the number of cores: Xeon E5205, 1.87 GHz, 1067 MHz front-side bus, 6 MB L2 cache, 65 watt Xeon L5310, 1.60 GHz, 1067 MHz front-side bus, 2 4 MB L2 cache, 50 watt Xeon L5335, 2.00 GHz, 1333 MHz front-side bus, 2 4 MB L2 cache, 50 watt Xeon E5405, 2.00 GHz, 1333 MHz front-side bus, 2 6 MB L2 cache, 80 watt Xeon E5420, 2.50 GHz, 1333 MHz front-side bus, 2 6 MB L2 cache, 80 watt The processors of the series 52xx (code name: Wolfdale) have two cores per chip (Dual-Core), whereas the processors of the series L53xx (code name: Clovertown) and the series E54xx (code name: Harpertown) have four cores per chip (Quad-Core). With the Wolfdale, the L2 cache is 6 MB and is assigned to both cores. In the Clovertown processors the size of the L2 cache is 2 4 MB per chip, that is 4 MB for two cores. With 2 6 MB, that is 6 MB for two cores, the Harpertown processor has an enlarged L2 cache compared with the Clovertown processor. Hyper-Threading is not offered in the current Xeon processors. When regarding computing performance, the system was always configured with adequate main memory so that this component does not represent a bottleneck. The measurements were made under 64-bit Windows 2003 R2. Fujitsu Technology Solutions 2009 Page 22 (28)

23 The diagram opposite shows all the measurement results of the various processors both with one and with two processors. The performance spectrum measured under the Terminal Server benchmark with the medium user load profile ranges from 221 users (two Xeon E5205) through to 271 users (two Xeon E5420). The PRIMERGY TX200 S4 with two Wolfdale Xeon E5205 processors (2 2 cores, 2 6 MB L2 cache) achieves the performance of 221 users. This is just below the 230 user mark measured with a small Harpertown Xeon E5405 processor (four cores, 2 6 MB L2 cache). Also of interest is the comparison between the larger Clovertown Xeon L5335 processors and the smaller Harpertown Xeon E5405 processors. With the same clock frequency and front-side bus frequency, the larger L2 cache of the Xeon E5405 comes out positively in the measuring results. It is noticeable in the measuring results that the performance increase in the upper performance spectrum of the processors can hardly be transformed into a larger number of users by the higher clock frequency or a second processor. Doubling the number of processors only leads to a performance increase ranging between approx. 23% and 12%. This is due to the fact that an increase from four to eight processor cores is less effective than from two to four cores. A more detailed analysis also shows that in the measurements with two processors their cores were only subjected to about 50% - 60% load, although there was neither a bottleneck in the network nor on the disks, in other words the benchmark could not fully utilize the system s CPU performance. A reason for this behavior is to be found in the load profile of the benchmark: a medium user, who is only working with one application and entering data rapidly, is used as the load profile. In our medium load profile, Microsoft Word is used as the application and the user writes an illustrated text with an average input rate of 230 characters per minute, taking about 15 minutes in total. The user then logs off and on again and edits another text. Since users are started on a staggered basis, logging on and off as well as application starts continuously take place during the entire period of measurement. And the outcome in particular of these numerous logons and logoffs is that the CPU performance cannot be fully utilized. This is why measurements were performed with a Harpertown processor with a slightly modified load profile. Every user now writes an illustrated text two times, in other words logging off and back on about every half an hour, which results in a halving of the logon/logoff operations. The modified load also of course brings about different maximum numbers of users. However, it is interesting to note that as a result of the modified load the processors could be better utilized in the measurements with two processors (about 70% - 80%) and that with processors of the higher performance class the measured scaling from one to two CPUs improved from a maximum of 14% to a maximum of 30%. This could be observed both with Microsoft Terminal Server and with measurements with Citrix Presentation Server. Fujitsu Technology Solutions 2009 Page 23 (28)

24 32- and 64-bit operating system The diagram opposite shows the results of Microsoft Terminal Server comparison measurements with the 32-bit and 64-bit Windows Server 2003 R2 operating system. The measurements were done using the T4US medium user profile on a PRIMERGY TX200 S4 with Clovertown processors. For the 64-bit measurements the maximum number of users determined by the benchmark was about 5% below the number of users determined with a 32-bit operating system. Due to its wider address pointer the 64-bit operating system needs more computing time than the 32-bit operating system, because more data have to be transported as a result of the wider address pointer. The advantages of the 64-bit operating system, the larger operating system tables and the enlargement of the address space did not have any effect here, because in the 32-bit measurements they were not the limiting factor. However, it should not be deduced from this that a PRIMERGY TX200 S4 as a terminal server generally provides less performance under 64-bit. The performance under 64-bit depends on other limiting factors, such as the main memory or the user profile. This aspect is dealt with in detail in the document Terminal Server Sizing Guide - 64-bit Technology (see Literature). Somewhat different terminal server behavior can be seen with the Citrix Presentation Server 4.0 on a PRIMERGY TX200 S4 with Xeon 5310 processors. In the 32-bit measurements the scaling from one to two physical CPUs only brought about an increase in performance of approximately 17%. Under the 64-bit operating system an increase in performance of approximately 35% was measured when the physical processors were doubled. This is the same magnitude as under Microsoft Terminal Server and can be explained by the increased memory requirements of a Citrix Presentation Server for a user session in comparison with Microsoft Terminal Server. The result of the limiting of the system resources (paged pool, non-paged pool and page table entries) in the 32-bit operating system was that no further sessions could be started with the scenario measured here and with effect from 198 users. The operating system no longer had the required resources in the paged pool and page table entries so that a login of the users was already acknowledged with an error message at a point in time when the response times of the terminal server for the already logged in users were still within a permissible limit. This explains why under the 64-bit operating system with two processors the measured number of users was higher than with the 32-bit operating system. These measurement results illustrate once more that the question: How much increase in performance can be achieved through a second CPU? can only be answered in connection with the in-depth consideration of the user profile and the bottleneck analysis that this entails. Fujitsu Technology Solutions 2009 Page 24 (28)

25 Main memory The main memory has the greatest influence on the performance of the terminal server. This is particularly reflected in the response time. As and when required, Windows acquires further virtual memory by relocating (swapping) data currently not needed from the main memory (RAM) to the swap file on the hard disk. However, since disk accesses are about a thousand times slower than memory accesses, this results directly in a breakdown in performance and a rapid increase in response times. With terminal server, the memory requirements increase in proportion with the number of users. This is also the case with the PRIMERGY TX200 S4 as the two diagrams for the 32-bit and 64-bit systems illustrate. When the occupied memory calculated from Available MBytes, the committed memory, and the Working Set is shown as a graph, a linear development can be observed that rises with the increasing number of users. The increase in the straight line is steeper with the 64-bit operating system. The 32-bit operating system (Windows Server 2003 Enterprise Edition with Microsoft Terminal Services) has basic requirements of 128 MB, and another 20 MB is needed per user or client. The basic requirement of the 64-bit system increases to approximately 150 MB. In the measuring scenario, however, all users work with the same application. And that is why all user groups have the same memory requirements. However, the memory requirements depend on the applications used and must therefore be calculated on a customerspecific basis. In this regard, it should be noted that the overall system performance is determined by the weakest component. Add to this the fact that the internal structures and virtual address space are restricted due to the architecture of the 32-bit operating system so that the maximum memory configuration of the PRIMERGY TX200 S4 of 24 GB cannot be used for Terminal Server under the 32-bit system. Applications with memory and without CPU limitations benefit in particular from the 64-bit architecture. In this context it should be mentioned, however, that 64-bit operating systems and 64-bit applications generally require more main memory than the 32-bit versions because all the address pointers of 64-bit systems are twice as wide. This can in extreme cases mean that the memory required by 64- bit is twice as large when compared with 32- bit. As shown in the diagram opposite, the same user who started the desktop and is working with Microsoft Word 2003, uses approximately 60% more main memory compared with the 32-bit system. In both cases, the application run by the terminal server user is Microsoft Word, which at present only exists as a 32-bit version. The Microsoft Terminal (Medium-load profile, Microsoft Office 2003, Microsoft Terminal Services) Services as part of the operating system are provided as a 64-bit version. Fujitsu Technology Solutions 2009 Page 25 (28)

26 Since the memory is for the most part the restricting factor, the formula can be used to calculate the required memory for a specified number of users or the number of users for a specified volume of memory. Summary As a dual-socket system with up to eight CPU cores, the PRIMERGY TX200 S4 is ideally suited for Terminal Server applications. Practice has showed that short-term peaks in the user load can generally be better absorbed by a server with two or more processors than with a mono-processor system and convey a harmonious subjective impression of the performance of the Terminal Server system. Good scaling can be achieved by using several systems (scale-out scenario). Due to the software Citrix Presentation Server Enterprise Edition or Microsoft Terminal Services with load balancing, scaling in terminal server farms is also possible and the terminal server farm scales on an almost linear basis. The following diagram shows the PRIMERGY TX200 S4 in comparison with other PRIMERGY systems. This presentation uses the maximum achievable number of users of each PRIMERGY system as the maximum value that was achieved with an optimal hardware configuration and the best operating system (32-bit or 64-bit). There is no exact demarcation where the performance of one model ends and that of the next, more powerful one begins. Every PRIMERGY model covers a certain bandwidth and there are overlaps between the systems. Fujitsu Technology Solutions 2009 Page 26 (28)