wasV5静态和动态的高速缓存.docx

WebSphere Application Server V5 中的静态和动态高速缓存高速缓存是提高应用软件性能的一项重要技术。几十年来，开发人员已经在许多技术中人工加入高速缓存。J2EE 和其他应用程序一样受益于高速缓存技术。WebSphere Application Server 通过引入一种功能强大的称为动态高速缓存 (dynacache) 的机制来识别这种技术。当考虑在 J2EE 应用程序中使用高速缓存的时机时，研究一下典型应用程序的基本体系结构是有帮助的。J2EE 应用程序开发人员通常按照模型-视图-控制器 (MVC) 的范例来开发自己的应用程序，在这种范例中，有“多层”代码来处理用户界面（视图）、业务逻辑（控制器）和数据访问（模型）。同样地，支持该应用程序的物理拓补结构也分为多层：最顶层加载负载平衡器和高速缓存代理。Web 层包括 Web 服务器。应用程序层包括一个像 WebSphere Application Server 这样的应用程序服务器。数据层可能包括数据库服务器或企业信息系统 (EIS)。在这些分布式体系结构中，高速缓存可以用来尽可能地提高每一层的性能并将其工作负载降到最低，最终达到提高性能的目的。通常高速缓存分为两类：一类是静态高速缓存，也就是说缓存中的内容是静态的、不变的。例如 HTML 文件，图象文件或 JavaScript 文件；另一类是动态高速缓存，保存程序动态运行的结果。在这一章里，我们将以一个基本的多层次应用程序体系结构为例，探讨高速缓存可以应用在哪些地方？然后我们将详细讨论不同高速缓存的各种参数，以及如何在应用程序中识别高速缓存潜在的作用。回页首使用高速缓存的时机下面的图 1 显示了一个典型的没有使用高速缓存的 J2EE 请求/响应实现流程。为了清楚地向读者介绍高速缓存的优点以及在配置了各种高速缓存后对一个请求/响应的影响，我们在这一章中将始终要用到这张图。每次执行一个动态请求时，比如请求一个 servlet 或 JSP，它可能需要遍历整个流程，如下图所示。即使是一个简单的带文件处理的静态请求也需要通过应用服务器来实现。显然地，为了完成这些请求,在不同的服务器之间有很多的网络跳转并且在各个服务器上都有资源正在被使用。网络跳转会给系统带来网络等待。更重要的是，每一层的处理都需要花费时间和资源。例如在应用程序服务器层，每一个跳转都会影响到很多层，如 Web 层、EJB 层、还有其他的服务如 JDBC 和 JNDI 等。可以想象一下，只生成一个简单的页面（可能是通过 JSP 来实现），必须执行一个 servlet、调用 EJB、访问终端数据库，然后将整个结果生成一个显示页面。不用想就知道当有相同的结果返回的时候会重复执行这个过程。比如有成百上千个用户想看同一个产品的目录介绍，就会导致工作负载过重和资源的严重消耗，而这原本是可以避免的。高速缓存就是提高性能的一项关键技术。图 1 是一个简化了的图，通常为了故障转移和可扩展性，在每一层都有很多服务器。如为了满足代理服务器的需要，Web 层可能由很多前端加载了负载平衡器的 Web 服务器组成。为了显示“最坏”的场景，我们在图中包括了一个代理服务器。因为我们后面还有讨论这个问题，所以我们在这个情景中包含了尽可能多的网络跳转。但是实际上很少有需要使用代理服务器的情况。应该注意到，如果一个代理服务器实际上被当作高速缓存代理服务器使用，它会自动提高性能，在后面的关于 WebSphere Application Server 高速缓存代理服务器的讨论中您会看到这一点。但同时在应用服务器和用户目录服务器上会产生一些冗余信息。图 1. 没有使用高速缓存的 J2EE 请求/响应回页首高速缓存在性能上的相互关联在图 1 的场景中，假设有一个用户请求某产品的目录，不难想象，服务器会调用各种各样的资源来完成用户的请求。为了构建产品列表，服务器会执行复杂的 SQL 联合查询语句从产品和市场数据库中提取数据，就像 Siebel 为了满足客户对价格和信息的需求而调用 ERP 系统一样。如果这个请求不是通过调用终端服务器来实现的，而是仅仅从前端代理服务器上的高速缓存中返回 HTML 结果，用户就会考虑性能上的差别。另外，当大量的请求在高速缓存中被解析，这些终端服务器的工作负载将大大减少（与消耗资源相对）。结果是吞吐量越大，现有的硬件和软件投资所能服务的用户就越多。不难看出，高速缓存是一个主要的性能调谐钮。在某些情况下，它能使系统性能提高三倍。我们经常说由于应用程序编码不规范导致用户不能调整其运行。但是可以通过 WebSphere Application Server 性能优化在一定程度上减少糟糕的代码对性能的影响。比如调整线程和连接池中的网络队列的排列，计算 JVM 堆栈大小。通