mootools：我想在Facebook上实现类似于Big pipe的架构

Question

I am developing an application in mootools. I have used Reqeust class to implement pipelining it. I want to develop a superior method to handle client server requests. I referred the following article to understand how big pipe works in facebook.

http://www.facebook.com/notes/facebook-engineering/bigpipe-pipelining-web-pages-for-high-performance/389414033919

In facebook, a javascript function is called on arrival of any server response to update data user screen. (see the screenshot)

http://img815.imageshack.us/img815/5154/facebookna.jpg

if i get a basic model of such architecture, i can start building application using that code.

can some one please provide me such a basic model?

Till now i have designed an architecture in which response_data is stored in a global variable and then a function called to update data to user screen.(Used synchronous Request here) which is very slow.

so which method is superior 'synchronous or Asynchronous'?

Answer 1

Firstly, thanks for the read, it was a very interesting blog post.

You may want to look into this libary which was inspired by Facebook's BigPipe. Note: I'm not endorsing it as I've never used it, but building it yourself is not trivial.

With regards to whether synchronous and asynchronous is better, that depends. Synchronous is simpler - the dependencies are obvious, and there's no overhead. Asynchronous is only an advantage if your resources are not fully utilised, and your processing can be easily broken down into independant blocks. I can't tell what you're trying to do, so you need to make the decision yourself where the performance bottleneck actually is, and whether architecting your application such that multiple sections can be downloaded, processed and rendered in parallel will actually provide an advantage.

As an example, if you're downloading a single, massive block of data to be rendered as a table in the browser, then breaking that data into multiple parallel downloads will improve performance - at the cost of creating some queuing system to deal with out-of-order responses. On the other hand, though technically slower, batching the download into synchronous blocks so that one block is downloaded and rendered before the next one is requested, will still do wonders to perceived performance , and is a much simpler alternative.