1、WebLogic Server 性能及调整性能调整导航对 WebLogic Server 和 WebLogic Server 应用程序进行性能调整是一个复杂和反复的过程。以下部分提供调整导航和调整提示，可用于提高系统性能： 性能调整导航 调整提示性能调整导航以下步骤提供了导航，有助于调整应用程序环境以优化性能： 了解性能目标 测量性能规格 查找系统中的瓶颈 将瓶颈的影响降到最低程度 获得性能目标了解性能目标要确定性能目标，需要了解已部署的应用程序，以及环境对系统的约束。收集有关应用程序组件应达到的活动级别的信息，如： 预计用户数。 请求的数量和大小。 数据量及数据一致性。 确定目标 CPU 利
2、用率。 目标 CPU 利用率不应该是 100%，应根据应用程序的需要（包括利用率达到峰值时的 CPU 周期）确定目标 CPU 利用率。如果将负载正常时的 CPU 利用率优化为 100%，将无力处理峰值负载。某些应用程序对滞后很敏感，维持快速响应时间的能力对其也很重要，高 CPU 利用率（利用率接近 100%）可以缩短响应时间，同时吞吐量因服务器中的工作排队而保持不变，甚或增加。对于此类应用程序，建议将目标 CPU 利用率设置为 70% - 80%。对于对滞后不敏感的应用程序，合适的目标 CPU 利用率为 90%。性能目标受限于某些约束，如： 软硬件配置，如 CPU 类型和磁盘大小相对于磁盘速度
3、和足够的内存。 确定硬件要求并无一定之规。确定充分满足应用程序需要所需的软硬件配置类型的过程称为容量规划。要进行容量规划，需要对系统性能目标进行评估，还必须了解应用程序。应将服务器硬件的容量规划重点放在最高性能要求上。请参阅容量规划。 域间互操作能力、使用旧系统的能力、支持旧数据的能力。 开发成本、实现成本、维护成本。此信息将用于设置应用程序环境的实际性能目标，如响应时间、吞吐量和特定硬件上的负载。测量性能规格在了解性能目标中确定性能条件之后，对将用于量化性能目标的规格进行测量。请参阅加载测试工具。以下部分将提供有关测量基本性能规格的信息： 监视磁盘和 CPU 利用率 监视网络上的数据传输监视
4、磁盘和 CPU 利用率运行重负载应用程序，同时监视： 应用服务器（磁盘和 CPU 利用率） 数据库服务器（磁盘和 CPU 利用率）其目的是确定应用服务器是否达到目标 CPU 利用率。如果发现应用服务器 CPU 未得到充分利用，请确认数据库是否有瓶颈。如果数据库 CPU 利用率是 100%，请检查应用程序 SQL 调用查询计划。例如，SQL 调用是否正在使用索引或正在执行线性搜索？此外，还要确认用在应用程序中的 ORDER BY 子句是否太多，影响了数据库 CPU。请参阅操作系统调整。如果发现数据库磁盘是瓶颈（例如，如果磁盘利用率为 100%） ，则尝试改为配置更快的磁盘或 RAID（独立磁盘冗
5、余阵列） ，前提是应用程序此后不必执行更多写操作。知道数据库服务器不是瓶颈之后，判断应用服务器磁盘是否为瓶颈。应用服务器磁盘的某些磁盘瓶颈包括： 持久性存储写入 事务日志记录 (tlog) HTTP 日志记录 服务器日志记录使用更快的磁盘或 RAID、禁用 JMS 同步写入、对 tlog 应用 JTA 直接写入，或增大 HTTP 日志缓冲区，均可优化应用服务器上的磁盘 I/O。监视网络上的数据传输检查应用程序和应用服务器之间及应用服务器和数据库服务器之间的数据传输量。此数据量不应该超过网络带宽；否则，网络将成为瓶颈。请参阅 使用 ndd 命令设置 TCP 参数。查找系统中的瓶颈如果确定网络和数
6、据库服务器都不是瓶颈，则开始在操作系统、JVM 和 WebLogic Server 配置中查找瓶颈。最重要的是，运行 WebLogic Server 的计算机是否能在客户端负载很重的情况下达到目标 CPU 利用率？如果不能，则检查应用程序中是否发生锁定。应该用商业工具（如 JProbe 或 OptimizeIt）分析应用程序，以查明瓶颈，提高应用程序性能。提示：即使发现 CPU 利用率为 100%，也应该分析应用程序以提高性能。有关应用程序分析工具的详细信息，请参阅性能分析工具。将瓶颈的影响降到最低程度在此步骤中将调整环境，以便将瓶颈对性能目标的影响降到最低程度。在此步骤中是将瓶颈的影响降到最
7、低程度而不是将其消除，意识到这一点很重要。可以通过调整资源来获得性能目标。就本文档的讨论范围而言，调整项目包括（按重要性从高到低排列）： 调整应用程序 调整数据库 调整 WebLogic Server 性能参数 调整 JVM 调整操作系统 调整 WebLogic 持久性存储调整应用程序引用Mastering BEA WebLogic Server: Best Practices for Building and Deploying J2EE Applications作者的话：“应用程序的高性能始于良好的应用程序设计。如果应用程序过于复杂或设计不佳，性能也会不佳，与为提高性能而采用的系统级调整和
8、最佳实践无关。也就是说，设计不佳的应用程序可能会产生不必要的瓶颈。 ”例如，资源争用可能是由拙劣的设计而不是应用程序域本身所致。有关详细信息，请参阅： 调整 WebLogic Server EJB 调整消息驱动 Bean 调整 JDBC 应用程序 调整记录上一个资源 调整 WebLogic JMS 调整 WebLogic JMS 存储转发 调整 WebLogic 消息传递桥 调整资源适配器 调整 Web 应用程序 调整 Web Service 调整 WebLogic Tuxedo Connector调整数据库数据库可能是主要的企业级瓶颈。数据库的优化可能很复杂，其效果取决于不同的供应商。请参阅
9、数据库调整。调整 WebLogic Server 性能参数WebLogic Server 使用了许多 OOTB（现成的）性能相关参数，可对其进行微调，具体取决于环境和应用程序。根据系统要求调整这些参数（而不是以默认设置运行） ，可大大提高单节点性能和应用程序的可伸缩性。请参阅 调整 WebLogic Server。调整 JVMJava 虚拟机（Java virtual machine，简称 JVM）是一种虚拟“执行引擎” 实例，可在微处理器上执行 Java 类文件中的字节码。请参阅 调整 Java 虚拟机 (JVM)。调整操作系统每种操作系统的默认调整参数设置都各不相同。对于 Windows
10、平台，其默认设置通常已经够用。但对于 UNIX 和 Linux 操作系统，通常需要对其作相应调整。请参阅操作系统调整。获得性能目标性能调整是一种迭代过程。将瓶颈对系统的影响降到最低程度之后，转到步骤 2 测量性能规格，然后确定是否已达到性能目标。调整提示本部分提供调整总体系统性能的提示和准则： 性能调整并不是万全之策。简而言之，高系统性能取决于：良好的设计、良好的实现、明确的性能目标和性能调整。 性能调整是一个持续不断的过程。通过可提供性能规格（可用其与性能目标进行比较）的实现机制，可在系统出现故障之前安排一个调整阶段。 其目的在于达到性能目标，而不是消除所有瓶颈。系统中的资源有限。根据定义，系统中至少有一种资源（CPU、内存或 I/O）是瓶颈。通过调整可将瓶颈对性能目标的影响降到最低程度。 设计应用程序时要考虑到性能： 保持设计的简单性 避免不当使用已发布模式。 应用 Java EE 性能模式。 优化 Java 代码。
