T E C H N I C A L S A L E S S O L U T I O N S

Transcription

1 Product Management Document InterScan Web Security Virtual Appliance Customer Sizing Guide September 2010 TREND MICRO INC N. De Anza Blvd. Cupertino, CA Toll free: Fax: Phone: T E C H N I C A L S A L E S S O L U T I O N S

2 Contents Executive Summary...1 Assumptions and Recommendations...1 Default Sizing Guidelines...1 Sizing at a Glance Software Appliance (Bare Metal)...2 Sizing at a Glance Virtual Appliance (VMware ESX v3.5 & 4.0)...3 Sizing at a Glance Software Appliance (Bare Metal) with Access Logging Enabled...5 Calculating the Number of IWSVA Servers Required...7 Step 1: Obtain the Required Data for the Customer Environment...7 Step 2: Determine the Number of Required Servers...8 The Impact of Enabling HTTPS Scanning (IWSVA and above) HTTPS Scanning Assumptions General Sizing and Performance Guidance for HTTPS Scanning Appendix A How Tests Were Conducted What Configuration Changes do to Sizing Scanning Reporting Caching Performance Criteria for Tests Scalability and Accuracy Hardware Tested Glossary About Trend Micro Incorporated Copyright 2010 by Trend Micro Incorporated. All rights reserved. No part of this publication may be reproduced, photocopied, stored on a retrieval system, or transmitted without the prior written consent of Trend Micro Incorporated. Trend Micro, the t-ball logo, and InterScan are trademarks or registered trademarks of Trend Micro Incorporated. All other company and/or product names may be trademarks or registered trademarks of their owners. Information contained in this document is provided "as-is" and subject to change without notice. This report is for informational purposes only and is not part of the documentation supporting Trend Micro products. TREND MICRO MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS REPORT. [ETM Part No: SG_SVA_201009US] This document is a product of Trend Micro Technical Sales Solutions. ii

3 Executive Summary Trend Micro has conducted tests on Trend Micro InterScan Web Security Virtual Appliance 3.1, 5.0 and 5.1 (IWSVA) to obtain advanced performance characterization data for sizing customer environments. Sizing for a single IWSVA server with antivirus, Web-reputation, URL filtering, and Applet and ActiveX Security (AAXS) active without caching in the environment is impacted by the following: CPU Memory Disk type and configuration Active features of IWSVA For the latest information about InterScan Web Security Virtual Appliance, including documentation, device support, and the latest software builds, visit the Trend Micro Web site at: Assumptions and Recommendations The sizing in this document is based on the following assumptions: The user population is the total number of potential Web users within an organization. The number of active users is the total number of client workstations that are simultaneously requesting HTTP content at any point in time. This is assumed 20% by default. Each active user has an average of 3.5 open connections to the Internet at any one time. Gigabit network interface cards (NIC) are used throughout the LAN. HTTPS scanning is disabled by default (IWSVA 5.x only). HTTPS impact is provided in this document. And the following Recommendations: Hardware should meet minimum listed requirements. It is required to have adequate memory to establish a TCP connection. If enough memory is not available, system performance may be restricted. Medium to Large Enterprise environments should utilize Trend Micro Advanced Reporting and Management (ARM) for centralized database functionality. Default Sizing Guidelines General sizing can be obtained on a per-server basis if the specifics of the available hardware are known. The sizing below assumes virus scanning, Web reputation, URL filtering and AAXS are active with IWSVA in both Forward Proxy mode without an external caching server. The results are accurate to within ±5 percent. Because IWSVA performance is CPU-bound, the number of CPU s present will affect performance. For multi-core systems, each core is considered a separate CPU for the purpose of this sizing guide. The sizing information conveyed in this document is the absolute maximum the specified hardware configuration can support. It is advisable to appropriately size and allow room for growth and not undersize a solution for a given environment. A linear increase in allocated CPU GHz does not equate to a linear performance increase. 1

