自动执行 Java 性能优化

《自动执行 Java 性能优化》由会员分享，可在线阅读，更多相关《自动执行 Java 性能优化（11页珍藏版）》请在金锄头文库上搜索。

1、自动执行负载生成和性能优化过程为什么可以节省大量的时间和精力。优化可能是一项非常艰巨而费时的工作，尤其对于需要最佳性能的环境来说更是 如此。优化所带来的好处是使环境更稳定、故障更少、总体性能更佳。也许您幸 运地拥有内部性能优化人员和专门的性能优化环境，如此优越的条件是非常罕见 的。如果您像其他人一样，需要在有限的时间内完成性能优化，本文将为您讲述 自动执行调优过程如何比手动调优更轻松、更快捷、更全面。1性能优化的基本原则Java 性能优化是一个持续不断的、通常历时很长且令人沮丧的过程。调优很少 会一次性解决性能问题。有时，不管您添加了多少硬件，或者花了多长时间试图 调整晦涩难懂的内存参数，可能

2、都难以达到理想性能。要获得最佳性能，需要明 确的性能目标、深思熟虑的设计、坚实的执行情况，并且最终要执行彻底的性能 优化。2 首先要制定明确的性能目标在采取任何步骤优化性能之前，首先要确定性能目标。这是因为预期的行为和用 户数、数据量以及请求大小在很大程度上决定着您将作出什么类型的优化决策。 每个环境都是唯一的，清楚地了解应用程序和环境的限制以及您希望达到的性能 和负载水平，对于您日后深入过程将有所帮助。3 优化 WebLogic Server 设置可以调整的 WebLogic 设置差不多有几百个：池大小、调整连接积压缓冲、缓存、JDBC 和 JMS 设置、使用工作管理器设置优先级、集群等。您

3、可以先从查看WebLogic Server的几大优化建议开始。4 查找瓶颈问题并不总是与 JVM 或 WebLogic 设置有关。请确保正确调整操作系统和网络 设置以满足应用程序要求，尤其在使用 UNIX 或 Linux 时。在负载状态下监视 服务器的磁盘和网络 I/O 以及 CPU 利用情况。如果数据库性能不佳，还应检查 您的数据库块大小、池大小和其他特定于供应商的性能优化设置。任何基础资源 限制都可能导致显著的性能下降。请记住，最终目的只是达到您的性能目标，而不是清除每一个瓶颈。系统中将始 终存在一个瓶颈或最慢部分，但最要紧的是达到您的性能目标并使客户满意。5 优化应用程序代码设计应用程序

4、时需要考虑性能因素，这一点是显而易见的。在当前的 SOA 环境 中，应用程序很容易变得过于复杂，并存在很多影响性能的问题。设计不良的应 用程序可能会引发系统资源、网络或数据库瓶颈。请使用经过验证的性能模式来 设计应用程序，并使应用程序尽量简单。6 优化堆无论使用什么应用程序，如果堆不足或花费大量时间进行垃圾收集，您都应该尝 试调整整个堆及其新生代的大小。可用堆的大小通常会显著提高或降低应用程序 的性能。为 WebLogic 服务器确定合适的堆大小对于提高性能非常重要。作为确定大小的 一般规则，您希望在每次垃圾收集结束时释放大约一半的堆空间。换言之，即堆 的大小应至少是其活动对象的两倍。也许最基

5、本的堆性能优化步骤是将最小堆大小设置成与最大堆大小相同。此建议 同样适用于新生代（在 Sun HotSpot 中为 New generation，在 Oracle JRockit 中为Nursery）大小的设置。默认情况下，经常出现堆扩展和堆收缩时JVM会 浪费资源。您尽可以将堆大小设置为系统可以处理的最大值（除去操作系统和其他应用程序 所需的内存）。较大的堆会降低垃圾收集的频率，但可能需要花费较长时间来执 行较大的垃圾收集。VM用于处理本地库和permGen （如果使用Sun HotSpot）的内存始终大于堆大 小，因此请注意，不要超出物理 RAM 的总大小。操作系统将内存分页到磁盘时 将显

