了解用于大型缓存实现的 WebSphere Application Server 选项

核心提示： 或许您需要大型 JVM 的原因并不是因为应用程序缓存，而是需要处理大量 HTTP 服务器对象或大型 HTTP 会话对象，了解用于大型缓存实现的 WebSphere Application Server 选项(6)，因为 HTTP 经常作为隐式应用程序缓存使用，ObjectGrid 提供了用于通过

或许您需要大型 JVM 的原因并不是因为应用程序缓存，而是需要处理大量 HTTP 服务器对象或大型 HTTP 会话对象，因为 HTTP 经常作为隐式应用程序缓存使用。ObjectGrid 提供了用于通过 Servlet 筛选器分流 HTTP 会话数据的内置机制。Servlet 筛选器以 J2EE EAR 文件的形式为应用程序提供 ObjectGrid HTTP 会话管理器，而且通过 addObjectGridFilter 脚本采用管理方式添加，此脚本以 Servlet 上下文初始化参数的形式向 Web 应用程序添加相应筛选器声明和配置——而不用进行任何应用程序更改。图 4 中显示了使用 ObjectGridFilter 为 HTTP 会话数据部署的应用程序。

图 4. 使用 ObjectGridFilter

通过这种方式使用 32 位 JVM 分流 HTTP 会话，同样可以通过避免 64 位寻址的开销而节约大量的内存。

DynaCache 和 Distributed Map

我并没有忘记这两项，不过对于需要大型应用程序服务器堆的情况，DynaCache 和 Distributed Map 都没有提供 64 位 JVM 的替代方案。DynaCache 是 WebSphere Application Server 的功能，可缓存 Servlet、JSP、Web 服务和 WebSphere Application Server 命令生成的结果，而 Distributed Map 提供用于在 WebSphere Application Server 实例中创建本地或远程缓存的 API。由于这些 API 都依赖于 WebSphere Application Server 运行时，因此缺少将缓存分流到独立缓存层的能力。因此，它们并不提供使用 64 位 JVM 保存缓存数据运行应用服务器的替代方案。虽然 Distributed Map 提供了磁盘分流（可以用于将缓存的大小限制为在 32 位磁盘空间内），但通过这种方式进行分流带来了在磁盘上写入和检索数据的延迟，其性能可能不为某些时间敏感的应用程序所接受。此外，正如我们提到的，DynaCache 特定于应用程序构件生成的输出，因此没有用于检索底层应用程序数据用于其他用途的机制。

结束语

在遇到了使用大量内存（处理缓存或 HTTP 会话）的应用程序的情况下，可将 ObjectGrid 作为替代解决方案，而不用过渡到 64 位 JVM。这两个方案各有优缺点：采用 ObjectGrid 处理缓存将需要进行一些应用程序修改（但此工作量应该很少），具有经济高效的特点，其性能很高，而且不用添加 RAM 和进行 64 位 JVM 所需的大量垃圾回收 JVM 优化。具体哪个选择适合您环境，应该由现有应用程序组成情况以及所需的实现时间内资源配备的可用情况决定。