mootools：我想实现类似于 Facebook 中的 Big Pipe 的架构
我正在 mootools 中开发一个应用程序。我已经使用 Reqeust 类来实现管道化。 我想开发一种更好的方法来处理客户端服务器请求。我参考了下面的文章来了解big pipeline在facebook中是如何工作的。
在 facebook 中，任何服务器响应到达时都会调用 JavaScript 函数来更新数据用户屏幕。 （参见屏幕截图）
http://img815.imageshack.us/img815/5154/facebookna。 jpg
如果我得到这种架构的基本模型，我可以开始使用它构建应用程序 代码。
有人可以给我提供这样一个基本模型吗？
到目前为止，我已经设计了一个体系结构，其中response_data存储在全局变量中，然后调用一个函数来将数据更新到用户屏幕。（此处使用同步请求）这非常慢。
那么“同步”和“异步”哪种方法更好呢？
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.
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'?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先，感谢您的阅读，这是一篇非常有趣的博客文章。
您可能想研究一下 这个库，它的灵感来自 Facebook 的 BigPipe。注意：我并不认可它，因为我从未使用过它，但自己构建它并不简单。
至于同步和异步哪个更好，那要看情况了。同步更简单 - 依赖性很明显，并且没有开销。仅当您的资源未得到充分利用时，异步才是一个优势，并且您的处理可以轻松地分解为独立的块。我不知道你想做什么，所以你需要自己决定性能瓶颈实际上在哪里，以及构建你的应用程序以便可以并行下载、处理和渲染多个部分是否实际上会提供一个优势。
举个例子，如果您正在下载单个大量数据块并在浏览器中呈现为表格，那么将该数据分解为多个并行下载将提高性能 - 代价是创建一些排队系统来处理按顺序响应。另一方面，虽然技术上速度较慢，但将下载批处理为同步块，以便在请求下一个块之前下载并渲染一个块，仍会对感知性能产生奇迹，并且更简单选择。
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.