4 Sizing at a Glance Software Appliance (Bare Metal) Assuming virus scanning, Web reputation, URL filtering, and AAXS are active on an IWSVA 5.0 server scanning HTTP traffic in Forward Proxy and Bridge mode configuration; Tables 1 and 2 provide recommendations for software appliance general sizing for IWSVA 5.1 and IWSVA 3.1/5.0 respectively. Table 1 IWSVA 5.1 Sizing at a Glance with All Scanning Policies Active (Default Install Configuration) Server Type 2 CPU (Xeon 80546K) 4 CPU (Xeon E5335) 4 CPU (Xeon 5160) 8 CPU (Xeon X5460) 16 CPU (Xeon E7340) Memory Concurrent Connections HTTP Transactions per Second Throughput (Mbits per second) Maximum Total User Population per device 2 GBytes Mbits / second GBytes 2,860 1, Mbits / second 4,080 4 GBytes 3,100 2, Mbits / second 4,400 8 GBytes 7,705 5, Mbits / second 11, GBytes 12,420 7, Mbits / second 17,700 Table 2 IWSVA 3.1 and 5.0 Sizing at a Glance with All Scanning Policies Active (Default Install Configuration) Server Type 2 CPU (Xeon 80546K) 4 CPU (Xeon E5335) 4 CPU (Xeon 5160) 8 CPU (Xeon X5460) 16 CPU (Xeon E7340) Memory Concurrent Connections HTTP Transactions per Second Throughput (Mbits per second) Maximum Total User Population per device 2 GBytes Mbits / second GBytes 2,400 1, Mbits / second 3,400 4 GBytes 2,700 2, Mbits / second 3,800 8 GBytes 6,700 5, Mbits / second 9, GBytes 10,800 7, Mbits / second 15,400 For the specific hardware configuration of each server type used above, please refer to Appendix A As the number of users and events increases, it becomes more important to use a fast disk subsystem to increase system performance (for example, SAS disk in RAID 1+0 configuration) Features and Modes Impact on Performance: The largest use of system resources is virus scanning. The use of Web reputation, URL filtering, and Applet and ActiveX Security (AAXS) only 2

