基于 Struts2 标签的 BigPipe 技术实现（3）

look_w

多线程方式不管是单线程还是普通实现方式，它们加载页面所需的总时间没有减少，对于非常大的页面，缩短加载时间才是最重要的，那么就可以使用本文介绍的多线程 BigPipe 技术了。多线程实现方式与 Facebook 的实现方式基本一致，在本文的例子中，将每个单元格视为一个 PageLet，每个 PageLet 的内容交给单独的线程进行生成和处理，也就是说，六个 PageLet 的内容并行处理，无需按照文档流顺序进行处理。我们打开 http://localhost:{your port}/BigPipeImpl/multi.action, 我们再次查看页面的内容加载时间，结果如图 6 所示。
图 6. 多线程实现方式的加载时间（）看到了吗？总共的加载时间变为了 6 秒，是不是很神奇，针对本文的例子，提高了 3 倍多，同时也只在一个请求内完成（另外两个请求是请求 JavaScript 文件和图片文件的）。而实际上，这个 6 秒，是加载时间最长的 PageLet 所需要的时间，因为各个 PageLet 的加载是并行的，页面加载时间以最晚的那个 PageLet 为准。本文例子的加载原理如图 7 所示。
图 7. 多线程 BigPipe 原理可以看到，六个单元格并行加载，整个页面的加载时间由最长的单元格 6 决定。按照图 7 的分析，单元格是按照 1-6 的顺序显示，同时每个单元格之间相差接近 1 秒。经验证，单元格显示的顺序的确是 1-6，结果如图 8 所示。
图 8. 多线程显示结果（）在每个单元格（也就是 PageLet）显示出内容的瞬间，Firebug 的网络监控部分，就会显示出当时网页所消耗的时间，结果如图 9 所示。
图 9. 每个 PageLet 显示的时间可以看到，每个 PageLet 的显示间隔正好一秒，与 的分析完全一致。这也证实了多线程加载 PageLet 的实现是正确的。
多种实现方式的对比从以上的示例展示和结果分析，不难看出普通实现方式、单线程 BigPipe、多线程 BigPipe 以及 Ajax 之间的差异，我们不防用一个表格来展示，对比结果如表 1 所示，注意：我们使用本文的示例程序作为评价背景，因为对于不同网页有可能出现不同的结果。
表 1. 四种实现方式对比类型请求数服务器端压力用户体验网页加载速度模块加载顺序实现难度普通 1 小差慢文档流顺序简单 Ajax 多大好快不确定困难单线程 BigPipe  1 小好慢自定义一般多线程 BigPipe  1 一般（线程池引起）好最快不确定最困难
针对本文的例子，给出了上表的评价结果，这些结果并不是绝对的，它是针对网页较大、内容模块较多情况下给出的结果，从中可以很容易看出各个实现方式的差异所在。读者可以从中找到符合自己需求的实现方式。