1 / 30

Measuring the Capacity of a Web Server

Measuring the Capacity of a Web Server. Gaurav Banga Peter Druschel Presenter: Sumit Lohia February 22, 2000. Outline. Introduction HTTP Server Dynamics Simple Request Generator Scalable Clients Evaluation of Scalable Clients Conclusion. Introduction. What do we measure?

arama
Télécharger la présentation

Measuring the Capacity of a Web Server

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Measuring the Capacity of a Web Server Gaurav Banga Peter Druschel Presenter: Sumit Lohia February 22, 2000

  2. Outline • Introduction • HTTP Server Dynamics • Simple Request Generator • Scalable Clients • Evaluation of Scalable Clients • Conclusion

  3. Introduction • What do we measure? • Requests/sec • How do we measure? • Live workloads • Synthetic workloads

  4. Realistic Traffic • Large number of simultaneous clients • Bursty traffic (8 to 10 times average load) • Delay and loss characteristics of WAN • Request file types • Transfer sizes • Locality of reference in URL requested

  5. HTTP Server Dynamics Server GET <uri> HTTP/1.0 Client HTTP/1.0 200 OK New socket connection made for each request

  6. Connection Establishment Phase • SYN to Server • SYN-ACK to Client • ACK to Server HTTP Connection Establishment Timeline

  7. OS and TCP Limitations • Maximum backlog on a listen socket • This is the upper-bound on the sum of the lengths of SYN-RCVD and accept queues • Most systems today have high somaxconn values (eg. 32767). • Exponential backoff or connection timeout by client if it misses SYN-ACK packet. • BSD retransmits at 6 secs, 30 seconds and gives up at 75 seconds.

  8. OS and TCP Limitations(2) • Accept queue length depends upon how fast the server calls accept(). • FIN also has a 3-way communication. Slow FIN sequence limits the number of sockets active on the server.

  9. Realistic Traffic • Large number of simultaneous clients • Bursty traffic (8 to 10 times average load) • Delay and loss characteristics of WAN • Request file types • Transfer sizes • Locality of reference in URL requested

  10. Simple Request Generator • Set of N web client processes executing on P client machines • Client machines and Server share a LAN • Each client sends request, receives response, waits for think time and repeats cycle

  11. Problems with Simple Method • Clients stay lockstep with the server • When server is running at full capacity, all additional clients are placed in the accept queue and no incremental requests are made • When clients are added past the accept queue length, TCP exponential backoff generates further requests at very low rate (0.04 requests/sec)

  12. Problems with Simple Method(2) Request Rate versus no. of Clients

  13. Problems with Simple Method(3) • Does not model WAN characteristics which cause long SYN-RCVD queues • Resource constraints on client machine might cause client to become bottleneck

  14. Outline • Introduction • HTTP Server Dynamics • Simple Request Generator • Scalable Clients • Evaluation of Scalable Clients • Conclusion

  15. Scalable Clients Testbed Architecture

  16. Scalable Clients (2) • WAN effects are introduced by introducing artificial delay in router’s forwarding mechanism • Request rate is independent of service rate by server • Ability to model burstiness

  17. Scalable Clients (3) • Multiple clients on single client machine • 2 processes per client • Connection Establishment Process • Connection Handling Process

  18. Connection Establishment Process • Opens connections to server using non-blocking mode • Connections are spaced out over T milliseconds • If connection is completed within T ms, send request and hand over socket to Connection Handling process through Unix domain socket • If T ms have elapsed then, close socket and initiate another connection

  19. Connection Handling Process • Wait for data to arrive on connected sockets • Wait for new connections to arrive on the Unix domain socket • Close socket on complete response

  20. Scalable Client Model A Scalable Client

  21. Design Rationale • Shorten TCP connection timeout • non-blocking connects with socket close() if not connected in T ms • Maintain a constant number of unconnected sockets • establishing another connection as soon as a connection fails

  22. S-client performance Request Rate versus no. of Clients

  23. Quantitative Evaluation • NCSA httpd server • somaxconn set to 1024 • No WAN delays • 4 client machines with equally distributed clients

  24. Quantitative Evaluation (2) Request rate versus number of clients

  25. Overload Behavior Web server throughput versus request rate

  26. Overload Behavior (2) • Server saturates at 130 transactions/second • With 2056 requests/second, transaction rate drops to 75 transactions/second • Drop in throughput due to CPU resources spent on protocol processing for incoming requests

  27. Bursty Conditions • Configured S-client to generate bursty traffic • Two parameters are configured • ratio of maximum request rate and average request rate (burst ratio) • fraction of time for which request rate exceeds average rate (burst duration)

  28. Bursty Conditions (2) Server throughput under bursty conditions versus request rate

  29. Conclusion • S-clients are offers substantial improvement over simple request generator to model overload and bursty conditions • Combined with related work on traffic model, a more accurate benchmark can be developed

  30. Q & A ?

More Related