Performance Benefits of Google Public DNS

As web pages become more complex, referencing resources from numerous domains, DNS lookups can become a significant bottleneck in the browsing experience. Whenever a client needs to query a DNS resolver over the network, the latency introduced can be significant, depending on the proximity and number of nameservers the resolver has to query (more than 2 is rare, but it can happen). As an example, the following screen shot shows the timings reported by the Page Speed web performance measurement tool. Each bar represents a resource referenced from the page; the black segments indicate DNS lookups. In this page, 13 lookups are made in the first 11 seconds in which the page is loaded. Although several of the lookups are done in parallel, the screen shot shows that 5 serial lookup times are required, accounting for several seconds of the total 11 seconds page load time.

There are two components to DNS latency:

• Latency between the client (user) and DNS resolving server. In most cases this is largely due to the usual round-trip time (RTT) constraints in networked systems: geographical distance between client and server machines; network congestion; packet loss and long retransmit delays (one second on average); overloaded servers, denial-of-service attacks and so on.
• Latency between resolving servers and other nameservers. This source of latency is caused primarily by the following factors:
  • Cache misses. If a response cannot be served from a resolver’s cache, but requires recursively querying other nameservers, the added network latency is considerable, especially if the authoritative servers are geographically remote.
  • Underprovisioning. If DNS resolvers are overloaded, they must queue DNS resolution requests and responses, and may begin dropping and retransmitting packets.
  • Malicious traffic. Even if a DNS service is overprovisioned, DoS traffic can place undue load on the servers. Similarly, Kaminsky-style attacks can involve flooding resolvers with queries that are guaranteed to bypass the cache and require outgoing requests for resolution.

We believe that the cache miss factor is the most dominant cause of DNS latency, and discuss it further below.

Cache misses

Even if a resolver has abundant local resources, the fundamental delays associated with talking to remote nameservers are hard to avoid. In other words, assuming the resolver is provisioned well enough so that cache hits take zero time on the server-side, cache misses remain very expensive in terms of latency. To handle a miss, a resolver has to talk to at least one, but often two or more external nameservers. Operating the Googlebot web crawler, we have observed an average resolution time of 130 ms for nameservers that respond. However, a full 4-6% of requests simply time out, due to UDP packet loss and servers being unreachable. If we take into account failures such as packet loss, dead nameservers, DNS configuration errors, etc., the actual average end-to-end resolution time is 300-400 ms. However, there is high variance and a long tail.

Though the cache miss rate may vary among DNS servers, cache misses are fundamentally difficult to avoid, for the following reasons:

• Internet size and growth. Quite simply, as the Internet grows, both through the addition of new users and of new sites, most content is of marginal interest. While a few sites (and consequently DNS names) are very popular, most are of interest to only a few users and are accessed rarely; so the majority of requests result in cache misses.
• Low time-to-live (TTL) values. The trend towards lower DNS TTL values means that resolutions need more frequent lookups.
• Cache isolation. DNS servers are typically deployed behind load balancers which assign queries to different machines at random. This results in each individual server maintaining a separate cache rather than being able to reuse cached resolutions from a shared pool.

Mitigations

In Google Public DNS, we have implemented several approaches to speeding up DNS lookup times. Some of these approaches are fairly standard; others are experimental:

• Provisioning servers adequately to handle the load from client traffic, including malicious traffic.
• Preventing DoS and amplification attacks. Although this is mostly a security issue, and affects closed resolvers less than open ones, preventing DoS attacks also has a benefit for performance by eliminating the extra traffic burden placed on DNS servers. For information on the approaches we are using to minimize the chance of attacks, see the page on security benefits.
• Load-balancing for shared caching, to improve the aggregated cache hit rate across the serving cluster.
• Prefetching name resolutions, to overcome the limits of conventional, passive caching and aim to serve the majority of requests out of cache. We are experimenting with a DNS prefetching technique which we think offers a significant opportunity for DNS speed-up. Below, we give an overview of the benefits, limitations, and challenges in implementing prefetching, and how we hope to meet those challenges with additional techniques such as traffic prioritization and cache partitioning.
• Providing global coverage for proximity to all users.

Provisioning serving clusters adequately

Caching DNS resolvers have to perform more expensive operations than authoritative nameservers, since many responses cannot be served from memory; instead, they require communication with other nameservers and thus demand a lot of network input/output. Furthermore, open resolvers are highly vulnerable to cache poisoning attempts, which increase the cache miss rate (such attacks specifically send requests for bogus names that can’t be resolved from cache), and to DoS attacks, which add to the traffic load. If resolvers are not provisioned adequately and cannot keep up with the load, this can have a very negative impact on performance. Packets get dropped and need to be retransmitted, nameserver requests have to be queued, and so on. All of these factors add to delays.

