1 在一个页面中，缓存的Control在页面中表现的是一个<esi>的标签，标签中会有一些属性。

2 Apache中的模块，要把每个返回给浏览器的页面，都拼装出来，然后检查是否具有<esi>标签，如果有，则要去Cache中找，没有，则直接通过。如果有标签，但是没有在Cache中，要重新渲染。

这里面有三个操作，我黑色部分标出来的。

对于渲染，Cache不命中都需要渲染，Apache的模块是重新走了一遍JBoss，而在新的方式中，是JVM内部的调用。这个地方我没有数据，但是JVM内部调用的开销肯定是小于Apache再走一次JBoss，我姑且认为两个是一样的。

对于拼装，写过Apache模块的同学会很清楚，在output_filter中，会有两个参数，其中一个是apr_bucket_brigade *pbbIn，如果要拼装一个完整的HTTP Response，是需要通过APR_BRIGADE_FIRST、APR_BUCKET_NEXT来遍历pbbIn。

那么这个地方有两个做法，一个是分配内存，把每个分片都复制在一起，组成完整的HTTP Response，另外一个是对每个分片做遍历，但是要考虑一个页面分在两个片上的情况。

具体的实现我要看了代码才知道，如果是每次分配内存、并Copy的话，那这个地方是会消耗不少内存的，因为对于每个页面都要做这样的操作。（可能的内存消耗）那么为了找<esi>标签，对每个HTTP Response的响应的遍历是不可少的。(对CPU的消耗)

假设，找到了<esi>标签，那么是需要构造新的返回的结果的，是需要构造一个新的apr_bucket_brigade，这个apr_bucket_brigade是由一个或者多个apr_bucket，而这些apr_bucket都是创建出来的。

当然，我没有能拿到Apache ESI Module的代码，这个只是我个人的分析。有些代码是依据我之前接触过的AtPanel打点模块来分析的。

对于XX的问题，我的看法是这样的，首先我们启动的时候的目标就是为了脱离Apache。如果这要说Apache ESI Module有什么可以改进和借鉴的，我个人觉得现在Apache ESI Module能做的应该都做了，如果之前提到的，在查找<esi>标签是先复制为一个完成的buffer，再查找，那是可以改进的(相信不是这么做的)，而其他后面的部分，找<esi>标签和构造新的apr_bucket_brigade 进行返回，我个人觉得已经没什么好改进了。

放在Java中处理，有一个优势。我们在处理的当时就知道是改怎么渲染Control，而在Apache的模块，你必须去检查。而对于把Cache的<esi>换成真正的内容，Java是直接拼装的，而Apahce是Copy&修改的，这个也是实现结构上决定的。