1 / 32

User-Perceived Latency

User-Perceived Latency. Long perceived latency is the most serious WWW performance problem. The delay from the time a request is issued until response is received. HTTP Request-response. Server. Client. DNS lookup (address to name) TCP connection setup

ahmed-benjamin
Download Presentation

User-Perceived Latency

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. User-Perceived Latency • Long perceived latency is the most serious WWW performance problem The delay from the time a request is issued until response is received.

  2. HTTP Request-response Server Client • DNS lookup (address to name) • TCP connection setup • Server processing time +/ reverse DNS (access control) • Transmission time • Request-response RTT DNS TCP SYN TCP ACK ACK, HTTP GET DNS HTTP response

  3. HTTP/1.1 Server Client HTTP/1.0 : TCP connection for each HTTP request. HTTP/1.1: Persistence and Pipelining HTTP GET • Persistent HTTP: TCP connection is re-used for additional HTTP requests • Pipelining: HTTP requests - responses are interleaved to save RTTs DNS HTTP response HTTP GET HTTP response HTTP GET HTTP response

  4. Proactive DNS Caching:Addressing a Performance Bottleneck Edith Cohen AT&T Labs-Research http://www.research.att.com/~edith Haim Kaplan Tel-Aviv University http://www.math.tau.ac.il/~haimk

  5. Talk Overview • Overview and Motivation • DNS architecture • effect of DNS lookup latency • Proactive DNS caching • Renewal Policies • Simultaneous Validation • Conclusion

  6. Domain Name System hostname IP-address • Essential for Internet name-based communication • Many-to-many mapping (virtual hosting, mirrors, aliases) • Distributed database maintained by a hierarchy of name-servers www.research.att.com 135.207.23.30

  7. resolving www.research.att.com ? ? Local Name-Server ? DNS Hierarchy

  8. Resolution may involve multiple remote name-servers DNS Lookup Client • Root DNS server • returns NS for att.com • dnsprime.att.com • returns NS for research.att.com • ns0.research.att.com • returns IP-address for www.research.att.com root dnsprime.att.com ns0.research.att.com

  9. Resolving Hostnames • Browser: if no answer in browser cache, query is sent to the local DNS server. • Name-server: use own cache. For missing info, iteratively query remote name-servers, while following referrals/ delegations.

  10. DNS Caching Mechanism • Data is stored in Resource Records (RR) (NS, A, CNAME, SOA) • Each record has a TTL value (Time To Live) • TTL values are assigned by respective domain administrators. • Record may be cached and used only for TTL duration.

  11. Latency Effect of DNS Lookups All requests > 60 sec after previous, ATT log

  12. Latency Effect of DNS Lookups (2) AltaVista referrals requests, ATT proxy log

  13. Performance effect... • NLANR cache service times on AKAMAI servers: {a4,a111}.g.akamaitech.net

  14. 3 to 6 seconds 4% > 3 seconds Service Times DistributionURLs served by a4.g.akamaitech.net 0 to 3 seconds 7351 requests in 6 days, 90%<200ms, 95% < 500ms

  15. Issues with DNS Latency • RTTs to (several) remote name servers • Not addressed by fatter pipes, faster high-capacity content servers. • Highly sensitive to packet loss • Inconsistent - fraction of lookups suffer long/pathological delays • As Internet service improves, will increasingly become more noticeable.

  16. no lookup delay (data is available locally) scalability problems: growing database size coherence single point of failure/load Scalable & robust distributed control distributed presence lookup delays from remote queries Before DNS DNS onehosts.txt file: centrally maintained ftp’d where needed Hierarchy of distributed name-servers.

  17. Passive DNS caching • Query remote NS only to answer a current client request • Cache (use) results till TTL expires Used by BIND name-server software

  18. Proactive DNS caching Guidelines: • Renewal Policies: auto-refresh entries just before TTL expires • Simultaneous Validation: Concurrently validate & use “expired” address Respect TTL values (be transparent to client) Minimize overhead to DNS servers Our Proposals:

  19. Methodology and Logs • Proxy logs • Simulate associated DNS cache • Separately issued DNS queries to obtain: TTL values, rate-of-change of IP-address.

  20. Performance of Passive caching

  21. Renewal Policies - Issue a renewal query upon expiration. - Policy determines when to renew. - Tradeoff of overhead/reduced-latency. • R-LRU renew r times passed the most-recent cache hit • R-LFU grant r additional renewals per hit ( TTL interval) • R-FIFO grant r renewals at entry time to the cache • R-OPT optimal omniscient offline renewal policy

  22. Performance of Renewal Policies ATT proxy log

  23. Performance of Renewal Policies UC (NLANR) log

  24. Renewal Policies: Conclusions from Experiments • R-LRU and R-LFU performed equally well across logs • R-FIFO did not perform as well • Reduction in misses corresponds to reduction in long DNS query times • More effective for more clients

  25. Renewal Policies: Implementation and Extensions • Most natural Implementation is within the name-server • Overhead control: • Pre-expiration renewals (usually 1 RTT) • off-peak renewals • Policies can be adapted to account for varying DNS resolution times

  26. Challenge: How do we benefit from valid expired addresses while still respecting TTL values. TTL versus Rate-of-change • TTL values are set conservatively: Rate-of-change of addresses is significantly lower than TTL value. • So, when “expired” records are discarded, we often loose valuable and valid information

  27. Simultaneous Validation • Keep expired address records. • When a client request arrives, concurrently: • Initiate a connection to host, using expired IP-address, and start fetching content • Issue a validating DNS query • If validation is successful, serve the content to the client

  28. Client DNS GAIN Web Server Web Server SV Latency Gain Client • DNS lookup • session with Web server: • Establishing TCP connection(s), sending HTTP request(s), ... DNS

  29. Simultaneous Validationsuccess rate

  30. Simultaneous Validation:Implementation Choices • browser or proxy (with a separate DNS cache) • requires maintenance of a separate name-to-address cache • single-entity implementation • name-server (using its internal cache) • requires protocol support for 2-phase resolutions • requires separate proxy or browser support • SV is more effective for a larger user base.

  31. Summary • DNS lookup delays can be addressed by increasing local availability of RRs • Renewal Policies • incur overhead of additional queries • simple limited deployment is effective • inter-request-time < c * TTL • Simultaneous Validation • minimal overhead • more involved implementation • inter-request-time < IP-address-lifetime

  32. Future Work • Single, replicated, hostname database + SV • Co-operative DNS caching • Distributed “local” name server • SV and Renewal at the RR level • Collect better data: name-server logs combined with logged HTTP requests • Refreshment policies for Web content

More Related