5 modestly lowers system performance and does not significantly decrease the supported user population per server. Transparent bridge mode performance was tested to be less than 4% lower than forward proxy mode performance and for general sizing purposes can be thought of as the same. As a general rule of thumb, enabling HTTPS scanning in a network that contains 15% of HTTPS traffic to be decrypted and scanned will reduce the sizing and capacity numbers in the sizing guide tables by approximately 53%. This is normal since HTTPS key negotiation, decryption and re-encryption are CPU bound activities. Environments with HTTPS scanning requirements should consider hardware acceleration cards for maintaining peak performance. With a Trend approved HTTPS acceleration card, performance numbers are retained with HTTPS scanning enabled. Refer to the Trend Micro Software Appliance Support document for certified hardware acceleration cards ( Sizing at a Glance Virtual Appliance (VMware ESX v3.5 & 4.0) Assuming virus scanning, Web reputation, URL filtering, and AAXS are active on an IWSVA server scanning HTTP traffic in Forward Proxy and Bridge mode configuration; Tables 3 and 4 provide recommendations for virtual appliance general sizing for IWSVA 5.1 and IWSVA 3.1/5.0 respectively. Table 3 IWSVA 5.1 Sizing at a Glance with All Scanning Policies Active (Default Install Configuration) Server Type 4 vcpu (4 GHz Allocation) 4 vcpu (8 GHz Allocation) 4 vcpu (12 GHz Allocation) Memory Concurrent Connections HTTP Transactions per Second Throughput (Mbits per second) Maximum Total User Population per device 4 GBytes 1, Mbits / second 1,640 4 GBytes 2,400 1, Mbits / second 3,400 4 GBytes 2,760 1, Mbits / second 3,900 Table 4 IWSVA 3.1 and 5.0 Sizing at a Glance with All Scanning Policies Active (Default Install Configuration) Server Type 4 vcpu (4 GHz Allocation) 4 vcpu (8 GHz Allocation) 4 vcpu (12 GHz Allocation) Memory Concurrent Connections HTTP Transactions per Second Throughput (Mbits per second) Maximum Total User Population per device 4 GBytes 1, Mbits / second 1,400 4 GBytes 2,100 1, Mbits / second 3,000 4 GBytes 2,400 1, Mbits / second 3,400 For the specific hardware configuration of each server type used above, please refer to Appendix A The performance difference of installing IWSVA on a VMware virtual appliance verses installing IWSVA on a bare metal software appliance server (both using 4 CPUs and the same amount of memory and disk) is between 10% and 15%. The performance degradation under VMware is normal and can be attributable to 3

6 the VMware OS overhead that is required to manage the Virtual Machines (VMs) and the resources being shared. A linear increase in allocated CPU GHz does not equate to a linear performance increase. For example, there is a 114% increase in performance from 4 GHz to 8 GHz, there is only a 13.3% increase from 8 GHz to 12 GHz. When looking at a similar relationship in the software appliance there is only a 12.5% increase when moving from 4 CPU s running at 2 GHz (8 GHz combined) to 4 CPU s running at 3 GHz (12 GHz combined). The maximum number of CPUs permitted for a virtual machine will depend on the version of VMware. Tests were conducted with a maximum of 4 CPUs under VMware ESX 3.5 & 4.0. Later versions of VMware such as vsphere 4.0 permit additional CPUs and will provide higher performance and capacity. For more information on performance tuning IWSVA on VMware, see the Trend Micro Software Virtual Appliance Best Practices for VMware document. Features and Modes Impact on Performance: The largest use of system resources is virus scanning. The use of Web reputation, URL filtering, and Applet and ActiveX Security (AAXS) only modestly lowers system performance and does not significantly decrease the supported user population per server. Transparent bridge mode performance was tested to be less than 2% lower than forward proxy mode performance and for practical purposes can be thought of as the same. As a general rule of thumb, enabling HTTPS scanning in a network that contains 15% of HTTPS traffic to be decrypted and scanned will reduce the sizing and capacity numbers in the sizing guide tables by approximately 53%. This is normal since HTTPS key negotiation, decryption and re-encryption are CPU bound activities. With a Trend approved HTTPS acceleration card, performance numbers are retained with HTTPS scanning enabled. 4

7 Sizing at a Glance Software Appliance (Bare Metal) with Access Logging Enabled Assuming virus scanning, Web reputation, URL filtering, and AAXS are active on an IWSVA server scanning HTTP traffic in Forward Proxy and Bridge mode configuration; Tables 5 and 6 provide recommendations for software appliance general sizing for IWSVA 5.1 and IWSVA 3.1/5.0 respectively. Table 5 IWSVA 5.1 Sizing at a Glance with All Scanning Policies Active (Default Install Configuration) Server Type 2 CPU (Xeon 80546K) 4 CPU (Xeon E5335) 4 CPU (Xeon 5160) 8 CPU (Xeon X5460) 16 CPU (Xeon E7340) Memory Concurrent Connections HTTP Transactions per Second Throughput (Mbits per second) Maximum Total User Population per device 2 GBytes Mbits / second GBytes 2,500 1, Mbits / second 3,570 4 GBytes 2,850 1, Mbits / second 4,000 8 GBytes 7,350 5, Mbits / second 10, GBytes 11,800 7, Mbits / second 16,800 Table 6 IWSVA 3.1 and 5.0 Sizing at a Glance with All Scanning Policies Active (Default Install Configuration) Server Type 2 CPU (Xeon 80546K) 4 CPU (Xeon E5335) 4 CPU (Xeon 5160) 8 CPU (Xeon X5460) 16 CPU (Xeon E7340) Memory Concurrent Connections HTTP Transactions per Second Throughput (Mbits per second) Maximum Total User Population per device 2 GBytes Mbits / second GBytes 2,200 1, Mbits / second 3,100 4 GBytes 2,500 1, Mbits / second 3,550 8 GBytes 6,400 5, Mbits / second 9, GBytes 10,300 7, Mbits / second 14,700 For the specific hardware configuration of each server type used above, please refer to Appendix A As the number of users and events increases, it becomes more important to use a fast disk subsystem to increase system performance (for example, SAS disk in RAID 1+0 configuration) 5

8 Features and Modes Impact on Performance: The largest use of system resources is virus scanning. The use of Web reputation, URL filtering, and Applet and ActiveX Security (AAXS) only modestly lowers system performance and does not significantly decrease the supported user population per server. Transparent bridge mode performance was tested to be less than 2% lower than forward proxy mode performance and for practical purposes can be thought of as the same. As a general rule of thumb, enabling HTTPS scanning in a network that contains 15% of HTTPS traffic to be decrypted and scanned will reduce the sizing and capacity numbers in the sizing guide tables by approximately 53%. This is normal since HTTPS key negotiation, decryption and re-encryption are CPU bound activities. With a Trend approved HTTPS acceleration card, performance numbers are retained with HTTPS scanning enabled. The IWSVA server was configured to Log every user visit along with any associated files. The above performance information represents a worst-case scenario as all user visits are being logged. By utilizing the second logging option to log one entry along with files over a specific size such as the default value of 1,024 KBytes, this will roughly decrease the number of log events recorded to 1/3 the volume when recorded when using the verbose logging method. It should be noted that during the performance testing, access logs were queued in text files and were processed slowly into the database over a period of the next hours for the performance testing duration. During this time, performing a report generation on data entered into the database was possible, but for only data which had been committed to the database. A full report on the data from the testing duration was only possible once all data was entered into the database. The two largest factors in depending on how IWSVA handles the access log events are quick disk drive access such as what is provided by SAS and CPU performance. For larger high-volume environments, Trend Micro highly recommends that the logging and reporting functions be redirected to an external reporting device - such as Trend Micro s Advanced Reporting & Management module. Offloading logging and reporting to an off-box device will improve the logging and reporting performance and reduced the scanning latency on the IWSVA unit. 6

9 Calculating the Number of IWSVA Servers Required This procedure allows you to calculate the number of IWSVA servers required for your environment based on the number of total users in the company. Step 1: Obtain the Required Data for the Customer Environment At a minimum, the following information is required to size a customer environment: User Population The following items are recommended but not required because sizing estimates can be made based on User Population: Peak number of concurrent users Peak throughput (Mbits per second) Caching percentage (if present) Sizing variables are defined in Table 7. Obtain from the customer environment as many of the variables listed in Table 7 as practical and write them down on a worksheet to be used in the calculations or in the Sizing Calculator. To ensure proper sizing, Trend Micro recommends that customers use peak loads (the highest number of active users and peak throughput) when calculating the number of required IWSVA servers. The version of IWSVA will make a difference in the final calculations as IWSVA 5.1 performance is 15% better (on average) over IWSVA 3.1 and 5.0. Table 7 Environment Variables for IWSVA Sizing Name Variable Description Number of Users with Internet Access USER_POPULATION The total number of users with Internet access that will be supported by the IWSVA deployment. Number of Users Accessing the Internet Simultaneously Peak Bandwidth Required %_CONCURRENCY THROUGHPUT_TOTAL The percentage of the USER_POPULATION who are actively making an Internet request (clicking a link in a web browser). If unknown, it is common to choose 20% (0.20) concurrency when sizing. For environments with more active users, increase the concurrency percentage to a value such as 0.33 or higher. (%_CONCURRENCY=0.20) The amount of HTTP traffic passing through the gateway in Megabits per second (Mbps). If unknown, it is common to choose a value of 75% available Internet bandwidth. For example, an organization with a T3 connection would have Mbits per second. For this organization THROUGHPUT_TOTAL = 0.75 x =

10 Name Variable Description The number of HTTP connections per active user. Connections per user Caching % CONNECTIONS_USER %_CACHE If unknown, the default value is 3.5. For environments with users accessing many Web 2.0 sites, increase the number of connections per user to 5 or higher. (CONNECTIONS_USER=3.5). If a caching solution is present, the percentage of caching occurring for the environment is required. If unknown yet caching is present, it is common to choose 25% caching (%_CACHE = 0.25) for the environment. If no caching is present, choose %_CACHE = 0. Step 2: Determine the Number of Required Servers For this sizing guide, identical hardware is assumed for all servers in a multi-server environment. After calculation, the customer can decide which server type fits their needs best and use the recommended number of servers for that specific hardware configuration. The options listed below assume IWSVA installed as a Software Appliance (bare metal) without access logging enabled (Table 1 or 2 depending on IWSVA version). It is important to note that only one type of server is used for sizing. Do not add the results from the options below; simply choose one of the results for the sizing. Option 1: Number of 2 CPU servers (2.8 GHz Intel Xeon 80546K, 2 GBytes RAM) Using the variables obtained or assumed from Table 7, calculate the number of 2 CPU servers required (IWSVA 5.0 used in this example): (CONNECTIONS_USER %_CONCURRENT USER_POPULATION) Number _ Servers = (1 % _ CACHE ) 500 Round up the number of IWSVA servers to the nearest whole number. Option 2: Number of 4 CPU servers (2.0 GHz Intel Xeon E5335, 4 GBytes RAM) Using the variables obtained or assumed from Table 7, calculate the number of servers required (IWSVA 5.0 used in this example): (CONNECTIO NS_USER %_CONCURRE NT USER_POPU LATION) Number _ Servers = (1 % _ CACHE ) 2,400 Round up the number of IWSVA servers to the nearest whole number. Option 3: Number of 4 CPU servers (3.0 GHz Intel Xeon 5160, 4 GBytes RAM) Using the variables obtained or assumed from Table 7, calculate the number of servers required (IWSVA 5.0 used in this example): (CONNECTIO NS_USER %_CONCURRE NT USER_POPU LATION) Number _ Servers = (1 % _ CACHE ) 2,700 8

11 Round up the number of IWSVA servers to the nearest whole number. Option 4: Number of 8 CPU servers (3.16 GHz Intel Xeon X5460, 8 GBytes RAM) Using the variables obtained or assumed from Table 7, calculate the number of servers required (IWSVA 5.0 used in this example): (CONNECTIO NS_USER %_CONCURRE NT USER_POPU LATION) Number _ Servers = (1 % _ CACHE ) 6,700 Round up the number of IWSVA servers to the nearest whole number. IWSVA 5.0 Connection Sizing Example For a customer with: USER_POPULATION = 10,000 %_CONCURRENT = 0.20 CONNECTIONS_USER = 3.5 %_CACHE = 0.20 THROUGHPUT_TOTAL=180 Megabits per second Who desires sizing using the following existing server configuration: Two CPU (two, dual-core, 3.0 GHz Intel Xeon 5160 CPU s) Memory per server is 4 GBytes The number of required servers are as follows: ( ,000) Number _ Servers = (1 0.20) = With rounding up, this equals 3.0 2,700 For this network, three (3) servers are required to meets their needs to ensure scanning capacity meets environmental conditions. If throughput information is also available, the throughput capabilities of the solution should be compared to the environment needs prior to making a recommendation. Simply compare the THROUGHPUT_TOTAL variable (if available) to the calculated throughput for the recommended solution. The calculated throughput should be greater than the THROUGHPUT_TOTAL variable. If it is not, the number of recommended servers should be adjusted accordingly. For example, for the above scenario, the recommended solution can provide 786 Mbits per second throughput (3 servers x 262 Mbits per second for the selected 4 CPU server). The customer environment requires only 180 Megabits per second, well below the available throughput. The following table can assist in making calculations: 2 CPU server (2.8 GHz Intel Xeon 80546K) supports 40 Mbits per second 4 CPU server (2.0 GHz Intel Xeon E5335) supports 188 Mbits per second 4 CPU server (3.0 GHz Intel Xeon 5160) supports 262 Mbits per second 9

12 The Impact of Enabling HTTPS Scanning (IWSVA and above) Starting with IWSVA 5.0, customers can enable HTTPS scanning to decrypt SSL traffic for scanning. HTTPS scanning involves CPU intensive operations negotiating the SSL key pair and key exchange, decrypting SSL encrypted content for scanning, and re-encrypting content to deliver to client hosts. Customers can select which URL categories, domains, web sites, and individual URLs to decrypt for scanning with the IWSVA s HTTPS scanning policies. Performance will decrease as the amount of SSL traffic to decrypt and scan increases. HTTPS scanning performance will depend on the amount of available CPU on the server platform. As a general rule of thumb, enabling HTTPS scanning in a network that contains 15% of HTTPS traffic to be decrypted and scanned will reduce the sizing and capacity numbers in the sizing guide tables by approximately 53%. This is normal since HTTPS key negotiation, decryption and re-encryption are CPU bound activities. Environments with HTTPS scanning requirements should consider hardware acceleration cards for maintaining peak performance. With a Trend approved HTTPS acceleration card, performance numbers are retained with HTTPS scanning enabled. Refer to the Trend Micro Software Appliance Support document for certified hardware acceleration cards ( HTTPS Scanning Assumptions In general, the mix of HTTPS traffic to normal non-encrypted traffic will be between a high of 30% to a low of 8% for many customers. Most customers will enable HTTPS scanning through URL categories and custom categories they define with only the domains, web sites and URLs that they re interested in scanning. This will reduce the amount of HTTPS traffic to be scanned by more than 50% of the overall HTTPS traffic mix. The resulting mix of HTTPS traffic to decrypt and scan will be less than 15% of overall traffic. General Sizing and Performance Guidance for HTTPS Scanning Testing performed by Trend Micro s sizing labs reveal the following: Scanning capacity with 100% HTTPS traffic is approximately 13% (or 1/8 th ) of non-encrypted traffic on the same server platform. Using the Dell 2950 Series III server platform with 8 CPU cores and 8 GBytes of memory as an example, the following performance can be expected (Table 5): Table 8 HTTPS Scanning Sizing Example with IWSVA 5.0 HTTPS Scanning Enabled Disabled HTTPS Traffic Mix for Scanning Maximum of 15% Not applicable 10

13 HTTPS Scanning Enabled Disabled Concurrent Connections Supported (< 2 sec page latency) 3,150 6,700 User Population Supported 4,500 9,500 11

14 Appendix A How Tests Were Conducted Product performance was determined based on a workload where each active user accesses 12 Web sites sequentially. This workload was deemed representative of that of an actual enterprise. The range of object sizes (.jpg,.png,.css,.gif, and.js) ranged between 9 and 174 KBytes, with.htm pages ranging between 3 and 143 KBytes. Think time was maintained at 5 seconds, making this a test of moderately aggressive Internet surfing behavior. Using this representative workload, a maximum throughput of ~615 Mbits per second was observed at 6,700 simultaneous connections on a Dell 2950 Series 3 (8 CPU Intel Xeon X5460, 8 GBytes RAM) using IWSVA 5.0. Throughput results were a function of the size of the user download. With large, long downloads, higher throughput occurs; with many smaller objects, less throughput occurs. IWSVA 5.1 improves capacity by roughly 15% on average. The use of ICAP or caching in general greatly improves the capacity of the environment by reducing the amount of network communication to the IWSVA server. IWSVA 3.1 and above also includes a Web Reputation feature. This feature relies on DNS queries to Trend Micro data centers for each new URL request. Reputations are cached for a period of 35 minutes by default and new reputation requests for that URL are provided without the need for additional queries. This Sizing Guide assumes that the customer environment has sufficient DNS infrastructure to handle the query load that results from deploying one or more IWSS units. What Configuration Changes do to Sizing Configuration changes to IWSVA affect sizing in a number of ways. These impacts are summarized below: Scanning Reporting There are four local scanning features in the product. The test results in the Default Sizing Guidelines section above are with all four scanning features active. Therefore, if all features are active, the performance equals the sizing calculated in this section. If virus scanning is deactivated, the number of supported simultaneous connections increases by approximately 19%. Web reputation, URL filtering, and Applet and ActiveX scanning only modestly affect performance for average workloads. Real-time reports can take a significant amount of time to complete in high-workload environments if there are inadequate amounts of free CPU to process each request. For this reason, reports should be scheduled for non-peak workload periods. Environments requiring efficient real-time reporting during high-workload periods are advised to size their servers for less than 100% CPU utilization to keep the end-user and administrative experiences positive. 12

15 Caching Activating optional per-user logging (the Logs Settings Log HTTP/FTP access events check box is checked) can increase disk I/O considerably. In multi-server environments, leveraging Trend Micro s Advanced Reporting & Management (ARM) module for off-box reporting or installing an additional IWSVA server that is dedicated to logging and reporting only will greatly improve logging and reporting performance. Using high-performance RAID arrays with fast hard disks will improve performance significantly. Using caching in an environment affects system performance. With a properly sized ICAP 1.0 solution in place, the capacity of the environment increases proportionally to the cache percentage: A 25 percent cache allows each server to increase capacity by a factor of 1.3. A 50 percent cache allows each server to increase capacity by a factor of 2. A 75 percent cache allows each server to increase capacity by a factor of 4. A 90 percent cache allows each server to increase capacity by a factor of 10. These performance factors are based on an off box external ICAP server. Performance Criteria for Tests Trend Micro conducted the tests with the requirement that all test results and sizing recommendations meet the following conditions: Hosts and servers have zero TCP Connection failures Hosts and servers have zero HTTP Transaction failures Hosts must experience an average page load time < 2000ms (2 seconds) Although the IWSVA servers can provide more connections and transactions than listed in the sizing tables, the page load latency will be above 2 seconds and will not reflect real-world expectations where users expect fast Internet response times. Scalability and Accuracy The scalability of IWSVA is totally dependent on the quantity and type of CPU being used. Older technology but seemingly higher MHz CPU s do not yield better performance numbers - as CPU processing efficiency gains with each newer generation of CPUs. When sizing different CPU environments, it is best advised to use the performance numbers based on the 4 CPU performance results as these give a nice upper and lower performance boundary for common CPU s available today. These results can also translate between the software appliance and virtual appliance. The testing procedure and methodology used in this report is accurate, reproducible and well documented. The results are precise up to ±5 percent. 13

16 Hardware Tested Tables 9-15 provide details of the hardware used in this Sizing Guide. Table 9 2 CPU Server Component Value Type Chassis Dell 1850 Series 1 CPU Intel Xeon Processor 2.80 GHz 80546K CPU Speed 2.8GHz Bus Speed 800Mhz Cores per CPU 2 Number of 1 CPU s Total Cores / 2 CPU Memory 2GB Disk Drives 1 x 146Gb 15K SCSI Disk Controller Dell Perc 5/I SCSI Network Gigabit Ethernet x 2 More Information Table 10 4 CPU Server Component Value More Information Type Chassis Dell 1950 Series 2 CPU Intel Xeon Processor E5335 CPU Speed 2GHz Bus Speed 1333Mhz Cores per CPU 4 Number of 1 CPU s Total Cores / 4 CPU Memory 4GB Disk Drives 2 x 73Gb 15K RPM SAS Configured in RAID 1 Disk Controller Dell Perc 5/i SAS Network Gigabit Ethernet x 2 14

17 Table 11 4 CPU Server Component Value Type Chassis Dell 1950 Series 3 CPU Intel Xeon Processor 5160 CPU Speed 3GHz More Information Bus Speed 1333Mhz Cores per CPU 2 Number of 2 CPU s Total Cores / 4 CPU Memory 4GB Disk Drives 2 x 73Gb 15K RPM SAS Configured in RAID 1 Disk Controller Dell Perc 5/i SAS Network Gigabit Ethernet x 2 Table 12 8 CPU Server Component Value More Information Type Chassis Dell 2950 Series 3 CPU Intel Xeon Processor X5460 CPU Speed 3.16GHz Bus Speed 1333Mhz Cores per CPU 4 Number of 2 CPU s Total Cores / 8 CPU Memory 8GB Disk Drives 3 x 73Gb 15K RPM SAS Configured in RAID 5 Disk Controller Dell Perc 6/i SAS Network Gigabit Ethernet x 2 15

18 Table CPU Server Component Value More Information Type Chassis Sun X4450 CPU Intel Xeon Processor E7340 CPU Speed 2.4GHz Bus Speed 1066Mhz Cores per CPU 4 Number of 4 CPU s Total Cores / 16 CPU Memory 16GB Disk Drives 4 x 136GB 15K RPM SAS Configured in RAID 5 Disk Controller Adaptec SUN RAID Network Gigabit Ethernet x 2 Table 14 4 CPU Virtual Appliance Component Type Value More Information Chassis VMware ESX 3.5 CPU VMware vcpu CPU Speed (Total Allocated) 4GHz / 8GHz / 12GHz Bus Speed NA Cores per CPU 1 Number of CPU s 4 Total Cores / CPU 4 Memory 4GB Disk Drives 40 GB Disk Controller LSI Logic Network Gigabit Ethernet x 1 16

19 Table 15 VMware ESX 3.5 Host Server Component Type Value More Information Chassis Dell 2950 Series 2 CPU Intel Xeon Processor X5355 CPU Speed 2.66GHz Bus Speed 1333Mhz Cores per CPU 4 Number of CPU s 2 Total Cores / CPU 8 Memory 8GB Disk Drives 3 x 73Gb 15K RPM Configured in RAID 5 SAS Disk Controller Dell Perc 5/i SAS Network Gigabit Ethernet x 2 17

20 Glossary Active Users The number of actual users requesting Web content through an HTTP Web browser (such as Microsoft Internet Explorer) at any one time. Connection Latency The amount of time between the user s first click in a Web browser until the time data begins appearing on the screen. Default Configuration The default configuration of IWSVA 5.0 is with antivirus, Web-reputation, URL filtering, and Applet and ActiveX Security (AAXS) active. HTTP 1.1 Connection A method that enables the use of one connection to send or receive multiple HTTP requests or responses. HTTP 1.1 allows multiple requests to be made through a single connection. Requests per second The rate at which HTTP objects (for example.jpg,.gif or.htm files) are requested and processed. Think Time The time between browser clicks for an active user. Throughput The amount of digital data per time unit that is delivered over a physical or logical link, or that is passing through a gateway scanning device. This is expressed as either Bytes per second or bits per second (8 bits = 1 Byte). Total Page Download Latency The average total time to download a workload-specific Web site after initial connection. User Population The total number of users with Internet access to be supported by the IWSVA 5.0 deployment. 18

21 About Trend Micro Incorporated Trend Micro Incorporated, a global leader in Internet content security, focuses on securing the exchange of digital information for businesses and consumers. A pioneer and industry vanguard, Trend Micro is advancing integrated threat management technology to protect operational continuity, personal information, and property from malware, spam, data leaks and the newest Web threats. Trend Micro s flexible solutions, available in multiple form factors, are supported 24/7 by threat intelligence experts around the globe. A transnational company, with headquarters in Tokyo, Trend Micro s trusted security solutions are sold through its business partners worldwide. For more information, please visit 19