210 likes | 369 Views
Measuring The Capacity of a Web server. By Xiongjun Tang. Topics. Introduction Dynamics of HTTP Server Problems in generating Synthetic HTTP requests A Scalable method for Generating HTTP requests Quantitative Evaluation Conclusion. Introduction.
E N D
Measuring The Capacity of a Web server By Xiongjun Tang
Topics • Introduction • Dynamics of HTTP Server • Problems in generating Synthetic HTTP requests • A Scalable method for Generating HTTP requests • Quantitative Evaluation • Conclusion
Introduction • Recently improvement on performance of web server • Better Web cashing • Application-level cashing (L7 cluster) • HTTP protocol enhancement • data compression • Better HTTP servers and proxies • Server OS implementation • tuning parameter in OS to get better performance
Introduction (continued) • Measuring Web server (characters) • request file types • transfer data sizes • locality of reference in URL • Using real workload directly
Introduction (continued) • Simple scheme of WEB client Generator • client establishes connection • send a HTTP request • receive response • wait for a certain time (Think time) • repeat the cycle • Adding client processes = increase total client requests
Introduction (continued) • Problems with naive method • Hard to exceed server’s capacity • Little resemblance in temporal characteristic to real-world Web traffic • Difference between delay and lose of WAN and LAN • limited resource on client machine
HTTP Connection Timeline 1. A web server listen for connection 2. Receive a client request (SYN packet) 3. Server TCP responds SYN-ACK packet, create socket for new,incomplete connection, and place it in SYN-RECN queue 4. Client responds ACK, server move socket created above from SYN-RECV to accept queue 5. Server remove first socket in queue and send back appropriate responses, then close connection
Limitation of TCP Implementation • Most system has a maximum number of backlog (Sum of length of SYN-RCVD queue and Accept Queue) • if sum > 1.5*backlog, server will drop incoming SYN packet • when TCP misses SYN-ACK packet, it goes into a exponential back-off status, For BSD system, it will send request at 6 seconds and 30 seconds after first SYN is sent before finally give up at 75 seconds. • If no SYN-ACK, it will only send 3 requests for during 75 seconds! • The Average length of SYN-RCVD depends on request rate and round-trip delay between client and server • long round-trip delay and high request rate increase SYN-RCVD length • Accept queue length depends on CPU handling speed and request rate
Problems in Generating Synthetic HTTP request • 1. Inability to generate Excess load • In real world HTTP requests are generated by huge number of clients • large mean and variance • requests are bursty ( such as France 98) • peak request can easily exceeds capacity of server • In simple model • small mean and variance • little burstiness
Why can’t simple method generate excess load • A new request can only be generate after a pervious one completed • when clients increase, the queue increases,so it will take CPU longer time to finish a connection, thus completed time increases, so request generating decrease. • The net connection request rate of all clients will remain equal to throughput of server • when clients is greater than server’s maximum backlog, server is beginning to drop SYN packet. • TCP exponential backoff will happen, generate further requests at very low rate
Request Rate vs. no. of clients • A example How many client will be requested to generate 1100 requests/sec? y-100 = (x-1024)*0.04 --> x = 1024 + (y-100)/0.04 if y = 1100 then x = 1024 + 1000/0.04 --> x = 1024 + 25000 (on paper is order of 15000) • If Max connection = 32767 1.5*32767+15000 = 64151 to generate 1100 requests/sec.
Additional Problem • Simple Method does not model high and variable WAN delay • Resource constrain in client machine • if too many processes, the contention for CPU and memory will increase. • Potential bottleneck • server is OK, but clients wait for resource
A Scalable Method for Generating HTTP request • Total P machines • Each machine running several S-clients • A Router can be used to simulate wan delay
S-Client • Created by a UNIX domain socketpair call • it has two processes, one is connection establishment process, the other is connection handling process • connection establishment process • purpose: to generate HTTP request at certain rate and with certain distribution • open D connections by using D sockets, requests are spaced out over T ms • after each socket is created, a timer is associated with it. • If in time T, it get the response from server, it will hand off to connection handling process. Close this socket, initiate another connection to server • if in time T, it don’t get response from server, close it, then initiate another connection to server • all avoid TCP exponential back-off
S-Client (continued) • Connection handling process • waiting data to arrive on any of active connections • if any new data coming, read it. If this completes, close the socket. • waiting for new connection to arrive on UNIX domain socket connecting to the other process • simply added to active pool of active connections
A S-client • Two key ideas: 1.shorten TCP connection timeout this will allow generati- on of request rate bey- ond capacity of server increase at least 1/T 2.maintain a constant number of unconnected sockets this will ensure generated request rate is independent of the rate at which server handles request
Request generating capacity of a client machine • Purpose • To use as less S-client to generate as many requests • Choose largest allowable number of descriptors(N) • How to get it ? • Choose a value largest value N, for which throughput Vs request rate curve when using 1 client machine is unchanged from the same curve when using 2 client machines.
Quantitative Evaluation • Each HTTP request is for a single file of size 1294 • No more than 130 requests/sec for simple method • with S-clients, up to 2065 requests/sec (limitation of machine resource) • T value for S-client is 500ms
Overload behavior • Why Dropped ? • Because CPU resource spent on protocol processing for incoming requests (SYN packet)
Bursty Condition • First parameter: the ration between Max request rate and average request rate • second parameter: the fraction of time for which request of rate exceed average rate • In general high busrtiness both in above two parameters degrades the throughput of server substantially
Conclusion • This paper examines pitfall in process of generating synthetic web server workload consisting of a small number of client machine • It exposes the limitation of simple method • A new method (S-client) is introduced, which can easily generate workload exceeding capacity of server as well as bursty workload • it will help study of the characters when server is in overload status and then improve the performance of server