User-Perceived Latency zLong perceived latency is the most serious WWW performance problem The delay...
-
Upload
beverly-golden -
Category
Documents
-
view
214 -
download
0
Transcript of User-Perceived Latency zLong perceived latency is the most serious WWW performance problem The delay...
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
DNS lookup (address to name)
TCP connection setup
Server processing time +/ reverse DNS (access control)
Transmission timeRequest-response
RTT
TCP SYNTCP SYN
TCP ACKTCP ACK
ACK, HTTP GETACK, HTTP GET
HTTP responseHTTP response
HTTP/1.1
Persistent HTTP: TCP connection is re-used for additional HTTP requests
Pipelining: HTTP requests - responses are interleaved to save RTTs
HTTP GETHTTP GET
HTTP responseHTTP response
HTTP/1.0HTTP/1.0 : TCP connection for each : TCP connection for each HTTP request.HTTP request.HTTP/1.1HTTP/1.1: Persistence and Pipelining: Persistence and Pipelining
HTTP GETHTTP GET
HTTP GETHTTP GET
HTTP responseHTTP response
HTTP responseHTTP response
Proactive DNS Caching:Addressing a Performance Bottleneck
Edith CohenAT&T Labs-Researchhttp://www.research.att.com/~edith
Haim KaplanTel-Aviv Universityhttp://www.math.tau.ac.il/~haimk
Talk Overview
Overview and Motivation DNS architecture effect of DNS lookup latency
Proactive DNS caching Renewal Policies Simultaneous Validation
Conclusion
Domain Name System
Essential for Internet name-based communicationEssential for Internet name-based communication Many-to-many mapping (virtual hosting, mirrors, Many-to-many mapping (virtual hosting, mirrors,
aliases)aliases) Distributed database maintained by a hierarchy Distributed database maintained by a hierarchy
of name-serversof name-servers
hostname IP-addresswww.research.att.com 135.207.23.30
ns-1.amazon.comamazon.com
ns.research.att.comresearch.att.com
dnsprime.att.comatt.com
root.
DNS Hierarchy
LocalName-Server
resolving www.research.att.com
DNS Lookup
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
Resolution may involve multiple remote name-serversResolution may involve multiple remote name-servers
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.
DNS Caching Mechanism
Data is stored in Resource Records (RR) (NS, A, CNAME, Data is stored in Resource Records (RR) (NS, A, CNAME, SOA)SOA)
Each record has a Each record has a TTL value TTL value (Time To Live)(Time To Live) TTL values are assigned by respective domain administrators.TTL values are assigned by respective domain administrators. Record may be cached and used only for TTL duration.Record may be cached and used only for TTL duration.
Latency Effect of DNS Lookups All requests > 60 sec after previous, ATT log
Latency Effect of DNS Lookups (2) AltaVista referrals requests, ATT proxy log
Performance effect...
NLANR cache service times on AKAMAI servers: {a4,a111}.g.akamaitech.netdomain TTL
akamaitech.net 25hr
g 1000 sec
a4, a111 20 sec
Service Times DistributionURLs served by a4.g.akamaitech.net
0 to 3 seconds
7351 requests in 6 days, 90%<200ms, 95% < 500ms
3 to 6 seconds
4% > 3 seconds
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 delaysAs Internet service improves, will increasingly become more noticeable.
Before DNS DNS
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
one hosts.txt file:centrally maintainedftp’d where needed
Hierarchy of distributed name-servers.
Passive DNS caching
Query remote NS only to answer a Query remote NS only to answer a current client requestcurrent client request
Cache (use) results till TTL expiresCache (use) results till TTL expires
Used by BIND name-server software
Proactive DNS caching
Renewal Policies: auto-refresh entries just before TTL expires
Simultaneous Validation:Simultaneous Validation: Concurrently validate Concurrently validate & use “expired” address& use “expired” address
Our Proposals:Our Proposals:
Guidelines:Respect TTL values (be transparent to client)Respect TTL values (be transparent to client)Minimize overhead to DNS serversMinimize overhead to DNS servers
Methodology and Logs Proxy logs Simulate associated DNS cache Separately issued DNS queries to obtain: Separately issued DNS queries to obtain:
TTL values, rate-of-change of IP-address.TTL values, rate-of-change of IP-address.
Requests (1000)
Hosts(1000)
period
AT&T489 10.5 11/8/96-
11/19/96
UC(NLANR)
10837 91 5/18/99-6/5/99
Performance of Passive caching
DNS misses(% HTTP req.)
First-seen misses(% DNS misses)
AT&T 32K 6.5% 33%
UC(NLANR)
941K 8.7% 9.7%
Renewal Policies
R-LRUR-LRU renew r times passed the most-recent cache hit renew r times passed the most-recent cache hit R-LFUR-LFU grant r additional renewals per hit ( TTL interval) grant r additional renewals per hit ( TTL interval) R-FIFOR-FIFO grant r renewals at entry time to the cache grant r renewals at entry time to the cache R-OPTR-OPT optimal omniscient offline renewal policy optimal omniscient offline renewal policy
- Issue a renewal query upon expiration.- Issue a renewal query upon expiration.- Policy determines when to renew.- Policy determines when to renew.- Tradeoff of overhead/reduced-latency.- Tradeoff of overhead/reduced-latency.
Performance of Renewal Policies ATT proxy log
Performance of Renewal Policies UC (NLANR) log
Renewal Policies: Conclusions from Experiments
R-LRU and R-LFU performed equally well across logs R-LRU and R-LFU performed equally well across logs R-FIFO did not perform as wellR-FIFO did not perform as well Reduction in misses corresponds to reduction in Reduction in misses corresponds to reduction in
long DNS query timeslong DNS query times More effective for more clients More effective for more clients
Renewal Policies: Implementation and Extensions
Most natural Implementation is within the name-serverMost natural Implementation is within the name-server Overhead control:Overhead control:
Pre-expiration renewals (usually 1 RTT)Pre-expiration renewals (usually 1 RTT) off-peak renewalsoff-peak renewals
Policies can be adapted to account for varying DNS Policies can be adapted to account for varying DNS resolution timesresolution times
TTL versus Rate-of-change
TTL values are set conservatively: Rate-of-TTL values are set conservatively: Rate-of-change of addresses is significantly lower than change of addresses is significantly lower than TTL value.TTL value.
So, when “expired” records are discarded, we So, when “expired” records are discarded, we often loose valuable and valid informationoften loose valuable and valid information
Challenge:How do we benefit from valid expired addresses while still respecting TTL values.
Simultaneous Validation
Keep expired address records.Keep expired address records. When a client request arrives, When a client request arrives, concurrentlyconcurrently::
Initiate a connection to host, using expired IP-address, Initiate a connection to host, using expired IP-address, and start fetching contentand start fetching content
Issue a validating DNS queryIssue a validating DNS query If validation is successful, serve the content to the clientIf validation is successful, serve the content to the client
SV Latency Gain
DNS lookupsession with Web server:
Establishing TCP connection(s), sending HTTP request(s), ...
Simultaneous Validationsuccess rate
SV success rate (out of DNS misses on
epreviously-seen hostnames)AT&T 97.9%
UC(NLANR)
99.1%
Simultaneous Validation:Implementation Choices
browser or proxy (with a separate DNS browser or proxy (with a separate DNS cache)cache) requires maintenance of a separate name-to-requires maintenance of a separate name-to-
address cacheaddress cache single-entity implementationsingle-entity implementation
name-server (using its internal cache)name-server (using its internal cache) requires protocol support for 2-phase requires protocol support for 2-phase
resolutionsresolutions requires separate proxy or browser support requires separate proxy or browser support
SV is more effective for a larger user base.SV is more effective for a larger user base.
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
Future Work
Single, replicated, hostname database + SV
Co-operative DNS caching Distributed “local” name serverSV and Renewal at the RR levelCollect better data: name-server logs
combined with logged HTTP requestsRefreshment policies for Web content