The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Anil Bhatt on Jul 18, 2007
The advent of AJAX has made it possible to develop browser based web applications with high user interactivity and low user-perceived latency. Real-time dynamic web data such as news headlines, stock tickers, and auction updates need to be propagated to the users as soon as possible. However, AJAX still suffers from the limitations of the web’s request/response architecture which prevents servers from pushing real-time dynamic web data.
Engin Bozdag, Ali Mesbah and Arie van Deursen of the Delft University of Technology have discussed the following approcahes to achieve web-based real time event notification:
1. HTTP Pull: In this traditional approach , the client checks with the server for latest data at regular user definable intervals . The pulling frequecncy needs to be high to ensure high data accuracy, but high pulling frequency may induce redundant checks leading to high network traffic. Low pulling frequency, on the other hand, may lead to missed updates. Ideally, the pulling interval should be equal to the rate at which the server state changes.
2. HTTP Streaming: This method consists of streaming server data in the response of a long-lived HTTP connection (Page Streaming) or an XMLHttpRequest connection (Service Streaming).
3. Reverse AJAX: Service Streaming, as applied to AJAX, is known as Reverse AJAX or COMET . It enables the server to send a message to the client when an event occurs, without the client having to explicitly request. The goal is to achieve a real-time update of the state changes. COMET uses the persistent connection feature in HTTP/1.1. With HTTP/1.1, unless specified otherwise, the TCP connection between the server and the browser is kept alive, until an explicit ‘close connection’ message is sent by one of the parties, or a timeout/network error occurs.
4. Long Polling: Also known as Asynchronous Polling, this method is a hybrid of pure server push and client pull. It is based on BAYEUX protocol. This protocol follows the topic based publish - subscribe scheme. After a subscription to a channel, the connection between the client and the server is kept open, for a defined amount of time. If no event occurs on the server side, a timeout occurs, and the server asks the client to reconnect asynchronously. If an event occurs, the server sends the data to the client, and the client reconnects.
In their experimental study, the authors compared Data Coherence, Server Performance, Network Performance and Data Misses of an AJAX application using a COMET push implementation (Dojo’s Cometd library), as opposed to a pure pull approcah.
The authors concluded that:
"...If we want high data coherence and high network performance, we should choose the push approach. However, push brings some scalability issues; the server application CPU usage is 7 times higher as in pull. According to our results, the server starts to saturate at 350-500 users. For larger number of users, load balancing and server clustering techniques are unavoidable.
With the pull approach, achieving total data coherence with high network performance is very difficult. If the pull interval is higher than the publish interval, some data miss will occur. If it is lower, network performance will suffer. Pull performs well only if the pull interval equals to publish interval. However, in order to achieve that, we need to know the exact publish interval beforehand. However, the publish interval is rarely static and predictable. This makes pull useful only in situations where the data is published frequently according to some pattern..."
Some other implementations of the Comet Ajax server-push model are:
Mobile and the New Two-Tiered Web Architecture
18 agile and lean practices for effective software development governance
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
The study says: "If the pull interval is higher than the publish interval, some data miss will occur. If it is lower, network performance will suffer. Pull performs well only if the pull interval equals to publish interval."
Huh? I'd like to hear how one justifies that a pull model can't perform "well" (for any reasonable definition of that term) just because it makes a few more network connections than would strictly be needed to serve all the data. Reading the paper, it looks like the authors just wanted a convenient way to dismiss something they aren't interested in. If that's the case, it would be more straight-forward to say "we aren't much interested in that" than to make up statements that are, at best, applicable only to a tiny subset of cases.
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.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
1 comment
Watch Thread Reply