6、著降低性能。7 试用垃圾收集器垃圾收集是用于从不再使用的对象中回收堆空间的一种机制。有多种垃圾收集模 式（从JVM到JVM）,这些模式都以不同方式使用系统资源。您在优化过程中 的工作是确定什么类型的垃圾收集模式最适用于您的特定应用程序和性能目标。选择收集器时的目标就是使垃圾收集暂停时间尽量缩短，从而提高垃圾收集吞吐 量。有关如何使用 JRockit 垃圾收集模式的信息，请参见“选择和优化垃圾收集 器”部分。有关 Sun HotSpot VM 可用的垃圾收集模式的详细概述，请参见 Sun 的 Tuning Garbage Collection with the 5.0 Java Virtual

7、Machine （使用 5.0 Java虚拟机优化垃圾收集）。8 其他注意事项JRockit 和 Hotspot JVM 提供了许多特定的 JVM 性能选项。影响性能的WebLogic 设置非常多。要进行有效优化，最重要的是使开发人员、架构师、系 统工程师、QA测试网络工程师和DBA作为一个团队进行协作。在优化过程中实 现跨学科参与可以精简工作，获得更佳结果，从而最终降低优化所需的成本和时 间。9 自动化的优点我们已经了解了 WebLogic 性能优化的几个基本原则，现在来看一下自动执行这 些任务如何真正使性能优化更容易、更省时、更有效。10 快速更改，频繁优化我曾多次看到，自动执行性能优化过

8、程所产生的结果比专家独自执行优化所产生 的结果更好。这主要是因为，自动过程可以快速执行更改并确定和衡量更改对性 能的影响，比神经最兴奋的人还要快，还要周到。另外，由于调优变成一个省力 的过程，您还可以针对每次代码发布进行优化，从而与应用程序更改取得同步。 对应用程序功能的细微更改都会导致很多预料不到的性能问题。另外，很多人错误地认为调优是可做可不做的事情，因为他们当前的响应时间很 充裕。人们很容易忽略这样一个事实，即正确的调整可以提高服务器的稳定性和 持久性。不调整或错误调整可能会导致故障，而经过正确调整的环境运行起来更 具可预测性且更稳定。11 节省时间，挖掘性能潜力我们在优化服务器上通常做

9、得不够频繁或不够彻底，仅仅因为这一过程非常费 时。当您自动执行此过程时，手动执行需要几天时间的工作现在在无人干预的情 况下一晚上即可完成。以前花无数个小时进行调优的人员现在可以节省这些时间 做更有意义的事情。随着故障减少、性能提高、正确利用硬件、“繁重工作”减少以及可以利用节省 的时间做更多工作，自动执行 Java 优化所带来的财务结余将会快速增长。在当 今苛刻的环境中，性能上的细小收益通常都会带来显著的资源节省。12 边看边学了解代码更改和不同调优变量如何影响性能非常具有启发作用。自动执行优化和 分析允许您尝试更多不同的设置组合，并且通过适当的监视，您可以同时看到结 果。这就像站在性能专家团

10、队的肩膀上；您开始了解为何作出某些优化决策，在 这个过程中您能够学到很多知识。您还能够针对每次代码发布轻松地优化服务器，这也算是一个很不错的意外收获 吧。由于知道将不会有惊喜，因此在部署生产时，您会拥有一个比较平和的心态。13逐步执行自动优化在本部分中，您将了解使用 Arcturus Applicare 优化向导查找最佳 JVM 设置 的过程。为了节省时间，我将演示测试各种垃圾收集设置的过程。简单来讲，优化向导将启动负载测试、监视服务器、分析行为、基于嵌入式智能 作出决策、优化配置并回弹服务器。此过程将重复执行，自动优化各种JVM、操 作系统和 WebLogic 设置，直至找到最佳组合。以下是

11、每个步骤的分解内容。由于自动执行时优化变得非常容易，因此您可能很快就希望进行微调和试验。在 优化向导中，有很多可用于控制资源利用的高级选项，我将在后面进行详细介绍。 与在任何性能优化过程中一样，您需要对应用程序行为有所了解。如果应用程序 有预热时间或初始缓存时间段，必须确保运行足够时间的负载才能获取精确结 果。14 选择负载测试设置优化向导与 Apache JMeter、HP Load Runner 和 The Grinder 负载生成工具进 行了集成，它还能够触发您自己的自定义 Java 应用程序和 shell 脚本所生成 的负载。我还没有生成负载工具设置或任何负载脚本，因此我使用JMete

