ETag を使用して Web アプリケーションの帯域幅を削減し、ページ 1/2 をロードする_PHP チュートリアル
- WBOYオリジナル
- 2016-07-21 15:54:22811ブラウズ
介绍
最近，大众对于REST风格应用架构表现出强烈兴趣，这表明Web的优雅设计开始受到人们的注意。现在，我们逐渐理解了“3W架构（Architecture of the World Wide Web）”内在所蕴含的可伸缩性和弹性，并进一步探索运用其范式的方法。本文中，我们将探究一个可被Web开发者利用的、鲜为人知的工具，不引人注意的“ETag响应头（ETag Response Header）”，以及如何将它集成进基于Spring和Hibernate的动态Web应用，以提升应用程序性能和可伸缩性。
我们将要使用的Spring框架应用是基于“宠物诊所（petclinic）”的。下载文件中包含了关于如何增加必要的配置及源码的说明，你可以自己尝试。
什么是“ETag”？
HTTP协议规格说明定义ETag为“被请求变量的实体值” （参见 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html —— 章节 14.19）。 另一种说法是，ETag是一个可以与Web资源关联的记号（token）。典型的Web资源可以一个Web页，但也可能是JSON或XML文档。服务器单独负责判断记号是什么及其含义，并在HTTP响应头中将其传送到客户端。
ETag如何帮助提升性能？
聪明的服务器开发者会把ETags和GET请求的“If-None-Match”头一起使用，这样可利用客户端（例如浏览器）的缓存。因为服务器首先产生ETag，服务器可在稍后使用它来判断页面是否已经被修改。本质上，客户端通过将该记号传回服务器要求服务器验证其（客户端）缓存。
其过程如下：
- 客户端请求一个页面（A）。
- 服务器返回页面A，并在给A加上一个ETag。
- 客户端展现该页面，并将页面连同ETag一起缓存。
- 客户再次请求页面A，并将上次请求时服务器返回的ETag一起传递给服务器。
- 服务器检查该ETag，并判断出该页面自上次客户端请求之后还未被修改，直接返回响应304（未修改——Not Modified）和一个空的响应体。
本文的其余部分将展示在基于Spring框架的Web应用中利用ETag的两种方法，该应用使用Spring MVC。首先我们将使用Servlet 2.3 Filter，利用展现视图（rendered view）的MD5校验和（checksum）以实现生成ETag的方法（一个“浅显的”ETag实现）。 第二种方法使用更为复杂的方法追踪view中所使用的model，以确定ETag有效性（一个“深入的”ETag实现）。尽管我们使用的是Spring MVC，但该技术可以应用于任何MVC风格的Web框架。
在我们继续之前，强调一下这里所展现的是提升动态产生页面性能的技术。已有的优化技术也应作为整体优化和应用性能特性调整分析的一部分来考虑。（见下）。
自顶向下的Web缓存
本文主要涉及对动态生成页面使用HTTP缓存技术。当考虑提升Web应用的性能的时候，应采取一个整体的、自顶向下的方法。为了这一目的，理解HTTP请求经过的各层是很重要的，应用哪些适当的技术取决于你所关注的热点。例如：
- 将Apache作为Servlet容器的前端，来处理如图片和javascript脚本这样的静态文件，而且还可以使用FileETag指令创建ETag响应头。
- 使用针对javascript文件的优化技术，如将多个文件合并到一个文件中以及压缩空格。
- 利用GZip和缓存控制头（Cache-Control headers）。
- 为确定你的Spring框架应用的痛处所在，可以考虑使用 JamonPerformanceMonitorInterceptor。
- 确信你充分利用ORM工具的缓存机制，因此对象不需要从数据库中频繁的再生。花时间确定如何让查询缓存为你工作是值得的。
- 确保你最小化数据库中获取的数据量，尤其是大的列表。如果每个页面只请求大列表的一个小子集，那么大列表的数据应由其中某个页面一次获得。
- 使放入到HTTP session中的数据量最小。这样内存得到释放，而且当将应用集群的时候也会有所帮助。
- 使用数据库明细（database profiling）工具来查看在查询的时候使用了什么索引，在更新的时候整个表没有被上锁。
当然，应用性能优化的至理名言是：两次测量，一次剪裁（measure twice, cut once）。哦，等等，这是对木工而言的！没错，但是它在这里也很适用！
ETagフィルターコンテンツ本体
最初に検討するアプローチは、ページ (MVC の「ビュー」) のコンテンツに基づいて ETag トークンを生成するサーブレット フィルターを作成することです。一見すると、このアプローチを使用して得られるパフォーマンスの向上は直感に反するように見えるかもしれません。まだページを生成する必要があるため、トークンを生成するための計算時間も増加します。ただし、ここでの考え方は帯域幅の使用量を削減することです。これは、ホストとクライアントが地球の反対側にあるような、応答時間が長い状況で非常に役立ちます。東京のオフィスで、ニューヨークのサーバーでホストされているアプリケーションを使用すると、応答時間が 350 ミリ秒になったことがあります。同時ユーザーの数が増えると、これが大きなボトルネックになります。
コード
トークンの生成に使用するテクノロジーは、ページのコンテンツから MD5 ハッシュを計算することに基づいています。これは、応答の上にラッパーを作成することで実現されます。このラッパーはバイト配列を使用して生成されたコンテンツを保持し、フィルター チェーンが処理された後、配列の MD5 ハッシュを使用してトークンを計算します。
doFilter メソッドの実装は以下の通りです。
public void doFilter(ServletRequest req, ServletResponse res, FilterChainchain) throws IOException,
ServletException {
HttpServletRequest servletRequest = (HttpServletRequest) req;
HttpServletResponse serv letResponse = (HttpServ) letResponse) res;
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ETagResponseWrapper WrapperResponse = new ETagResponseWrapper(servletResponse, baos);
chain.doFilter(servletRequest, WrappedResponse);
byte[] bytes = baos .toByteArray();
String token = '"' + ETagComputeUtils.getMd5Digest(bytes) + '"';
servletResponse.setHeader("ETag", token); // 常に ETag をヘッダーに格納します
String PreviousToken = servletRequest.getHeader("If-None-Match");
if (previousToken != null &&PreviousToken.equals(token)) { // 以前のトークンと現在のトークンを比較します
logger .debug("ETag match: returns 304 Not Modified");
servletResponse.sendError(HttpServletResponse.SC_NOT_MODIFIED);
// 初めて ETag を作成したときに
servletResponse を通じて送信したのと同じ日付を使用します。 setHeader ("Last-Modified", servletRequest.getHeader("If-Modified-Since"));
} else { // 初回から - 最終更新時刻を現在に設定します
Calendar cal = Calendar.getInstance();
cal.set(Calendar.MILLISECOND, 0);
Date lastModified = cal.getTime();
servletResponse.setDateHeader("Last-Modified", lastModified) . getTime());
logger.debug("本文コンテンツの書き込み");
servletResponse.setContentLength(bytes.length);
ServletOutputStream sos = servletResponse.getOutputStream();
sos.write(bytes);
sos .flush();
sos.close();
}
}