Therefore, it’s important for DNS resolvers to be provisioned for high-volume input/output. This includes handling possible DDoS attacks, for which the only effective solution is to over-provision with many machines. At the same time, however, it’s important not to reduce the cache hit rate when you add machines; this requires implementing an effective load-balancing policy, which we discuss below.

Scaling resolver infrastructure by adding machines can actually backfire and reduce the cache hit rate if load balancing is not done properly. In a typical deployment, multiple machines sit behind a load balancer that equally distributes traffic to each machine, using a simple algorithm such as round robin. The result of this is that each machine maintains its own independent cache, so that the cached content is isolated across machines. If each incoming query is distributed to a random machine, depending on the nature of the traffic, the effective cache miss rate can be increased proportionally. For example, for names with long TTLs that are queried repeatedly, the cache miss rate can be increased by the number of machines in the cluster. (For names with very short TTLs, that are queried very infrequently, or that result in uncacheable responses (0 TTL and errors), the cache miss rate is not really affected by adding machines.)

To boost the hit rate for highly cacheable names, it’s important to load-balance servers so that the cache is not fragmented. There are two ways to accomplish this: one is to use a global cache that is shared by all machines; the other is to partition the cache by name, so that all queries for one name are sent to the same machine. In Google Public DNS, we use both approaches. One pool of machines shares a small global cache containing the most popular names; these machines are load balanced without any affinity or stickiness. If a query cannot be satisfied from this cache, it is sent to another pool of machines that divide up the cache by (less popular) names. All queries for the same name are sent to the same machine, where the name is either cached or it isn’t.

Prefetching name resolutions

As the Internet grows, there is a limit to the cache hit rate a resolver can reach with regular, passive caching: there are relatively few very popular names, and caching the unpopular ones doesn’t help much, since they expire before they are requested again. However, we’d like to be able to serve less popular, less frequently requested names as quickly as we can serve popular names like http://www.gmail.com. Since it’s not acceptable to serve stale or extrapolated results for those names, we also need to ensure that the resolutions are always valid (i.e. have not passed the TTL expiry time).

To accomplish these goals, we are experimenting with aggressively prefetching and refreshing names independently of whether and when users ask for them. There are two major challenges to implementing prefetching properly:

• Respecting other nameservers’ capacity limits. To ensure that we don’t overload other nameservers with prefetch queries, we impose rate limits on our outgoing requests. To ensure that that self-imposed cap on outgoing capacity is not exhausted by rogue traffic, we divide up the QPS-based quota for each of the nameservers into multiple traffic queues and strictly prioritize prefetch traffic over user traffic.
• Managing our own servers’ capacity limits. As our servers don’t have infinite memory and CPU, we need to carefully select the names which we can prefetch. We discuss the challenges and our approaches to selecting names for prefetching below.

  In addition, to protect the cache from being eaten up by bogus entries from attackers, we separate the main cache into primary and secondary partitions and give read/write access to each partition according to traffic type.

To maximize the use of the fixed nameserver-QPS limit we have imposed, we need to weigh the benefit of each name record against its cost (nameserver capacity and local CPU and RAM), which is inversely proportional to its TTL. However, determining the benefit of a given name record is a complex task, as we’d like to achieve all of the following, sometimes competing, goals:

• Minimizing the incidence of cache misses. This implies that we don’t need to independently prefetch popular names such as http://www.google.com and ad.doubleclick.com, since they are likely to be kept fresh by regular user traffic.
• Serving popular names even when our servers are under DoS attacks that are exhausting our outbound capacity. This implies that we should, in fact, prefetch popular names.
• Avoiding bogus names injected by deliberate pollution attacks. This implies that we can’t rely on solely on user traffic as the source of names to select.
• Keeping the set of selected names up to date. We need to be able to adjust the candidate names according to shifts in popularity, cost, etc.

The complexity of the name selection problem makes it impossible to solve online, so we have separated the prefetch system into two components: a pipeline component, which runs as an external, offline, periodic process that selects the names to commit to the prefetch system; and a runtime component, that regularly resolves the selected names according to their TTL windows.

The pipeline component synthesizes the names from a variety of sources, mainly the Google web search index and recent Google Public DNS server logs, and ranks them according to benefit. Benefit is determined by a combination of various factors, including hit rate, the cost of a cache miss, and popularity. The pipeline then factors in the TTL cost; re-ranks all the records; and selects all the names from the top of the list until the cost budget is exhausted. The pipeline continuously updates the list of selected names. The runtime component continuously resolves the selected name records and refreshes them according to their TTL settings.