12、r （系 统自带）并遵循以下指令来记录测试脚本。启动优化向导时，我指定了负载脚本，它允许自定义要模拟的用户数。在本次测 试中我选择了 70 个用户，因为根据以前的测试我知道，当用户数达到此数值时 我的应用程序性能开始下降。第一次优化服务器时，您可能不了解您的应用程序处理多少用户才会导致性能下 降。如果我不清楚我的环境可以处理多少用户，我可能会使用一个称为“容量确 定”的简洁功能（图 2），而不必进行猜测和购买更多服务器。容量确定的目的 是找到良好吞吐量的最佳平衡，而不超出您的资源利用限制。容量确定允许您设 置初始用户数和将要尝试的最大用户数，在优化时它将增加负载，直至在吞吐量 和资源利用之间找

13、到平衡点。图 2. 自动执行容量确定功能15 选择测试条件接下来，您需要选择每个优化会话要采用的监视样例数，以及这些会话之间的时 间间隔。正如我在前面提到的，如果您的应用程序有预热时间或初始缓存时间段， 则此时您可以通过优化设置来确保测试时间足够长，以便得到精确的基准值。我 选择每个会话采用 20 个样例，时间间隔为 60 秒。图 3. 由于应用程序各不相同，您可以根据需要调整样例数及样例时间间隔以，获得精确的基准值。16 开始“执行”现在您可以坐下来放松一下。您还可以安排在任意时间开始优化，这样，如果您 要在以后的非高峰时间进行优化，则不必亲临现场。优化向导将尝试其中每个设 置，当优化结束后

14、，优化向导会生成报表，给出有关哪些设置提供最佳性能的建 议。当服务器处于负载状态下时，优化向导将监视服务器的性能和运行情况。向导通 过查看吞吐量、堆信息、CPU利用情况、线程、等待者、队列（基本上包括了您 所观察的全部内容 如果您亲自运行负载测试的话）完成此任务。在启动优化 会话时可以设置和自定义样例之间的频率和时间间隔。这是优化向导和 Applicare 其他功能最具吸引力、最有价值的一个方面。它随 制定智能化性能优化决策的人工智能引擎一起提供。根据性能优化顾问的综合经 验、经过验证的优化方法和最佳实践构建了知识库。可以查看负载测试过程中生 成的数据，并对下一步将要优化的内容作出明智的决策。

15、优化向导在达到最佳可 能组合后，将结束优化过程。我可以在 Applicare 控制台中实时查看进度表，也可以等到测试结束后查看报 表。如果您要查看数据以便得出自己的结论，可以参考大量的报表和图表，它们 针对每个优化设置的行为提供了完整的详细信息。17 结果在这里，我简要讨论优化结果，显示 Applicare 创建的一些有关优化会话的图 表，并讨论 Applicare 给出的一些其他建议。这不是详尽的优化练习，但它显 示了优化向导在少量负载状态下可以在短时间内完成的任务。优化过程历时 4 小时完成，它尝试了 9 个不同的设置组合，并优化了 JVM 设置和其他设置，包 括线程、 JDBC 设置等。

16、优化向导查找过小或过大的配置区域并进行适当设置。 根据我为优化向导提供尝试的参数，最佳设置如下：-Xms512m -Xmx512m -XX:CompileThreshold=8000 -XX:PermSize=48m -XX:MaxPermSize=128m -Xverify:none -XX:NewRatio=3 -XX:SurvivorRatio=6 -XX:+UseParallelGCApplicare 提供一组显示优化结果的图表，为了节省空间，我给出了显示优化前 后变化的吞吐量和堆图表。您可以看到堆的利用率较低，并且主要垃圾收集的暂 停时间较短。您还可以看到，在主要垃圾收集发生时吞吐量下降，这表明优化前 的初始设置在主要垃圾收集期间会导致很长的暂停时间。图 4. 此图表显示优化后的吞吐量（蓝色）好于优化前的