New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Abel Avram on Dec 04, 2009
Google is offering two DNS servers for public use, namely 8.8.8.8 and 8.8.4.4, in an attempt to further speed up browsing.
A DNS server is used to translate a web name, a literal identifier, into a numerical identifier used by the underlying network protocols. An average user needs hundreds of such translations to be done in a typical browsing day, according to Google. Many web pages are complex these days incorporating content from multiple domains, each domain being in need of a domain name resolution. The name resolution process - connecting to a DNS server, finding the numerical ID and returning the response – increases the browsing latency resulting sometimes in completely loading a page in seconds, even 11 seconds as this example shows.
Google finds this DNS latency unacceptable and has opened up two globally distributed DNS servers to public use hoping to improve browsing speed. They are trying to address three main issues:
- Speed: Resolver-side cache misses are one of the primary contributors to sluggish DNS responses. Clever caching techniques can help increase the speed of these responses. Google Public DNS implements pre-fetching: before the TTL on a record expires, we refresh the record continuously, asynchronously and independently of user requests for a large number of popular domains. This allows Google Public DNS to serve many DNS requests in the round trip time it takes a packet to travel to our servers and back.
- Security: DNS is vulnerable to spoofing attacks that can poison the cache of a name server and can route all its users to a malicious website. Until new protocols like DNSSEC get widely adopted, resolvers need to take additional measures to keep their caches secure. Google Public DNS makes it more difficult for attackers to spoof valid responses by randomizing the case of query names and including additional data in its DNS messages.
- Validity: Google Public DNS complies with the DNS standards and gives the user the exact response his or her computer expects without performing any blocking, filtering, or redirection that may hamper a user's browsing experience.
Google says their DNS servers are better because they are
- 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.
- Pre-fetching 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 pre-fetching 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 pre-fetching, 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.
On a similar but different note, Google has unveiled how Chrome deals with name resolution to increase browsing speed even more. Jim Roskind, a Chrome Software Engineer, gave some tips:
For the future: some 1-2% of the TCP/IP packets are lost in transmission and the TCP/IP stack has a 3 seconds time-out on Windows after which it starts resending it. When the first packet is lost, the user waits expecting for the page to be load, but the target website hasn’t actually been contacted. 3 seconds is way too much for Google, so they will implement a mechanism in Chrome to either resend a TCP/IP packet which was not answered or to open up a new connection when the server does not answer in a reasonable time.
Why NoSQL? A primer on Managing the Transition from RDBMS to NoSQL
Agile Development: A Manager's Roadmap for Success
Improve Java Garbage Collection, Runtime Execution, and JVM visibility with Zing
With this solution, the easiest way to improving users' experience with Google apps would be to handle requests for all Google's domains before processing any other domains. If worldwide users decide to switch to their DNS service en masse, they'll have a mighty tool to gain advantage over competitors. But, at the end of the day, that's ok - they don't force you to use it.
Looks like Google wants to be able to detect what is directly typed in the navigation bar or the links that are clicked past the initial search results. This could surely improve their ranking algorithms but also poses a HUGE privacy problem.
There's a good response from the OpenDNS folks:
blog.opendns.com/2009/12/03/opendns-google-dns/
To think that Google’s DNS service is for the benefit of the Internet would be naive. They know there is value in controlling more of your Internet experience...
[but also]
...it means that Google is bringing awareness to a wide audience that there is a choice when it comes to DNS and that users don’t have to settle for what their ISP provides. And we believe that having choice is a good thing...
As opposed to the isp peeking in your info. Look for microsoft to do the same things.
Very good point, Bobby. Many companies already do have access to this info.
Look for microsoft to do the same things.
And Microsoft has the power to silently "reset" Windows users' DNS settings to point to Microsoft-hosted DNS servers in the next Windows Update.
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
6 comments
Watch Thread Reply