For closed resolvers, this is not really an issue. For open resolvers, the closer your servers are located to your users, the less latency they will see at the client end. In addition, having sufficient geographical coverage can indirectly improve end-to-end latency, as nameservers typically return results optimized for the DNS resolver’s location. That is, if a content provider hosts mirrored sites around the world, that provider’s nameservers will return the IP address in closest proximity to the DNS resolver.

Google Public DNS is hosted in data centers worldwide, and uses anycast routing to send users to the geographically closest data center.

Note, however, that because nameservers geolocate according to the resolver’s IP address rather than the user’s, Google Public DNS has the same limitations as other open DNS services: that is, the server to which a user is referred might be farther away than one to which a local DNS provider would have referred. This could cause a slower browsing experience for certain sites.

 

Apple iLife ’11 for Mac OS X launched

Apple launched iLife ’11 at the Back to the Mac event yesterday, alongside new MacBook Airs and a sneak-peek at Mac OS X 10.7 Lion. The new Apple iLife ’11 is already on sale and will come preinstalled on all new iMacs and MacBooks, Apple said.

Apple demoed three new applications from iLife ’11 at yesterday’s Mac event — iPhoto, iMovie and GarageBand.

iPhoto ’11 includes a full-screen mode similar to iOS for viewing and editing photos. iPhoto ’11 from iLife ’11 will also have social sharing improvements, new slideshows, a near complete redesign in books, and new letterpress cards.

iMovie ’11 is Apple’s entry-level video editing program for Mac OS X, part of iLife ’11. iMovie ’11 will sport improved audio editing features, according to Steve Jobs it was the most wanted request for iMovie ’11.

GarageBand ’11 will feature new recording and instrument tools in iLife ’11. GarageBand ’11 will also have Flex Time, Groove Matching, and ‘How did I play?’ features. New guitar amps, lessons, effects and new piano lessons will also take centrestage in GarageBand ’11.

