Phelps AJ T 2020.Pdf (1.937Mb)

Total Page:16

File Type:pdf, Size:1020Kb

Phelps AJ T 2020.Pdf (1.937Mb) ink - An HTTP Benchmarking Tool Andrew J. Phelps Thesis submitted to the Faculty of the Virginia Polytechnic Institute and State University in partial fulfillment of the requirements for the degree of Master of Science in Computer Science & Application Godmar V. Back, Chair Ali R. Butt Denis Gracanin May 11, 2020 Blacksburg, Virginia Keywords: Networking, Benchmarking, HTTP, Distributed Systems Copyright 2020, Andrew J. Phelps ink - An HTTP Benchmarking Tool Andrew J. Phelps (ABSTRACT) The Hypertext Transfer Protocol (HTTP) is one the foundations of the modern Internet. Because HTTP servers may be subject to unexpected periods of high load, developers use HTTP benchmarking utilities to simulate the load generated by users. However, many of these tools do not report performance details at a per-client level, which deprives developers of crucial insights into a server’s performance capabilities. In this work, we present ink, an HTTP benchmarking tool that enables developers to better understand server performance. ink provides developers with a way of visualizing the level of service that each individual client receives. It does this by recording a trace of events for each individual simulated client. We also present a GUI that enables users to explore and visualizing the data that is generated by an HTTP benchmark. Lastly, we present a method for running HTTP benchmarks that uses a set of distributed machines to scale up the achievable load on the benchmarked server. We evaluate ink by performing a series of case studies to show that ink is both performant and useful. We validate ink’s load generation abilities within the context of a single machine and when using a set of distributed machines. ink is shown to be capable of simulating hundreds of thousands of HTTP clients and presenting per-client results through the ink GUI. We also perform a set of HTTP benchmarks where ink is able to highlight performance issues and differences between server implementations. We compare servers like NGINX and Apache and highlight their differences using ink. ink - An HTTP Benchmarking Tool Andrew J. Phelps (GENERAL AUDIENCE ABSTRACT) The World Wide Web (WWW) uses the Hypertext Transfer Protocol to send web content such as HTML pages or video to users. The servers providing this content are called HTTP servers. Sometimes, the performance of these HTTP servers is compromised because a large number of users requests documents at the same time. To prepare for this, server maintainers test how many simultaneous users a server can handle by using benchmarking utilities. These benchmarking utilities work by simulating a set of clients. Currently, these tools focus only on the amount of requests that a server can process per second. Unfortunately, this coarse- grained metric can hide important information, such as the level of service that individual clients received. In this work, we present ink, an HTTP benchmarking utility we developed that focuses on reporting information for each simulated client. Reporting data in this way allows for the developer to see how well each client was served during the benchmark. We achieve this by constructing data visualizations that include a set of client timelines. Each of these timelines represents the service that one client received. We evaluated ink through a series of case studies. These focus on the performance of the utility and the usefulness of the visualizations produced by ink. Additionally, we deployed ink in Virginia Tech’s Computer Systems course. The students were able to use the tool and took a survey pertaining to their experience with the tool. Acknowledgments First, I would like to thank my advisor, Dr. Back, for helping me perform this research. He has been of immense help over the last year, and he has been a resource of knowledge for me. He has spent a great amount of his own time assisting me, and his guidance has helped me complete this research and this document. I would also like to thank the rest of my committee, Dr. Butt and Dr. Gracanin, for the insights that they provided on this work. They both made suggestions that improved the quality of this research. Specifically, I’d like to thank Dr. Gracanin for taking the time to go through this entire thesis with me. iv Contents List of Figures vii List of Tables ix 1 Introduction 1 1.1 Testing for Performance ............................. 1 1.2 Proposed Solution ................................ 3 1.3 Contributions ................................... 6 1.4 Roadmap ..................................... 7 2 Background Information 8 2.1 Transmission Control Protocol .......................... 8 2.2 Hypertext Transfer Protocol ........................... 13 2.3 HTTP Server Concurrency Models ....................... 17 2.4 Linux Connection Management ......................... 22 2.5 HTTP Benchmarking ............................... 26 3 Design and Implementation 32 3.1 Load Generation ................................. 34 v 3.2 Distributed Benchmarking Manager ....................... 38 3.3 ink API ...................................... 41 3.4 ink GUI ...................................... 44 4 Evaluation 58 4.1 Goals and Methodology ............................. 58 4.2 Assessing ink’s Load Generation Ability .................... 60 4.3 Evaluating Server Performance with ink .................... 69 4.4 Survey Results .................................. 83 5 Related Work 86 5.1 Assessing Server Quality and Performance ................... 86 5.2 Visualization Techniques ............................. 90 6 Future Work 92 6.1 Load Generation Improvements ......................... 92 6.2 GUI Improvements ................................ 92 7 Conclusion 94 Bibliography 96 List of Figures 2.1 Example of HTTP clients experiencing different levels of service, leading to misleading data points .............................. 30 3.1 High level overview of ink’s architecture .................... 33 3.2 Brewer’s red-to-green divergent color scheme [1] ................ 46 3.3 100 client moving averages rendered using colored line segments ....... 49 3.4 1; 000 concurrent clients rendered as 200 timelines ............... 51 3.5 1; 000 concurrent clients rendered as 50 timelines ............... 52 3.6 Image of the dashboard of alternative data visualizations. Visualizations are based on the same dataset as Figure 3.3 .................... 54 3.7 2; 000 clients grouped by physical machine origin ............... 57 4.1 Benchmarking with 43; 520 simulated clients and 17 physical clients ..... 62 4.2 Benchmarking with 87; 040 simulated clients and 17 physical clients ..... 63 4.3 Benchmarking with 174; 080 simulated clients and 17 physical clients .... 64 4.4 Benchmarking with 348; 160 simulated clients and 17 physical clients .... 65 4.5 Requests-per-second generated by NGINX under varying levels of load ... 66 4.6 Average request latency observed by clients benchmarking NGINX ...... 67 vii 4.7 Histogram of latencies from benchmark with 348,160 connections and 17 phys- ical clients ..................................... 68 4.8 File descriptors allocated by HTTP server during 60 second benchmark ... 70 4.9 An ink report that indicates that only half of clients were served. Observed TCP connections are marked by black dots. .................. 71 4.10 Memory usage of HTTP server during 60 second benchmark ......... 72 4.11 Benchmark with 15; 000 clients released in waves of 5; 000 clients every 30 seconds ...................................... 74 4.12 CPU usage of pre-fork Apache HTTP server with 1; 000 concurrent connections 77 4.13 Network usage of pre-fork Apache HTTP server with 1; 000 concurrent con- nections ...................................... 78 4.14 CPU usage of NGINX HTTP server with 1; 000 concurrent connections ... 79 4.15 Network usage of NGINX HTTP server with 1; 000 concurrent connections . 80 4.16 Client timelines of pre-fork Apache HTTP server with 1; 000 concurrent con- nections ...................................... 81 4.17 Client timelines of NGINX HTTP server with 1; 000 concurrent connections 82 List of Tables 2.1 Comparison of load generated on NGINX by popular HTTP benchmarking tools ........................................ 28 4.1 Comparison of RPS generated by original wrk and modified wrk ....... 61 ix Chapter 1 Introduction Society is becoming more and more reliant on web-based services. Websites, mobile appli- cations, and headless systems are all connected to the Internet. A large number of these services is built upon the Hypertext Transfer Protocol (HTTP), which is the most popular application layer protocol that is used on the Internet today. HTTP is far from its simple origins of transferring markup files; now, complex, critical systems use HTTP to transfer important data. For this reason, it is important that the performance of these services can be tested adequately. If critical services, such as government health care services [2], run on top of HTTP, developers need to understand the impact that a sudden surge of users can have on their application. Crisis situations can lead to unforeseen spikes in the load being put on web servers [3]. Even applications that were developed with a smaller target audience in mind can be subject to heavy load if a “Slashdot Effect” [4] occurs in which an unprepared HTTP server is accessed by thousands of users in an instant. 1.1 Testing for Performance To help prepare for situations that result in an unexpected influx of traffic, developers have created specialized software that can simulate
Recommended publications
  • Microprocessor
    MICROPROCESSOR www.MPRonline.com THE REPORTINSIDER’S GUIDE TO MICROPROCESSOR HARDWARE EEMBC’S MULTIBENCH ARRIVES CPU Benchmarks: Not Just For ‘Benchmarketing’ Any More By Tom R. Halfhill {7/28/08-01} Imagine a world without measurements or statistical comparisons. Baseball fans wouldn’t fail to notice that a .300 hitter is better than a .100 hitter. But would they welcome a trade that sends the .300 hitter to Cleveland for three .100 hitters? System designers and software developers face similar quandaries when making trade-offs EEMBC’s role has evolved over the years, and Multi- with multicore processors. Even if a dual-core processor Bench is another step. Originally, EEMBC was conceived as an appears to be better than a single-core processor, how much independent entity that would create benchmark suites and better is it? Twice as good? Would a quad-core processor be certify the scores for accuracy, allowing vendors and customers four times better? Are more cores worth the additional cost, to make valid comparisons among embedded microproces- design complexity, power consumption, and programming sors. (See MPR 5/1/00-02, “EEMBC Releases First Bench- difficulty? marks.”) EEMBC still serves that role. But, as it turns out, most The Embedded Microprocessor Benchmark Consor- EEMBC members don’t openly publish their scores. Instead, tium (EEMBC) wants to help answer those questions. they disclose scores to prospective customers under an NDA or EEMBC’s MultiBench 1.0 is a new benchmark suite for use the benchmarks for internal testing and analysis. measuring the throughput of multiprocessor systems, Partly for this reason, MPR rarely cites EEMBC scores including those built with multicore processors.
    [Show full text]
  • Load Testing, Benchmarking, and Application Performance Management for the Web
    Published in the 2002 Computer Measurement Group (CMG) Conference, Reno, NV, Dec. 2002. LOAD TESTING, BENCHMARKING, AND APPLICATION PERFORMANCE MANAGEMENT FOR THE WEB Daniel A. Menascé Department of Computer Science and E-center of E-Business George Mason University Fairfax, VA 22030-4444 menasce@cs.gmu.edu Web-based applications are becoming mission-critical for many organizations and their performance has to be closely watched. This paper discusses three important activities in this context: load testing, benchmarking, and application performance management. Best practices for each of these activities are identified. The paper also explains how basic performance results can be used to increase the efficiency of load testing procedures. infrastructure depends on the traffic it expects to see 1. Introduction at its site. One needs to spend enough but no more than is required in the IT infrastructure. Besides, Web-based applications are becoming mission- resources need to be spent where they will generate critical to most private and governmental the most benefit. For example, one should not organizations. The ever-increasing number of upgrade the Web servers if most of the delay is in computers connected to the Internet and the fast the database server. So, in order to maximize the growing number of Web-enabled wireless devices ROI, one needs to know when and how to upgrade create incentives for companies to invest in Web- the IT infrastructure. In other words, not spending at based infrastructures and the associated personnel the right time and spending at the wrong place will to maintain them. By establishing a Web presence, a reduce the cost-benefit of the investment.
    [Show full text]
  • Overview of the SPEC Benchmarks
    9 Overview of the SPEC Benchmarks Kaivalya M. Dixit IBM Corporation “The reputation of current benchmarketing claims regarding system performance is on par with the promises made by politicians during elections.” Standard Performance Evaluation Corporation (SPEC) was founded in October, 1988, by Apollo, Hewlett-Packard,MIPS Computer Systems and SUN Microsystems in cooperation with E. E. Times. SPEC is a nonprofit consortium of 22 major computer vendors whose common goals are “to provide the industry with a realistic yardstick to measure the performance of advanced computer systems” and to educate consumers about the performance of vendors’ products. SPEC creates, maintains, distributes, and endorses a standardized set of application-oriented programs to be used as benchmarks. 489 490 CHAPTER 9 Overview of the SPEC Benchmarks 9.1 Historical Perspective Traditional benchmarks have failed to characterize the system performance of modern computer systems. Some of those benchmarks measure component-level performance, and some of the measurements are routinely published as system performance. Historically, vendors have characterized the performances of their systems in a variety of confusing metrics. In part, the confusion is due to a lack of credible performance information, agreement, and leadership among competing vendors. Many vendors characterize system performance in millions of instructions per second (MIPS) and millions of floating-point operations per second (MFLOPS). All instructions, however, are not equal. Since CISC machine instructions usually accomplish a lot more than those of RISC machines, comparing the instructions of a CISC machine and a RISC machine is similar to comparing Latin and Greek. 9.1.1 Simple CPU Benchmarks Truth in benchmarking is an oxymoron because vendors use benchmarks for marketing purposes.
    [Show full text]
  • Model Driven Scheduling for Virtualized Workloads
    Model Driven Scheduling for Virtualized Workloads Proefschrift voorgelegd op 28 juni 2013 tot het behalen van de graad van Doctor in de Wetenschappen – Informatica, bij de faculteit Wetenschappen, aan de Universiteit Antwerpen. PROMOTOREN: prof. dr. Jan Broeckhove dr. Kurt Vanmechelen Sam Verboven RESEARCH GROUP COMPUTATIONAL MODELINGAND PROGRAMMING Dankwoord Het behalen van een doctoraat is een opdracht die zonder hulp onmogelijk tot een goed einde kan gebracht worden. Gelukkig heb ik de voorbije jaren de kans gekregen om samen te werken met talrijke stimulerende collega’s. Stuk voor stuk hebben zij bijgedragen tot mijn professionele en persoonlijke ontwikkeling. Hun geduldige hulp en steun was essentieel bij het overwinnen van de vele uitdagingen die met een doctoraat gepaard gaan. Graag zou ik hier dan ook enkele woorden van dank neerschrijven. Allereerst zou ik graag prof. dr. Jan Broeckhove en em. prof. dr. Frans Arickx bedanken om mij de kans te geven een gevarieerde en boeiend academisch traject te starten. Bij het beginnen van mijn doctoraat heeft Frans mij niet alleen geholpen om een capabel onderzoeker te worden, ook bij het lesgeven heeft hij mij steeds met raad en daad bijgestaan. Na het emiraat van Frans heeft Jan deze begeleiding overgenomen en er voor gezorgd dat ik het begonnen traject ook succesvol kon beeïndigen. Beiden hebben ze mij steeds grote vrijheid gegeven in mijn zoektocht om interessante onderzoeksvragen te identificeren en beantwoorden. Vervolgens zou ik graag dr. Peter Hellinckx en dr. Kurt Vanmechelen bedanken voor hun persoonlijke en vaak intensieve begeleiding. Zelfs voor de start van mijn academische carrière, bij het schrijven van mijn Master thesis, heeft Peter mij klaar- gestoomd voor een vlotte start als onderzoeker.
    [Show full text]
  • Opportunities and Open Problems for Static and Dynamic Program Analysis Mark Harman∗, Peter O’Hearn∗ ∗Facebook London and University College London, UK
    1 From Start-ups to Scale-ups: Opportunities and Open Problems for Static and Dynamic Program Analysis Mark Harman∗, Peter O’Hearn∗ ∗Facebook London and University College London, UK Abstract—This paper1 describes some of the challenges and research questions that target the most productive intersection opportunities when deploying static and dynamic analysis at we have yet witnessed: that between exciting, intellectually scale, drawing on the authors’ experience with the Infer and challenging science, and real-world deployment impact. Sapienz Technologies at Facebook, each of which started life as a research-led start-up that was subsequently deployed at scale, Many industrialists have perhaps tended to regard it unlikely impacting billions of people worldwide. that much academic work will prove relevant to their most The paper identifies open problems that have yet to receive pressing industrial concerns. On the other hand, it is not significant attention from the scientific community, yet which uncommon for academic and scientific researchers to believe have potential for profound real world impact, formulating these that most of the problems faced by industrialists are either as research questions that, we believe, are ripe for exploration and that would make excellent topics for research projects. boring, tedious or scientifically uninteresting. This sociological phenomenon has led to a great deal of miscommunication between the academic and industrial sectors. I. INTRODUCTION We hope that we can make a small contribution by focusing on the intersection of challenging and interesting scientific How do we transition research on static and dynamic problems with pressing industrial deployment needs. Our aim analysis techniques from the testing and verification research is to move the debate beyond relatively unhelpful observations communities to industrial practice? Many have asked this we have typically encountered in, for example, conference question, and others related to it.
    [Show full text]
  • Towards Better Performance Per Watt in Virtual Environments on Asymmetric Single-ISA Multi-Core Systems
    Towards Better Performance Per Watt in Virtual Environments on Asymmetric Single-ISA Multi-core Systems Viren Kumar Alexandra Fedorova Simon Fraser University Simon Fraser University 8888 University Dr 8888 University Dr Vancouver, Canada Vancouver, Canada vka4@sfu.ca fedorova@sfu.ca ABSTRACT performance per watt than homogeneous multicore proces- Single-ISA heterogeneous multicore architectures promise to sors. As power consumption in data centers becomes a grow- deliver plenty of cores with varying complexity, speed and ing concern [3], deploying ASISA multicore systems is an performance in the near future. Virtualization enables mul- increasingly attractive opportunity. These systems perform tiple operating systems to run concurrently as distinct, in- at their best if application workloads are assigned to het- dependent guest domains, thereby reducing core idle time erogeneous cores in consideration of their runtime proper- and maximizing throughput. This paper seeks to identify a ties [4][13][12][18][24][21]. Therefore, understanding how to heuristic that can aid in intelligently scheduling these vir- schedule data-center workloads on ASISA systems is an im- tualized workloads to maximize performance while reducing portant problem. This paper takes the first step towards power consumption. understanding the properties of data center workloads that determine how they should be scheduled on ASISA multi- We propose that the controlling domain in a Virtual Ma- core processors. Since virtual machine technology is a de chine Monitor or hypervisor is relatively insensitive to changes facto standard for data centers, we study virtual machine in core frequency, and thus scheduling it on a slower core (VM) workloads. saves power while only slightly affecting guest domain per- formance.
    [Show full text]
  • Evaluation of AMD EPYC
    Evaluation of AMD EPYC Chris Hollowell <hollowec@bnl.gov> HEPiX Fall 2018, PIC Spain What is EPYC? EPYC is a new line of x86_64 server CPUs from AMD based on their Zen microarchitecture Same microarchitecture used in their Ryzen desktop processors Released June 2017 First new high performance series of server CPUs offered by AMD since 2012 Last were Piledriver-based Opterons Steamroller Opteron products cancelled AMD had focused on low power server CPUs instead x86_64 Jaguar APUs ARM-based Opteron A CPUs Many vendors are now offering EPYC-based servers, including Dell, HP and Supermicro 2 How Does EPYC Differ From Skylake-SP? Intel’s Skylake-SP Xeon x86_64 server CPU line also released in 2017 Both Skylake-SP and EPYC CPU dies manufactured using 14 nm process Skylake-SP introduced AVX512 vector instruction support in Xeon AVX512 not available in EPYC HS06 official GCC compilation options exclude autovectorization Stock SL6/7 GCC doesn’t support AVX512 Support added in GCC 4.9+ Not heavily used (yet) in HEP/NP offline computing Both have models supporting 2666 MHz DDR4 memory Skylake-SP 6 memory channels per processor 3 TB (2-socket system, extended memory models) EPYC 8 memory channels per processor 4 TB (2-socket system) 3 How Does EPYC Differ From Skylake (Cont)? Some Skylake-SP processors include built in Omnipath networking, or FPGA coprocessors Not available in EPYC Both Skylake-SP and EPYC have SMT (HT) support 2 logical cores per physical core (absent in some Xeon Bronze models) Maximum core count (per socket) Skylake-SP – 28 physical / 56 logical (Xeon Platinum 8180M) EPYC – 32 physical / 64 logical (EPYC 7601) Maximum socket count Skylake-SP – 8 (Xeon Platinum) EPYC – 2 Processor Inteconnect Skylake-SP – UltraPath Interconnect (UPI) EYPC – Infinity Fabric (IF) PCIe lanes (2-socket system) Skylake-SP – 96 EPYC – 128 (some used by SoC functionality) Same number available in single socket configuration 4 EPYC: MCM/SoC Design EPYC utilizes an SoC design Many functions normally found in motherboard chipset on the CPU SATA controllers USB controllers etc.
    [Show full text]
  • Big Data Benchmarking Workshop Publications
    Benchmarking Datacenter and Big Data Systems Wanling Gao, Zhen Jia, Lei Wang, Yuqing Zhu, Chunjie Luo, Yingjie Shi, Yongqiang He, Shiming Gong, Xiaona Li, Shujie Zhang, Bizhu Qiu, Lixin Zhang, Jianfeng Zhan INSTITUTE OFTECHNOLOGY COMPUTING http://prof.ict.ac.cn/ICTBench 1 Acknowledgements This work is supported by the Chinese 973 project (Grant No.2011CB302502), the Hi- Tech Research and Development (863) Program of China (Grant No.2011AA01A203, No.2013AA01A213), the NSFC project (Grant No.60933003, No.61202075) , the BNSFproject (Grant No.4133081), and Huawei funding. 2/ Big Data Benchmarking Workshop Publications BigDataBench: a Big Data Benchmark Suite from Web Search Engines. Wanling Gao, et al. The Third Workshop on Architectures and Systems for Big Data (ASBD 2013) in conjunction with ISCA 2013. Characterizing Data Analysis Workloads in Data Centers. Zhen Jia, et al. 2013 IEEE International Symposium on Workload Characterization (IISWC-2013) Characterizing OS behavior of Scale-out Data Center Workloads. Chen Zheng et al. Seventh Annual Workshop on the Interaction amongst Virtualization, Operating Systems and Computer Architecture (WIVOSCA 2013). In Conjunction with ISCA 2013.[ Characterization of Real Workloads of Web Search Engines. Huafeng Xi et al. 2011 IEEE International Symposium on Workload Characterization (IISWC-2011). The Implications of Diverse Applications and Scalable Data Sets in Benchmarking Big Data Systems. Zhen Jia et al. Second workshop of big data benchmarking (WBDB 2012 India) & Lecture Note in Computer
    [Show full text]
  • An Experimental Evaluation of Datacenter Workloads on Low-Power Embedded Micro Servers
    An Experimental Evaluation of Datacenter Workloads On Low-Power Embedded Micro Servers Yiran Zhao, Shen Li, Shaohan Hu, Hongwei Wang Shuochao Yao, Huajie Shao, Tarek Abdelzaher Department of Computer Science University of Illinois at Urbana-Champaign fzhao97, shenli3, shu17, hwang172, syao9, hshao5, zaherg@illinois.edu ABSTRACT To reduce datacenter energy cost, power proportional- This paper presents a comprehensive evaluation of an ultra- ity [47] is one major solution studied and pursued by both low power cluster, built upon the Intel Edison based micro academia and industry. Ideally, it allows datacenter power servers. The improved performance and high energy effi- draw to proportionally follow the fluctuating amount of work- ciency of micro servers have driven both academia and in- load, thus saving energy during non-peak hours. However, dustry to explore the possibility of replacing conventional current high-end servers are not energy-proportional and brawny servers with a larger swarm of embedded micro ser- have narrow power spectrum between idling and full uti- vers. Existing attempts mostly focus on mobile-class mi- lization [43], which is far from ideal. Therefore, researchers cro servers, whose capacities are similar to mobile phones. try to improve energy-proportionality using solutions such We, on the other hand, target on sensor-class micro servers, as dynamic provisioning and CPU power scaling. The for- which are originally intended for uses in wearable technolo- mer relies on techniques such as Wake-On-LAN [36] and gies, sensor networks, and Internet-of-Things. Although VM migration [24] to power on/off servers remotely and dy- sensor-class micro servers have much less capacity, they are namically.
    [Show full text]
  • Adaptive Control of Apache Web Server
    Adaptive Control of Apache Web Server Erik Reed Abe Ishihara Ole J. Mengshoel Carnegie Mellon University Carnegie Mellon University Carnegie Mellon University Moffett Field, CA 94035 Moffett Field, CA 94035 Moffett Field, CA 94035 erikreed@cmu.edu abe.ishihara@sv.cmu.edu ole.mengshoel@sv.cmu.edu Abstract least load. Typical implementations of load balancing deal with round robin balancing for domain name service Traffic to a Web site can vary dramatically. At the same (DNS) [7]. Much of existing frameworks and previous time it is highly desirable that a Web site is reactive. To research deal with inter-server connections and balanc- provide crisp interaction on thin clients, 150 milliseconds ing, with little or no focus on dynamic parameter adjust- has been suggested as an upper bound on response time. ment of individual servers. Unfortunately, the popular Apache Web server is lim- Focusing on an individual Web server rather than a ited in its capabilities to be reactive under varying traf- cluster of machines, we investigate in this paper an alter- fic. To address this problem, we design in this paper an native approach to ensuring quick and predictable user adaptive controller for the Apache Web server. A modi- response, namely feedback control and specifically Min- fied recursive least squares algorithm is used to identify imum Degree Pole Placement control [5]. This can be in system dynamics and a minimum degree pole placement an environment where inter-server load balancing is al- controller is implemented to adjust the maximum num- ready in place, or when a single server is handling Web ber of concurrent connections.
    [Show full text]
  • Energy Efficiency of Server Virtualization
    Energy Efficiency of Server Virtualization Jukka Kommeri Tapio Niemi Olli Helin Helsinki Institute of Physics, Helsinki Institute of Physics, Helsinki Institute of Physics, Technology program, CERN, Technology program, CERN, Technology program, CERN, CH-1211 Geneva 23, Switzerland CH-1211Geneva 23, Switzerland CH-1211 Geneva 23, Switzerland jukka.kommeri@cern.ch tapio.niemi@cern.ch olli.helin@cern.ch Abstract—The need for computing power keeps on growing. combine several services into one physical server. In this The rising energy expenses of data centers have made server way, these technologies make it possible to take better consolidation and virtualization important research areas. advantage of hardware resources. Virtualization and its performance have received a lot of attention and several studies can be found on performance. In this study, we focus on energy efficiency of different So far researches have not studied the overall performance virtualization technologies. Our aim is to help the system and energy efficiency of server consolidation. In this paper we administrator to decide how services should be consolidated study the effect of server consolidation on energy efficiency with to minimize energy consumption without violating quality an emphasis on quality of service. We have studied this with of service agreements. several synthetic benchmarks and with realistic server load by performing a large set of measurements. We found out that We studied energy consumption of virtualized servers with energy-efficiency depends on the load of the virtualized service two open source virtualization solutions; KVM and Xen. and the number of virtualized servers. Idle virtual servers do They were tested both under load and idle.
    [Show full text]
  • Remote Profiling of Resource Constraints of Web Servers Using
    Remote Profiling of Resource Constraints of Web Servers Using Mini-Flash Crowds Pratap Ramamurthy Vyas Sekar Aditya Akella Balachander Krishnamurthy UW-Madison CMU UW-Madison AT&T–Labs Research Anees Shaikh IBM Research Abstract often limited, this can be difficult. Hence, large providers Unexpected surges in Web request traffic can exercise who can afford it typically resort to over-provisioning, or server-side resources (e.g., access bandwidth, process- employ techniques such as distributed content delivery or ing, storage etc.) in undesirable ways. Administra- dynamic server provisioning, to minimize the impact of tors today do not have requisite tools to understand the unexpected surges in request traffic. Smaller application impact of such “flash crowds” on their servers. Most providers may trade-off robustness to large variations in Web servers either rely on over-provisioning and admis- workload for a less expensive infrastructure that is provi- sion control, or use potentially expensive solutions like sioned for the expected common case. CDNs, to ensure high availability in the face of flash This approach still leaves operators without a sense crowds. A more fine-grained understanding of the per- of how their application infrastructure will handle large formance of individual server resources under emulated increases in traffic, due to planned events such as annual but realistic and controlled flash crowd-like conditions sales or Web casts, or unexpected flash crowds. While can aid administrators to make more efficient resource these events may not occur frequently, the inability of the management decisions. In this paper, we present mini- infrastructure to maintain reasonably good service, or at flash crowds (MFC) – a light-weight profiling service least degrade gracefully, can lead to significant loss of that reveals resource bottlenecks in a Web server infras- revenue and dissatisfied users.
    [Show full text]