Zeus Traffic Manager VA Performance On VSphere 4

White PaperZeus Traffic ManagerVA Performance onvSphere 4Zeus. Why wait

ContentsIntroduction . 2Test Setup . 2System Under Test. 3Hardware . 3Native Software. 3Virtual Appliance . 3Benchmarks . 4Results. 6Analysis . 7IntroductionThis document details the performance figures obtained by the Zeus Traffic ManagerVirtual Appliance (Zeus Traffic Manager VA) on VMware vSphere 4.0 and outlines themethods used to achieve these performance figures. A comparison of the performance ofvarious virtual appliance configurations relative to that of the native install of Linux on thesame hardware is also provided.Test SetupA series of clients and web servers, along with the system under test, were connected to aflat, switched Ethernet network using multiple 1Gbps NICs. The clients, which consisted of64-bit dual-core CPU machines running Linux, generated requests and sent them to thesystem under test. Zeus Traffic Manager was running on the system under test and loadbalanced the requests across the web servers, which consisted of 64-bit dual- and quadcore CPU machines also running Linux.The requests were generated by a program called Zeusbench 1, a high-performance, vendoragnostic, HTTP benchmarking tool included with Zeus Traffic Manager. Zeusbench reportedthe benchmarking results obtained on each of the clients. These results were then collatedto ascertain the overall performance of the system under test.Zeusbench produces similar results to those that would be achieved with otherbenchmarking tools, such as /2009/03/26/introducing zeusbenchZ e u s Tr a f f i c M a n a g e r V A P e r f o r m a n c e o n V M w a r e v S p h e r e 4Page 2 of 8Zeus. Why wait.

System Under TestHardwareThe hardware used to conduct the benchmarks consisted of a Dell PowerEdge 2950containing an Intel Quad-Core Xeon E5450 processor, 8GB of RAM and 6 networkinterfaces. The network interfaces are broken down into four Intel Pro 1000VT interfacesand two interfaces built in to the motherboard. Only the Intel Pro 1000VT interfaces wereused to conduct the benchmarks, with one of the built-in interfaces used for the ESXservice console and the other interface remaining unused.Native SoftwareThe performance figures for the native hardware of the system under test were obtainedby running a 64-bit Ubuntu 8.10 Live CD on the machine and installing on it the Linuxx86 64 build of Zeus Traffic Manager version 5.1r1. All non-essential services werestopped and the following Linux kernel tunings applied:# Increase local port rangeecho "1024 65535" /proc/sys/net/ipv4/ip local port range# Disable syncookiesecho 0 /proc/sys/net/ipv4/tcp syncookies# Increase maximum syn backlogecho 8092 /proc/sys/net/ipv4/tcp max syn backlog# Increase maximum socket backlogecho 1024 /proc/sys/net/core/somaxconn# Increase maximum available file descriptorsecho 2097152 /proc/sys/fs/file-maxVirtual ApplianceThe performance figures for the various virtual appliance configurations were obtainedusing a pre-release version of Zeus Traffic Manager VA 5.1r2 virtual appliance configuredon vSphere 4.0 running on the system under test. When obtaining performance figures,the Zeus Traffic Manager Virtual Appliance under test was the only virtual machineinstalled on the vSphere server.No additional tuning was performed beyond that which already exists on the standardVirtual Appliance image. VMware tools are preinstalled in the Zeus Traffic Manager VAimage.The virtual machine was allocated 512 MB of RAM and the “vmxThroughputWeight” settingfor the ESX server was set to 128.Each of the four Intel Pro 1000VT network interfaces was configured on a separate virtualnetwork and added to the virtual machine. The “vmxnet3” network device was used foreach of these virtual network interfaces.Z e u s Tr a f f i c M a n a g e r V A P e r f o r m a n c e o n V M w a r e v S p h e r e 4Page 3 of 8Zeus. Why wait.

BenchmarksThe intention of the benchmarks was to obtain performance figures for a 64-bit virtualmachines running with 1, 2, 3 and 4 virtual CPUs. These figures could then be comparedwith those obtained for the native system to discover how performance is affected byrunning Zeus Traffic Manager inside a virtual machine.The benchmarks conducted consisted of the following tests:Layer 4 connections per second: The rate at which Zeus Traffic Manager can handlenew TCP connections. Clients send a series of requests to Zeus Traffic Manager, each on anew connection. For each request, Zeus Traffic Manager opens a new connection to a webserver and forwards the request to it. The web server sends back a response for eachrequest.Layer 4 requests per second: The rate at which Zeus Traffic Manager can handle shortrequests and responses. Each client sends all its requests on the same connection to ZeusTraffic Manager, which forwards them over a persistent connection to a web server. A shortresponse is returned from the web server for each request.HTTP connections per second: The rate at which Zeus Traffic Manager can process newHTTP connections. Clients send a series of HTTP requests, each on a new connection. ZeusTraffic Manager parses the requests and forwards them on to a web server using anestablished keepalive connection. The web server sends back a response for each request.HTTP requests per second: The rate at which Zeus Traffic Manager can handle HTTPrequests. Each client sends its requests down an existing keepalive connection. Zeus TrafficManager processes each request and forwards it on to a web server over another keepaliveconnection. The web server responds with a zero sized file.HTTP 2K requests per second: The rate at which Zeus Traffic Manager can handlerequests for a 2 KB file.HTTP 8K requests per second: The rate at which Zeus Traffic Manager can handlerequests for an 8 KB file.HTTP throughput: The throughput that Zeus Traffic Manager can sustain when servinglarge files via HTTP. The methodology used for the HTTP requests per second benchmark isused here, however the files requested are 1 MB in size.SSL connections per second: The rate at which Zeus Traffic Manager can decrypt newSSL connections. Clients send a series of HTTPS requests, each on a new connection, for azero sized file. SSL session IDs are not reused, so each connection requires a full SSLhandshake. 1024 bit RC-4 encryption is used.SSL throughput: The throughput Zeus Traffic Manager can sustain whilst performing SSLdecryption. Each client sends its requests on an existing keepalive connection and SSLsession IDs are reused. The test measures the performance of the cipher used to encryptand decrypt the data passed along the SSL connection.Z e u s Tr a f f i c M a n a g e r V A P e r f o r m a n c e o n V M w a r e v S p h e r e 4Page 4 of 8Zeus. Why wait.

