JVM 堆内存
除非在某些非常特定的用于实时处理的新 JVM 中，一般在每个服务器中存在一个 JVM 堆，该堆包含所有应用程序和 WebSphere Application Server 运行时组件分配的所有 Java 对象的所有实例。因此，此堆从定义上讲是在所有应用程序之间共享的，并且一个应用程序分配过多的对象很容易影响其他应用程序，结果可能是在堆上没有留下可供其他应用程序正确工作的足够空间，或者导致频繁的垃圾收集。
标准 WebSphere Application Server JVM 中没有限制每个应用程序访问堆的内在机制。因此，对于使用 JVM 堆资源而言，您的策略依据必须是确保每个应用程序行为良好。应认真测试每个应用程序，以确保它不存在内存泄漏问题。
如果确实存在错误并且造成堆超载，则便于分析堆内容和确定应用程序责任的非常好的策略应依赖于其实例占用堆空间的特定于应用程序的类名称。如果每个应用程序都使用不同的类，则更容易找出问题的根源。
应用程序部署构件
这些构件包括 EAR 文件、WAR 文件、Web 和 EJB 模块等等。除非在非常特殊的情况下，通常没有理由将逻辑上不同的多个应用程序合并到单一部署构件，并且对服务器资源的使用和性能没有太大的好处。每个应用程序应有自己的 EAR 文件和在该 EAR 文件中有自己的模块集。这样，您可以独立地部署、更新、管理和监视每个应用程序。还能让您独立地启动和停止每个应用程序，这在尝试隔离问题根源时非常方便。
与每个 Web 应用程序关联的虚拟主机
在应用程序之间共享虚拟主机时很少甚至不会节省什么资源（除了对 HTTP 连接可以使用较少的端口）。另一方面，向每个应用程序分配不同的虚拟主机和一个易于识别并且互不相同的上下文根，可以非常方便地在系统中的跟踪文件中跟踪 Web 请求流，并将其与给定的应用程序相匹配。因此，如果承载各种应用程序的网站组织允许，对每个应用程序分配不同的虚拟主机不失为一个好主意。
消息传递资源
这包括诸如服务集成总线、JMS 提供程序、队列、主题、目的地等资源。此类资源是在服务器范围分配的（可能连接到同样是服务器范围的某些其他资源，如 JMS 提供程序），并且可以由服务器中的一个或若干应用程序自由访问。
对于此类资源，一般很少关注争用和供应不足问题，但与服务器中任何其他类型的对象类似，它们确实消耗一定的内存量，因此可能需要决定是对某些实体创建单一共享副本可取，还是创建多个独立副本可取。
为每个应用程序定义单独的消息传递资源可能特别有益，这样可以单独地启动、停止和监视每个应用程序，从而便于进行各种故障诊断任务。
4. 执行对每个应用程序的端到端监视
认真计划应用程序包装和消息传递是它为监视环境带来的最大好处。监视工具（如 IBM Tivoli® ITCAM 工具套件）可以报告整个系统的运行状态，并能够显示环境中各个元素的性能。良好实施的命名约定可以让管理员和系统团队轻松地识别问题组件及其拥有者。
使用 Tivoli Performance Viewer 确定基本问题
随 WebSphere Application Server 提供的 Tivoli Performance Viewer 支持从应用服务器显示 PMI 的基本数据。管理员可以使用 Tivoli Performance Viewer 查看内部 WebSphere Application Server 资源的统计信息，例如 JDBC 连接池、Web 容器线程以及由应用服务器控制并且无法由更多传统系统工具访问的其他资源。
Tivoli Performance Viewer 显示的度量范围从轻量测量（如池活动）到更精细的测量（如 EJB 方法级响应时间）。虽然并不是所有测量都适用于某个大容量的生产应用程序，但它们确实提供了针对应用程序行为的有用见解，特别是在测试环境中更是如此。
例如，在测试环境中，测试员或管理员可以启用方法级度量来显示被测试应用程序（或应用程序组）的组件响应时间。如果 Servlet、JSP 和 EJB 都使用一致的命名标准，则管理员可以方便地将具有较长响应时间的元素与某个特定所有者匹配。
复杂监视
此相同的一致性命名原则还通过更复杂的工具集提供了一些好处。用于 WebSphere 的 Tivoli ITCAM 可让您在较高级别监视应用程序，然后逐层深入进行更详细的问题确定分析。管理员利用此工具的详细分析功能可以查看详细的流程和度量，包括泄漏检测分析，指出造成泄漏的代码行。显然，在此分析级别上，良好的类命名方案支持对由多个应用程序共享的环境进行调试和问题报告。此工具还支持按类名称过滤监视器。例如，在详细分析过程中，您可能希望通过将度量集中于属于一个特定应用程序的类，简化数据收集和减少开销。而且，强制的包命名方案使该操作更加容易。