Pricing and Availability: iLife ’11 in India
iLife ’11 is available for a price of Rs. 2,800 through the Apple Resellers (http://www.apple.com/in). The iLife ’11 Family Pack includes five licenses and is available for Rs. 4,400 and the Mac Box Set which includes iLife ’11, iWork and Mac OS X v10.6 Snow Leopard is available for Rs. 9,700.

Also Read:

• Apple Mac update: OS X Lion, MacBook Air, iLife, other announcements
• Apple Mac OS X Lion coming in summer 2011
• Apple MacBook Air update: Slimmer 11.6-inch model launched
• VIDEO: New MacBook Air launch
• Apple FaceTime for Mac beta out

 

 

WordPress Founder on the Key to Open Source Success [INTERVIEW]

 

As a 19-year-old college student in 2003, Matt Mullenweg developed what has become the largest self-hosted blogging tool on the web. Two years later, he foundedAutomattic, which runs the content management system for WordPress and a handful of other web tools.

WordPress — still free and open source — is currently used by more than 12% of the top million websites (this one included). In a recent e-mail exchange, Mullenwegdiscussed the open source movement, the shifting personal web publishing world, and the future of WordPress.

• 1. How did WordPress change the Internet?

  Well we’re not done yet, but two things WordPress has been able to exemplify is that Open Source can create great user experiences and that it’s possible to have a successful commercial entity and a wider free software community living and working in harmony.

• 2. What is the biggest shift that has happened in personal publishing since WordPress.org was launched in 2003 and WordPress.com in 2005?

  To me the biggest shift has been in mobile. From the first time I held an iPhone, the space has evolved quickly, and people have shifted from reading content on their desktops to smartphones and iPads, even long-form stuff. Twitter is the ultimate service for the mobile age — its simplification and constraint of the publishing medium to 140 characters is perfectly complementary to a mobile experience. People still need longer stuff, but they see the headline on Twitter or Facebook.

• 3. Automattic continues to expand in terms of customers, VIP services and acquisitions. Any plans to go public or broach the IPO pool?

  We love the freedom afforded by being an independent company and plan to stay that way for the foreseeable future. In that scenario, being publicly held is one of the obvious liquidity options for shareholders, but in an environment where even companies with massive revenues like Zynga and Facebook aren’t public, I think for Automattic it’s many years off and not something that influences our decisions day-to-day.

• 4. How do you balance your commitment to open source with your capitalistic ambitions?

  I don’t balance them — they’re both out in full force. The more money Automattic makes, the more we invest into Free and Open Source software that belongs to everybody and services to make that software sing. The more I make, the more I donate to non-profits spreading Open Source to the world.

• 5. What do you think are the biggest concerns facing the open source movement?

  The biggest challenge for Open Source is that as it enters the consumer market, as projects like WordPress and Firefox have done, you have to create a user experience that is on par or better than the proprietary alternatives. Traditional Open Source development models, like the Apache one, are not set up to do that. In server software options are good — in consumer web interfaces they’re a cognitive burden.

  While I personally believe strongly in the philosophy and ideology of the Free Software movement, you can’t win people over just on philosophy; you have to have a better product too.

• 6. WordPress.com has adopted many of the features that Tumblr, Posterous and other microblogging services have popularized. Is this going to continue in the future? Any plans to integrate some of the WP.com microblogging tools into self-hosted WordPress.org sites?

  Absolutely, and that’s all I can say for now. 🙂

   

HP Unveils webOS 2.0

In addition to announcing the Palm Pre 2 Tuesday, HP announced webOS 2.0, which the company claims is the most significant update to the platform since its launch in 2009.

HP purchased Palm back in April, largely because of the promise of its mobile software platform, webOS. Visually, webOS 2.0 retains the flourish of its predecessor, but operationally it’s a lot more robust.

HP is bringing webOS 2.0 first to SFR in France via the new Palm Pre 2. The Palm Pre 2 will hit Verizon later this year. HP says existing customers can expect the webOS 2.0 update to arrive “in the coming months.”

So what’s new in webOS 2.0? The Palm Pre 2 page has a pretty good explanation, but here are some highlights:

The new Synergy feature is one of the cooler new software features for keeping contacts and calendars updated. You can automatically sync your Facebook (), LinkedIn (), Google (), Yahoo () and Microsoft Exchange info. If a contact’s information changes in one place, you’ll see it updated on your phone. This is pretty similar to what companies like Xobni () and Meshin are doing, but it’s built-in at the OS level.

We don’t have a webOS 2.0 device in our hands, but our friends at PreCentral have a pretty exhaustive review of the new update and they seem pretty impressed.

We’ve always been fans of webOS as an operating system. The problem has been inspiring developer interest in the platform and making sure the hardware is both powerful enough to run the OS and well-made enough not to break or be unreliable.

WebOS 2.0 seems to have a lot going for it, but as I noted on the “Briefly Awesome” podcast last week, it seems prime for a tablet device. That’s where we want to see webOS, and where we think it has its best shot of being an inviting platform for application developers and users.

What do you think of the looks and featureset of webOS 2.0? Is this enough to help HP gain some momentum in the mobile device space?

7 inch RIM BlackBerry PlayBook tablet with dual-core CPU officially announced (video)

 

Research in Motion’s first tablet isn’t called BlackPad, and neither SurfBook: it’s the BlackBerry PlayBook – officially announced today.

The PlayBook has a 7 inch multitouch capacitive display with 1024 x 600 pixels (why, hello, Samsung Galaxy Tab) and runs the brand new BlackBerry Tablet OS, also announced today.

The tablet is, unsurprisingly, Adobe Flash 10.1 enabled, it has built in support for HTML 5, and RIM says it’s “ideal for games, media, apps and everything the real Internet offers.”

Of note is the 1 GHz dual-core processor of the tablet, and the inclusion of 1GB of RAM.

The PlayBook can be paired with a BlackBerry smartphone via secure Bluetooth connection for full access to Push technology, Email, calendar, BBM, documents, tasks and so on.

As for the BlackBerry Tablet OS, this is based on the QNX Neutrino microkernel architecture and thus it’s able to support “a professional grade tablet experience and to redefine the possibilities for mobile computing.”

Others specs and features of the PlayBook:

• “True multi-tasking”
• “3G access via existing BlackBerry smartphone service plan”
• Wi-Fi 802.11 a/b/g/n
• 5MP camera on the back, with HD video
• 3MP front-facing camera for video-calling, also with HD capabilities
• MicroUSB connector
• Micro HDMI
• DLNA media streaming
• Rich stereo sound
• “Out-of-the-box compatibility with BlackBerry Enterprise Server”
• 130 x 194 x 10 mm (7.6 x 5.1 x 0.4 inches)
• 400 grams (0.9 lbs)

Official video promo:

Unfortunately, for those who find the BlackBerry PlayBook interesting (and it sure is), the tablet will not be available this year. RIM expects to launch it in the US “in early 2011, with other markets to get it starting the second quarter of the year. Pricing has not been unveiled.

You can find out more about the PlayBook here at RIM.

Via Press release