Determining the Remote Client Perceived Response Time from Live Packet Streams David P
Total Page:16
File Type:pdf, Size:1020Kb
Appears in Proceedings of the Sixth Symposium on Operating Systems Design and Implementation (OSDI 2004) ksniffer: Determining the Remote Client Perceived Response Time from Live Packet Streams David P. Olshefski1;2, Jason Nieh1 and Erich Nahum2 1Columbia University and 2IBM T.J Watson Research [email protected], [email protected], [email protected] Abstract Server farm management systems that allocate re- sources on-demand to meet specified response time goals As dependence on the World Wide Web continues to are receiving much attention. The ability of a Web host- grow, so does the need for businesses to have quantitative ing center to move CPU cycles, machines, bandwidth measures of the client perceived response times of their and storage from a hosted Web site that is meeting its Web services. We present ksniffer, a kernel-based traf- latency goal to one that is not, is a key requirement for fic monitor capable of determining pageview response an automated management system. Such allocation de- times as perceived by remote clients, in real-time at giga- cisions must be based on accurate measurements. Over- bit traffic rates. ksniffer is based on novel, online mech- allocating resources to one hosted Web site results in an anisms that take a “look once, then drop” approach to overcharge to that customer and a reduction in the avail- packet analysis to reconstruct TCP connections and learn able physical resources left to meet the needs of the oth- client pageview activity. These mechanisms are designed ers. Under-allocation results in poor response time and to operate accurately with live network traffic even in the unsatisfied Web site users. The ability to base these al- presence of packet loss and delay, and can be efficiently location decisions on a measure that is relevant to both implemented in kernel space. This enables ksniffer to the Web site owner and the end user of the Web site is a perform analysis that exceeds the functionality of cur- competitive advantage. rent traffic analyzers while doing so at high bandwidth Unfortunately, obtaining an accurate measure of the rates. ksniffer requires only to passively monitor network client perceived response time is non-trivial. Current ap- traffic and can be integrated with systems that perform proaches include active probing from geographically dis- server management to achieve specified response time tributed monitors, instrumenting HTML Web pages with goals. Our experimental results demonstrate that ksnif- JavaScript, offline analysis of packet traces, and instru- fer can run on an inexpensive, commodity, Linux-based menting Web servers to measure application-level per- PC and provide online pageview response time measure- formance or per connection performance. All of these ments, across a wide range of operating conditions, that approaches fall short, in one area or another, in terms of are within five percent of the response times measured at accuracy, cost, scalability, usefulness of information col- the client by detailed instrumentation. lected, and real-time availability of measurements. We have created ksniffer, an online server-side traffic 1 Introduction monitor that combines passive packet capture with fast For many businesses, the World Wide Web is a highly online mechanisms to accurately determine client per- competitive environment. Customers seeking quality on- ceived pageview response times on a per pageview basis. line services have choices, and often the characteristic ksniffer uses a model of TCP retransmission and expo- that distinguishes a successful site from the rest is per- nential backoff that accounts for latency due to connec- formance. Clients are keenly aware when response time tion setup overhead and network packet loss. It combines exceeds acceptable thresholds and are not hesitant to this model with higher level online mechanisms that use simply take their business elsewhere. It is therefore ex- access history and HTTP referer information when avail- tremely important for businesses to know the response able to learn relationships among Web objects to corre- time that their clients are experiencing. This places them late connections and Web objects to determine pageview in a difficult position: having to obtain accurate client response times. perceived response time metrics in a timely, cost effec- ksniffer mechanisms take a “look once, then drop” ap- tive manner so that problems can be immediately iden- proach to packet analysis, use simple hashing data struc- tified and fixed. For larger Web sites, the requirement tures to match Web objects to pageviews, and can be of having a scalable solution is key; in addition, the ca- efficiently implemented in kernel space. Furthermore, pability to transmit this information to an online cluster ksniffer only looks at TCP/IP and HTTP protocol header management system is also a necessity. information and does not need to parse any HTTP data 1 Appears in Proceedings of the Sixth Symposium on Operating Systems Design and Implementation (OSDI 2004) ksniffer Machine payload. This enables ksniffer to perform higher level Web pageview analysis effectively online in the presence Local Analysis of high data rates; it can monitor traffic at gigabit line user mmap kernel speeds while running on an inexpensive, commodity PC. Socket These mechanisms enable ksniffer to provide accurate (a) TCP filtering config results across a wide range of operating conditions, in- files protocol (b) cluding high load, connection drops, and packet loss. In analysis IP these cases, obtaining accurate performance measures is most crucial because Web server and network resources device independent may be overloaded. ksniffer has several advantages over other approaches. device driver device driver Remote First, ksniffer does not require any modifications to Web packet stream Analysis pages, Web servers, or browsers, making deployment Figure 1: ksniffer architecture. easier and faster. This is particularly important for Web hosting companies responsible for maintaining the in- as well as a platform for research into traffic analysis. frastructure surrounding a Web site but are often not Figure 1 depicts the ksniffer architecture. permitted to modify the customer’s server machines or ksniffer is designed to be implemented as a set of dy- content. Second, ksniffer captures network character- namically loadable kernel modules that reside above the istics such as packet loss and delay, aiding in distin- network device independent layer in the operating sys- guishing network problems from server problems. Third, tem. Its device independence makes it easy to deploy ksniffer measures the behavior of every session for ev- on any inexpensive, commodity PC without special NIC ery real client who visits the Web site. Therefore, it hardware or device driver modifications. ksniffer appears does not fall prey to biases that arise when sampling to the kernel simply as another network protocol layer from a select, predefined set of client monitoring ma- within the stack and is treated no different than TCP/IP, chines that have better connectivity, and use different which is shown for comparison in Figure 1. ksniffer Web browser software, than the actual users of the Web monitors bidirectional traffic and looks at each packet site. Fourth, ksniffer can obtain metrics for any Web once, extracts any TCP/IP or HTTP header information content, not just HTML. Fifth, ksniffer performs online that is present, then discards the packet. The in-kernel analysis of high bandwidth, live packet traffic instead of implementation exploits several performance advantages offline analysis of traces stored on disk, bypassing the such as zero-copy buffer management, eliminated sys- need to manage large amounts of disk storage to store tem calls, and reduced context switches [16, 17]. ksniffer packet traces. More importantly, ksniffer can provide does not produce packet trace log files, but can read con- performance measurements to Web servers in real-time, figuration parameters and write debugging information enabling them to respond immediately to performance to disk from kernel space. problems through diagnosis and resource management. This design gives ksniffer a three to four fold improve- This paper presents the design and implementation of ment in performance over user space systems that copy ksniffer. Section 2 presents an overview of the ksniffer every packet to user space. Each packet could potentially architecture. Section 3 describes the ksniffer algorithms impact the response time measurement, yet ksniffer only for reconstructing TCP connections and pageview activ- examines a small percentage of the bytes within each ities. Section 4 discusses how ksniffer handles less ideal packet (TCP/IP fields and the HTTP headers, if present). operating conditions, such as packet loss and server over- By executing in kernel space, ksniffer avoids transferring load. Section 5 presents experimental results quantifying large amounts of irrelevant bytes to user space, saving the accuracy and scalability of ksniffer under various op- CPU cycles and memory bandwidth. erating conditions. We measure the accuracy of ksniffer ksniffer provides a low overhead shared memory in- against measurements obtained at the client and compare terface (similar to MAGNET [13]) to export results (not the scalability of ksniffer against user-space packet anal- packets) to user space. This allows more sophisticated ysis systems. Section 6 discusses related work. Finally, analysis that is less performance critical