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 Dave West on Jul 16, 2010
Changhao Jiang, Research Scientist at Facebook, describes a technique, called BigPipe, that contributed to making the Facebook site, "twice as fast." BigPipe is one of several innovations, a "secret weapon," used to achieve reported performance gains: "[BigPipe] reduces user perceived latency by half in most browsers." The exception was Firefox 3.6, latency was reduced by approximately 50 ms - about a 22% reduction.
The motivation for BigPipe, and associated innovations:
Modern websites have become dramatically more dynamic and interactive than 10 years ago, and the traditional page serving model has not kept up with the speed requirements of today's Internet.
Taking inspiration from hardware (pipeline and scalar microprocessors), the Facebook team used PHP and Javascript (no changes in existing Web servers and browsers are required) to a achieve a "fundamental redesign of the existing web serving process. The redesign involves: breaking down the page serving process into eight distinct steps (each step is called a "pagelet"), some of which can be performed in parallel. Responding to the initial page request by returning
an unclosed HTML document that includes an HTML head tag and the first part of the body tag. The head tag includes BigPipe’s JavaScript library to interpret pagelet responses to be received later. In the body tag, there is a template that specifies the logical structure of page and the placeholders for pagelets.
And then creating JSON-encoded objects (the pagelets) that include "all the CSS, JavaScript resources needed for the pagelet, and its HTML content, as well as some meta data."
The increasing load time latency for sophisticated Web pages is not a new issue, nor is the use of some form of pipelining to effect performance gains. Aaron Hopkins discusses Optimizing Page Load Time on Die.net, including numerous factors, other than the traditional page request life cycle, that can affect the latency of page loading. One interesting point in Aaron's post:
IE, Firefox, and Safari ship with HTTP pipelining disabled by default; Opera is the only browser I know of that enables it. No pipelining means each request has to be answered and its connection freed up before the next request can be sent. This incurs average extra latency of the round-trip (ping) time to the user divided by the number of connections allowed. Or if your server has HTTP keepalives disabled, doing another TCP three-way handshake adds another round trip, doubling this latency.
Jiang did not indicate that BigPipe took advantage of a browsers innate pipelining functionality, and implied that it did not when saying that no changes in existing servers or browsers was required. It would be interesting to know whether or not the BigPipe innovations will continue to be useful when the browser does change - i.e. with the widespread implementation of HTML 5.
Kensaku Komatsu created a demo (reported by The Zinger) that
... compares data flow in HTML5 Web Sockets on the one side versus XML HTTP Request on the other. When I ran it, the results were astounding: 565 milliseconds against 31444 millieseconds–wow! The Web Sockets experience is 55 times faster, in part, because there is so much less unnecessary header traffic going over the wire.
The demo uses HTTP Pipelining, something that is generally considered to be "dangerous,"
but it is not HTTP pipelining. The network traffic is made up of WebSocket frames and not HTTP requests and responses. It is explicitly controlled by the application author and is not subject to the problems of HTTP/1.1 pipelining. Because WebSockets can send and receive at any time, are directly controlled by the programmer, and are not subject to proxy interference, the pipelining ability is safe and should not be disabled.
Komatsu's demo brings together the relationships between Facebook's innovations, HTTP pipelining questions, and the future capability of HTML 5, especially WebSockets and how they will eventually interact to increase Web site performance and minimize user experienced latency.
Mobile and the New Two-Tiered Web Architecture
SOA All-In-One Guide: KPIs & Best Practices, ESB Report
Why NoSQL? A primer on Managing the Transition from RDBMS to NoSQL
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.
No comments
Watch Thread Reply