Cache requests per second: The rate at which Zeus Traffic Manager can serve small filesdirectly from its cache.Cache throughput: The throughput that Zeus Traffic Manager can sustain when servinglarge files from its cache.Z e u s Tr a f f i c M a n a g e r V A P e r f o r m a n c e o n V M w a r e v S p h e r e 4Page 5 of 8Zeus. Why wait.

ResultsThe following table presents the raw performance figures for the native hardware runningZeus Traffic Manager and each of the virtual machine configurations running Zeus TrafficManager VA:Test NameNative1 vCPU2 vCPU3 vCPU4 113000104000HTTP 2k req/s7520047400643006920063000HTTP 8k req/s4480030200382003850037000HTTP throughput (GBits)3.232.733.012.982.97SSL conn/s83002350440065407790SSL throughput 002020004.013.9943.993.99theperformanceL4 conn/sL4 req/sHTTP conn/sHTTP req/sCache req/sCache throughput (GBits)Thefollowingchartcomparesof eachof thevirtualmachineconfigurations against the native hardware performance:Performance as a percentage of native140%120%100%80%60%40%20%0%1 vCPUZ e u s Tr a f f i c M a n a g e r V A P e r f o r m a n c e o n V M w a r e v S p h e r e 4Page 6 of 82 vCPU3 vCPU4 vCPUZeus. Why wait.

AnalysisThe chart presented above shows the difference in performance between benchmarks foreach virtual machine configuration. The configurations vary by the number of virtual CPUsconfigured.The results obtained do not show perfectly linear scaling with the number of vCPUsassigned to the virtual machine. This is due to the hypervisor using some CPU time tomanage the network traffic and virtual machines. On production systems running othervirtual machines performance figures will scale differently from those obtained here.With the exception of SSL connections/second, the results obtained using vSphere 4.0 areapproximately 25% better than results obtained on the same System under Test (SUT)using ESX 3.5 update 4. This shows the huge performance improvements in the currentvSphere 4.0 hypervisor.Cache throughput tests show results consistently at 4Gb/second. This was the maximumnetwork bandwidth available on the SUT; using a 10Gb network or more 1Gb networkcards cache throughput would be higher.Performance for some configurations and benchmarks, in particular with 3 vCPUs, wasfaster than running on a native installation of Linux. Typically with previous generations ofhypervisor there would be a performance hit running under a virtual environment.However these numbers show the advantage of the highly optimized vSphere networkstack coupled with a tuned Virtual Appliance.Performance would normally be expected to decrease when configuring fewer vCPUs forthe virtual machine. The figures obtained, however, show that 3vCPUs mostly obtainedhigher figures than the 4vCPU configuration. This is likely to be caused by co-schedulingrestrictions, with the service console requiring some CPU time, and the need for thevSphere network layer to consume some resource.Overall, the 3 vCPU configuration obtained the best performance, with the averageperformance the same as native, and SSL connections/second showing the lowestperformance at 78% of native. The SSL connections/second test has a relatively smallamount of network traffic and is highly dependent on CPU speed; with 25% fewer CPUs itis therefore expected that the performance drops by approximately 25%.VMware’s performance tuning guide for ESX2 highlights that running a single-vCPU virtualappliance can have performance benefits over running a multiple-vCPU virtual appliance.The performance of the 1-vCPU appliances in these benchmarks was quite strong, so if thenecessary workload can be met with a single vCPU then it could improve the overallperformance of the system when compared with running a multiple-vCPU appliance tocover the same workload.2“Performance Tuning Best Practices for ESX Server 3” (VMware). Available at[http://www.vmware.com/pdf/vi performance tuning.pdf]Z e u s Tr a f f i c M a n a g e r V A P e r f o r m a n c e o n V M w a r e v S p h e r e 4Page 7 of 8Zeus. Why wait.

For further information, please email: info@zeus.com or visit www.zeus.comStay in touch with Zeus by following: blog.zeus.com or twitter.com/ZeusTechnologyTry before you buy.Simply visit our website: www.zeus.com/downloadsTechnical support is also available during your evaluation.Zeus Technology Limited (UK)Sales: 44 (0)1223 568555Zeus Technology, Inc. (U.S.)Phone: 1-888-ZEUS-INCThe Jeffreys BuildingMain: 44 (0)1223 5250001875 South Grant StreetFax:Cowley RoadFax:Suite 720Email: info@zeus.comCambridge CB4 0WSEmail: info@zeus.comSan Mateo, California 94402Web:United KingdomWeb:United States of America. 44 (0)1223 525100www.zeus.com1-866-628-7884www.zeus.com Zeus Technology Limited 2009. All rights reserved. Zeus, Zeus Technology, the Zeus logo, Zeus Web Server, TrafficScript,Zeus Traffic Manager and Cloud Traffic Manager are trademarks of Zeus Technology. All other brands and product names may betrademarks or registered trademarks of their respective owners.

Zeus Traffic Manager was running on the system under test and load balanced the requests across the web servers, which consisted of 64-bit dual- and quad-core CPU machines also running Linux. The requests were generated by a program called Zeusbench1, a high-performance, vendor