改善J2EE性能和用户体验的管理变革
摘要
经过调查，我们知道客户对IT投资的期望并不是总能满足的。
这就是为什么需要不断改进软件管理方式和关注创新的产品以帮助从客户的应用, 数据库和基础设施中获得更高的性能和生产效率。
通过运用深入而专业的IT运营技术和持之以恒地总结工作中的最佳实践的情况，我们可以帮助我们的客户从企业IT中获得更高期望的满足。
1. 概览
本文将讨论的是, 应用性能的调优和分析工作应该是经常的工作，在应用的软件生命周期中应反复和尽早地进行。我们所说的用于调优和分析的 "迭代"方法，需要在它们累积，变得不可控制和提高成本之前能够发现性能问题。调优的工作必须由开发人员负责，他们需要把调优和分析当作开发过程的一部分。传统的作法是把调优作为一个从软件构造中分离出来的过程，或者指派给QA团队，而他们对代码和生命周期构造阶段并不熟悉。
我们看一下为什么需要采用这种迭代方法，理由如下：
这些动机反映了人们越来越意识到关键软件系统是一种战略资产，必须在整个开发和使用中保护和发展它们。
本文也将说明在整个开发阶段，怎样利用JProbe Suite和PerformaSure提供一套完整的测试过程，这是迭代测试的最佳实践。它将显示JProbe Suite的精确性，广度，细节和易用性，使得开发人员不但能确定问题出现的地方，并且当测试完成后也能够进一步改善代码。这将使问题在变得严重前减轻性能问题。本文还将说明在上线前的staging环境中，PerformaSure将如何帮助用户在整个J2EE栈中发现性能问题。
2. 介绍
当Java和定制的Web应用（J2EE）在Intenet编程环境中正在占据巩固统治地位的时候，性能和稳定性问题仍然倍受关注。随着Internet不断发展，公司推出软件比以前更快了，这不可避免导致产品中有更多的bug。华盛顿大学计算科学副教授Brian Bershad就说过"产品发布计划太快了，不是开发人员不够聪明，而是他们没有时间思考"。
不管目标是创建在线交易系统，电子商务网站，银行系统，门户应用或者客户关系管理系统，低下的性能都会转换成巨大的经济成本。更有甚者，最终用户开始期望在线应用的性能能像他们的汽车和日用设备一样快速反应。性能方面的小故障简直不可接受。
通常，我们说性能差，是指存在不合常规的编码和配置，结果导致内存使用的低效率，性能瓶颈，线程死锁和资源饱和。当应用运行时出现了这些不合常规的情况，它们能够导致令人沮丧的延迟，错误的传输，死屏，甚至应用崩溃。例如，毫无限制的内存增长能够使应用响应急剧减慢，使股市交易者在给定的时间内不能完成交易。当用户试图进行在线支付帐单时，性能瓶颈能引起令人难以忍受的延迟。
部署和交付逾期，预算超支，没有遵守产业规则，工作流中断，倍受折磨的客户等等，这些都是应用性能缺陷带来的潜在副产品。尽管如此，这些问题可以通过选用正确的产品和采用有效的风险管理策略防止，这些策略包括了开发和QA过程的最佳实践。
管理性能低下的风险的最佳实践主要集中在软件开发阶段的步骤安排上，稍后我们将探究其中的原因。性能调优和分析应该集成到整个开发阶段，而不是推迟到应用开发完成后才进行。此外，性能调优和分析应该被看作是预防性过程的一个方面，而不是单纯的等出现问题才处理。当最终用户部署完应用之后发现代码有问题，这不但需要更多的成本和时间修复它，对于用户体验也会产生负面影响。生产价廉而稳定的软件产品需要在整个开发过程中能够主动地识别和解决编写代码问题。
这意味着过程和思想的双重转变，包括性能的整体重要性，和如何设计，开发应用以及将它推向市场。
为了展示并解释这种转变，本文将指出：
总之，性能调优和分析的最佳实践是在应用生命周期的开发和QA阶段，执行一个完全集成的，迭代的和系统的过程。
3. 性能调优和分析的发展
如果应用的性能缺点造成了严重影响，那么人们就会希望性能调优贯穿于整个应用生命周期，调优使得J2EE应用稳定性的最大化。人们也希望采用一些能够确保应用性能和稳定性的可以依赖的策略，这些策略是应该被普遍采用并且能够融入到应用生命周期的过程中。
在一项调查中，有91％的回答者同意应该在开发中就进行性能分析。然而有53％承认这很少发生，为什么？
不幸的是，应用性能仍然没有被优先考虑，它没有功能性，易用性，遵从GUI标准，可维护性和开发时间重要。大部分是由于它的优先级低，性能调优和分析被看作是分离的过程活动，置于应用生命周期开发阶段的末期，并且通常局限于QA（与压力测试一起进行）。不幸的是，大部分的公司没有详细指定性能需求以便进行充分的测试。由于时间的紧迫，手工性能测试时间连同手工功能测试的时间被大大缩短，有时候甚至被取消。
如何把握这个方法呢？有时候，当涉及到指定确切的负载和可测量性的需求时，项目需求收集阶段的工作将更加困难。而且由于应用的使用量增长和使用范围的扩大，应用的性能和吞吐量比以前更重要了。不像功能测试，性能测试需要更多的开发者参与，以便确定问题的根本原因和可能的改善措施。性能问题通常比功能问题更难于诊断。
经理们需要理解这些影响，成本和中断，它们是在生产阶段的bug造成的。迹象逐渐表明在应用提交给QA之前，发现并排除bug能够比之后的修改节省10到1000倍的成本。Quest已经注意到在生产阶段发现性能问题后，开发团队将被要求作为J2EE专家帮助快速诊断和解决问题。这将是开发经理试图按期交付应用的一个主要障碍。
当客户争取获得更高的生产效率时，他们就会不断要求更高的性能和稳定性，特别是Internet应用，不稳定的代码将对公司的财务具有放大的影响。
3.1. 市场变化的动力
除了我们描述的原因外，向市场推出软件产品方式的改变也促使传统性能调优和分析方法的改变。
这种变化类型是使用最广泛和最有效的类型，用于模仿和跟踪发生在你特有业务环境中的变化。它给IT部门一种方式，测量那些几乎不可能量化的变化项目，就像以下的性能影响：
一些中大规模的公司正在指望把部分开发项目外包给劳动力成本低的国家。这种外包安排给保证应用高性能添加了额外的复杂度。在由国外开发的应用代码开发出来后，部署到生产环境之前，公司需要一种验证应用性能的方法。标准的以开发者为中心的解决方案，例如JProbe Suite，适用于接收外包的公司，但对于发出外包的公司就不大适用了，因为代码不是他们编写的。发出外包的公司需要一个更高层次的工具，可以查看应用的整个J2EE栈并且能够识别性能瓶颈，在这里，使用PerformaSure比较合适。在发出外包的公司和接受外包的公司之间必须能够方便地沟通，这才能确保应用的性能要求得到满足。接收外包的公司应该使用像JProbe Suite这样的工具，并且给发出外包的公司提供报告，描述关于性能测试过程，发现bugs等信息。
市场对于缺点的容忍度越来越小。它们也需要规模更大的，更复杂的应用（依赖于很多不同程序员编写的大量组件化代码）。考虑到面临的双重压力-需要在短时间内交付具有更多功能的应用，并且对缺点的容忍程度越来越低-，必须重新审视在整个应用开发生命周期中性能调优和分析的环节。
在某种程度上，软件组织是反应式的。在提前的交付日期要求下，他们修改他们的部署标准，并且转向更小的何更频繁的项目迭代过程。他们也充分利用面向对象代码对于模块所具有的继承能力。这使得他们能够发布应用的某个部分，即可以在整个项目完成前对这部分代码进行测试。换句话说，加速产品推向市场的需要和模块化的到来把性能调优和分析提前了。但是进行性能调优和分析是否足够早呢？他们真迭代了吗？这个责任和所涉及的工具是否已经交给了负责某个项目工作的所有开发人员呢？
在考察面向对象代码（特别是Java和J2EE）是如何促进使用集成的，迭代的方法之前，让我们概括一下前面讲述的当前性能调优环境。因为性能调优和分析需要宝贵的时间，并且未被看作是至关重要的需求（因为企业一般通过硬件升级来解决性能问题），这样就存在一种趋势，就是把性能调优和分析的优先级设为很低并且是可以牺牲的，甚至他们可以接受有一点瑕疵的应用。在今天的业务环境中，需要快速创建应用和部署应用，在快速变化的业务过程和市场中盈利，这已经被看作是一项众人都认可的观念了。另一方面，随着应用还在不断增加复杂度和像Java这样的面向对象语言的爆炸性增长，加速把应用推向市场意味着公司正在寻找其他选择。他们试图找到一种方法，在获得更高的性能质量的同时而不延迟应用交付时间。
简而言之，当前的环境是：
3.2. JAVA开发和性能管理的挑战
在市场急切要求提前交付应用和与之相矛盾的对Bug的无法忍受的双重压力之间，Java最适合解决这种问题。像Java这样的面向对象语言更适合用于模块化，并且使更早的，部署应用的某部分成为可能。这也促进了尽早地，集成地，迭代调优和分析。尽管如此，也应该强调一些风险：
随着组件和框架的使用需求不断增加，对于这些组件和框架，需要更多的性能测试用于确保它们可以很好的执行用例。像JProbe Suite和PerformaSure这样的工具能使技术人员深入了解出现瓶颈的地方和组件间的交互情况。
JVM中的垃圾回收机制并没有排除所有内存泄漏的出现。开发团队需要一个工具帮助他们了解在垃圾回收后内存中还有哪些对象仍然存在，这些对象是什么时候创建和在哪里创建的。
如果应用产生很多短期对象的话，垃圾回收系统也会引起性能问题。
J2EE开发仍然是相对是新生的，并且大部分公司缺少足够的经验用于预测困难和避免性能缺陷。工具和方法能够帮助指导这些公司达到更高的性能和生产效率。
J2EE应用服务器和JVM的配置是复杂的，并且对应用性能的影响是极深的。在staging和系统测试中，需要性能工具提供一种可视性，使能够看到系统层，组件层和事务层的性能瓶颈。
当负载大时，就会导致其它的性能，线程和扩展性问题。公司需要确保在staging测试时执行正确的扩展性测试，用于正确地识别在生产环境中将会出现的性能问题。
目前存在的系统管理产品不能监测J2EE系统和收集开发人员所需的用于正确诊断和解决在生产阶段中发现的性能问题的信息。
大部分的应用服务器都提供了JMX接口，允许用户监测应用服务器，但用户需要扩展这些接口和提供在事务层次上关键性能信息的监测解决方案。
早期调优能够有助于识别创建短期对象的方法，并且这时开发人员能够修改设计，这样可以减少这些短期对象的创建。早期调优也意味着从一种方法中抽象出类似的方法的有关效率的编码教训，能帮助开发人员避免无效率的重复。在稍后事例中，就是内存泄漏的例子，由于错误的引用使得垃圾回收不能回收内存。由于在该阶段，开发人员对于设计和实现记忆还很清楚熟悉，早期调优就能比较容易识别出游离对象和解决这些无意识的引用-通过垃圾回收后这些引用仍然存在。
Java的本质特性倾向于使开发者远离他们在应用中使用的众多代码，为应对这样的风险，需要强调把性能调优和分析看作开发阶段的关键因素。也需要新的测试和监测解决方案确保最大化正常运行时间，缩短在生产中解决发现问题的时间。
3.3. 实际中的迭代模型
前面我们提到大部分的经理和开发人员认同在应用开发期间应该进行性能调优和分析，但实际上只有少数人这么干了。当成千上万的用户同时访问从单个服务器上启动的应用，单个用户在其工作的客户端环境下不容易发现的一个小故障，将成为所有用户都将体验到的主要性能问题。
同样地，越往后解决问题成本越高，特别当应用变得更复杂的时候。正如Esphion的CTO，Juergen Brendel所描述的"在设计阶段修补一个主要的缺陷，我们需要的只是动动笔，但当软件大部分已经完成时才发现，可能就需要重新编码"。将性能调优和分析推迟到测试阶段（在部署之前）引起的风险太大，在这阶段暴露出来的问题会更加严重，需要比较高的成本和花费大量的时间才能解决。
成本效益的论点-将性能调优从反应型处理方式转变为预防型处理方式的价值-是非常有作用的。早期性能调优能够帮助团队避免最后一分钟的灾难，它会威胁部署日期，失去用户和破坏周密的计划预算。
当把成本效益的因素与软件生产的时间性要求，客户不断改变的功能需求和对性能不断减小的市场容忍度等一同考虑时，就形成了一个采用高灵活性的，迭代的和全面集成的性能调优过程的解决方案。开发团队可以满足不断变化的市场需求和在Internet应用中采用迅速流行的面向对象代码。企业必须确定把软件当作战略资产，在整个生命周期中必须保护和发展它们。
公司需要一个提高开发过程的"有机的"质量的模型，它认为需求的确定是一个不断增加发现的过程。这样一个开发模型将集中地进行：建立需求，规划设计，编写代码，发现问题，出现新需求，规划新的设计和编写新的代码--不断地迭代，向客户对应用和需求和期望值靠近。尽管如此，这还是不能排除对工具的需求，这些需求包括以J2EE为中心的一系列在生产和QA时使用的测试工具和监测工具。
要想获得最佳性能关键是在每个开发周期期间都要调优。这将有助于确保在新的应用中使用单独的类定义时，这些类是坚固的并且是可以安全地放心使用的。
3.4. 什么时候开始调优
在这个方法中，时间是必需的。性能优化和分析应该集成到整个开发阶段，并且组织到完整的用例中，这将使开发人员能够避免一些不必要努力同时确保错误不进行累积。
尽管如此，我们不会倡导"尽可能早"，过早地调优可能消耗开发人员宝贵的时间在代码上，这些代码在后面可能改变或者这些代码不完整。一方面应避免把大量时间用于调优最终丢弃的用例，另一方面应早期和经常调优，重要的是要对这两方面进行折衷考虑。可以针对每个用例的实现进行进行线程分析，内存诊断和性能剖析。在每个迭代阶段都能够迅速地插入需求的改变和错误修改。产品的部分发布成为可能，并产生可靠的源码，这些源码是基于反复的检验和问题的解决而形成的，因此提供一个坚实的基础用于建立随后的代码。为了节省时间，识别关键用例和他们性能的需求是非常重要的步骤，必须在性能调优之前完成它。
公司应该寻找业内领先的工具，这些工具可以集成到他们建立的系统和单元测试系统中，用于自动采集性能和内存信息，这些信息是每夜创建和测试过程的一部分。另外，QA工具需要与压力测试解决方案集成，同时生产监测和性能支持工具需要能够收集更深入的性能信息，特别是当影响最终用户体验的关键阈值被超过时产生的信息。
3.5. 应该由谁负责
在开发过程中，各个团队成员应该共同负责性能调优。业务分析必须确保他们精确地传递在新的业务解决方案中有关性能期望和压力期望的信息。这时架构师必须考虑他们的需求，公司的系统和专业技术，并且设计一个解决方案，确保可扩展。开发人员需要在代码级通力合作来负责应用的性能。
这不但体现了调优过程在时间上的一种转变，它也体现了责任上的一种转变。开发人员应该装备工具，使他们在代码编写过程中就能够调优和分析。
根据迭代方法，性能调优和分析的工作应该指派给最佳理解应用设计、目的和代码本身的人。有了他们第一手知识，开发人员能够作出关于提高性能最好的决定。而且，开发人员通过从开始就负责性能调优，使他们有机会了解具体的性能设计，这些宝贵的技能对于随后的项目是有利的。这样，开发人员可以在将应用提交到QA测试前就可以确保基本质量。
这不但没有消除QA团队执行性能测试和扩展性测试的责任，而且由于在开发期间进行的额外测试，确保他们所测试的代码更健壮。
3.6. 优点
这个方法能用于所有的项目吗？当决定在产品生命周期中如何尽早地进行性能调优和分析，并且决定由谁来负责时，很重要的一点是考虑项目的范围和具体的需求。在很少情况下，当确定应用不会发生变化或者如果应用特别简单，可能传统的方法更合适。但必须记住，即使是简单的项目，如果在产品交付时遇到非要解决的错误，特别是如果这些错误在部署后出现，那么成本很快就会变得很高。
有了重复的调优，迭代方法的最大优势是对每个用例都进行测试，使得每个用例的性能都很稳定。实际上，每一次中间里程碑发布都代表着一个实际的产品，所以随后的阶段可以看作是早期产品的扩展。这就得出一个结论，团队可以更早地给他们的用户发布产品，我们可以注意到这些都是愈加值得这么做的。例如，电子商务的客户通常都想快速地升级新的版本，这样他们就能够快速地提出需求。尽早地调优，并且逐块调试，这就很容易及时地部署应用。
其它的优势包括：
4. 方法论
使用JProbe Suite带来的性能调优和分析的最佳实践，这意味着要尽早期地和经常地使用它进行调优和分析。一旦实现了一个应用的用例，开发人员首先应该调优以确保获得最优的内存使用。使用JProbe Suite Memory Debugger进行堆分析将确保游离对象存活的时间不会超过其应该的时间。最后，开发人员使用JProbe Profiler调优性能。这样的话，当开发人员完成所有调优并且对每个用例实例进行修改后，这个单元代码就可以交给QA了。
获得Java代码稳定性，高性能，高效并且没有错误的最有效方法是首先确保代码正确，接下来是确保有效的内存使用，最后是性能的提高。早期和经常的进行这些步骤能带来性能调优和分析的最佳实践，这些工作最好由熟悉代码的人也就是开发人发人员来完成。
PerformaSure最好是在QA/测试阶段使用，最可能的是在staging测试环境中进行整个应用的性能调优（查看代码，应用设置和数据库性能相关问题）。用户也需要重新查看他们的生产环境，以确保他们有合适的工具监测和收集J2EE应用上的性能信息，因为即使在开发和测试阶段努力识别并消除性能问题，在生产过程中仍然可能出现问题。
5. 结论
导致87人遇难的空中客车A320分析报告揭示了这次灾难是由于一个计算机设计瑕疵造成的。1993年由于软件错误引起火箭推进器消耗完整个供应能源，导致价值8000万美元的卫星被摧毁。
不是所有由错误代码产生的性能实例瑕疵都是如此极端的情况，但它们都会产生不良的结果。随着市场要求的应用的复杂性不断增加，并且随着企业对基于Internet的任务关键性应用的依赖程度不断提高，所有的开发团队必须更加注意面对这些后果。并且，对于企业来说，把软件当作战略资产的需要必须具有优先权。
公司能够采取的最重要步骤是把他们性能调优的观点从被动的过程改变为主动的，预想的，预防性的过程。保持开发成本下降，和确保仍然吸引用户且使用户满意的关键是确保及时解决错误或者不要使之变得不可控制。
公司必须在应用生命周期的开发阶段，采用迭代方法，尽早地和经常地进行的性能调优和分析。他们也必须确保在QA和生产阶段所采用的解决方案能收集到所需的信息，帮助开发团队快速地分离出问题的根本原因, 确保可用时间增加。在合适的时间让合适的人使用合适的工具，这样公司就能改善他们的JAVA应用性能和可用性了。按照这个模型，公司不但可以确保比较高的JAVA和J2EE应用性能和稳定性；也大大加快产品交付的速度。
（北京铸锐数码科技有限公司 www.InnovateDigital.com）
- 在开发过程中消除序列化瓶颈
- 从设计者和架构师的角度强制一定的透明度，对于整个开发的效率是必需的
- 有助于开发人员更好的理解他们自己的代码和他们引入的代码
- 集中注意力排除早期的错误
- 可以采取措施消除随时可能的风险
- 集中注意力到重用的选项
- 突出产品的质量和性能
- 外包开发项目有不断增长的趋势
- 对应用的错误容忍程度越来越低的趋势
- 采用面向对象语言，已经意识到应用模块化的可能性，并且可以通过部署部分应用而测试更大的功能模块。
- 以前的情形是将性能调优和分析分配到QA和验收阶段，这是一次性的，反应式的处理方式。
- 现在的情形使得在早期进行性能调优和分析不但可行并且也是最佳的。
- 在执行过程方面，性能调优和分析的最佳实践，包括时间安排，人员和方法论等。
- JProbe Suite和PerformaSure在优化开发资源和时间方面的价值，贯穿整个提高Java应用产品性能的过程。
- 用户对性能和稳定性的看法已经发生重大改变
- 用户需求和将软件投入市场的方式已经发生改变
- 企业市场中JAVA大规模采用，特别是在服务器端领域