聚沙成塔-小哈的记事薄

前一篇文章说到了前端优化对响应时间的提升效果，不过要用到这种好处，首先要做的就是让WebSphere个组件各司其职——IBM Http Server处理静态文件，WebSphere Application Server处理动态内容——所谓的“动静分离”。

先了解一下WAS是如何处理静态内容的：

静态内容被返回到用户的方式至少有三种。它们是：

1. 静态内容通过 WebSphere Application Server 中的 File Serving 功能从 WAR 文件返回（缺省情况）
2. 静态内容从 Web 服务器返回
3. 静态内容从 Caching Proxy Server 返回，如从 WebSphere Edge Server（以下称为 Edge Server）产品中的 Caching Proxy Server 返回。

我们来看一个例子，下图中的应用程序是默认安装的BusinessObjects的Crystal Reports Explorer组件：

简洁的页面，却也有415K的内容，本地打开速度为2.3S。接下来我们把静态页面转移到IHS上，看看结果如何。

打开位于 WAR 文件下的 WEB-INF 扩展中的 ibm-web-ext.xmi 文件，编辑或者添加fileServingEnabled=”false”来禁用Application Server 的文件服务功能。同样修改config目录下的ibm-web-ext.xmi 文件（注：应该是在程序打包时就禁用fileServingEnabled功能，修改文件的话注意各个地方的统一）。重启应用。

再次刷新程序首页，发现已无法访问。我们重新生成、传播插件，比较前后的差别，发现

<Uri AffinityCookie=”JSESSIONID” AffinityURLIdentifier=”jsessionid” Name=”/adhoc/*”/>

变为了

<Uri AffinityCookie=”JSESSIONID” AffinityURLIdentifier=”jsessionid” Name=”/adhoc/updatehandler.jsp”/>
<Uri AffinityCookie=”JSESSIONID” AffinityURLIdentifier=”jsessionid” Name=”/adhoc/updatehandler.csp”/>
<Uri AffinityCookie=”JSESSIONID” AffinityURLIdentifier=”jsessionid” Name=”/adhoc/updatehandler2.csp”/>
<Uri AffinityCookie=”JSESSIONID” AffinityURLIdentifier=”jsessionid” Name=”/adhoc/*.jsp”/>
<Uri AffinityCookie=”JSESSIONID” AffinityURLIdentifier=”jsessionid” Name=”/adhoc/*.jsv”/>
<Uri AffinityCookie=”JSESSIONID” AffinityURLIdentifier=”jsessionid” Name=”/adhoc/*.jsw”/>
<Uri AffinityCookie=”JSESSIONID” AffinityURLIdentifier=”jsessionid” Name=”/adhoc/j_security_check”/>
<Uri AffinityCookie=”JSESSIONID” AffinityURLIdentifier=”jsessionid” Name=”/adhoc/ibm_security_logout”/>

原先不管三七二十一的转发，现在Application Server 已经智能地重新生成了插件文件，以便让 Web 服务器服务静态内容。插件文件将 servlet 和 JSP 的动态 URL 传递回到Application Server。现在要做的就是配置Web服务器来对静态的URL加以识别。我把adhoc.war中的静态内容拷贝到了HTTPServer\htdocs下，同时修改httpd.conf文件，添加

重启Apache，再次访问，首页又出现了，而停止IHS服务器，你会发现页面有开“天窗”，说明访问的静态资源是在Apache上的。于是我开启了IHS的deflate压缩功能，同时加上Expires头部，那么那些经常处理业务的人员，就不用每次都下载重复的图片，重复的CSS了，而且发请求得到304 Not Modified的动作，都会被省略（刷新的时候不会，但点击页面的时候就会少很多request）。

大小从415K缩小到106K，时间减少到1.48S，提升的空间还是很大的。

当然好技术不能滥用，过度的优化也是万恶之源——简单如动静分离也会带来应用发布更新上的不便，在行动前要了解自己现有的性能情况，明确自己的目的，分析自己的网络拓扑，然后规划好详细的优化步骤，确保这些动作都是可以回滚的。在 WebSphere Application Server 中处理静态内容 这篇文章是你动手前所需要好好阅读的。

摘录总结性的一段

在什么情况下您会选择每一个先前所描述的选项呢？您如何权衡每一个解决方案的利弊呢？下面一组指导原则可以帮助您对静态内容作出决定：

• 如果您在 WebSphere 的安装中性能不成什么问题，那么请不要想那些更复杂的设置。将您的静态内容保存在 WAR 文件中然后让 file serving servlet 服务它们会比较容易且更加节省成本。
• 如果在 WebSphere 的安装中性能是个问题，那么就请将文件解压缩，这样会提高您站点的整体性能。但是，解除打包与替换静态内容可能影响效率，除非这个过程可以通过使用上面提到的技术来重复。
• 如果您有性能需要，并且有能力支付这项花费，那么从长远看最好的解决方案是使用高速缓存代理服务器。像 WebSphere Edge Server 这样的产品（包括执行诸如负载平衡、动态（JSP/servlet）高速缓存以及内容管理这样任务的组件）可以提供额外的性能帮助。

http://www.redbooks.ibm.com/Redbooks.nsf/RedbookAbstracts/tips0223.html?Open 这篇tip是说明如何在WebSphere上实施动静分离的。