|
本文提供了十点有关性能方面的计划安排它们能确保你的应用得以完整实施 ． 应用需要性能调整 应该认识到应用在项目的不同阶段需要性能调整而调整需求是需要必要的资源和时间的你应该为此制定相应的计划下面的几点建议可能对你确定如何安排预算会有所帮助 ． 培养内部性能专家 安排两个开发者去理解性能调整有性能专家再好不过了但是如果你能安排好内部资源整体预算将会很便宜至少你的内部资源能处理基本的问题——建立基准规则声明响应时间目标诸如此类——即使你后来雇佣了一个专家验证处理或者提供更好的建议对于Java项目来说有足够丰富有趣的Java性能调整材料和工具存在因此性能调整可能被开发者认为是一项积极任务Java Performance Tuning 网站列出了许多Java性能调整的资源可以让你的开发者从那里开始 象为书籍和杂志在预算中拨款一样预算中也要包括培训和网页浏览的时间还包括为测试和购买不同测试工具的拨款你的性能专家应该估算如下费用剖析（profiling）工具;基线;网页下载或者GUI抓取和重放或者其他的客户端仿真工具这些为测试性能和创建基线的工具的选择在调整时将产生的不同费用和时间为这些做好准备并且确保你拥有正确的方法来根据你的需要做出正确的选择 理解性能调整和估量工具可能不是开发者的最主要的任务如果事情进展顺利的话它可能永远不会成为首要任务但是根据我的经验越是到了项目快结束的时候内部的性能专家越是要在性能调整上花费更多的时间 ． 在规范中规定性能需求 应用的性能需求需要在制定规范阶段定义这不是开发者的主要任务顾客和商务专家需要确定什么样的响应时间能够接受从声明什么样的不能接受的响应时间开始定义可能是较好的办法这个任务可能在开发的更靠后的阶段被承担事实上它可能比较简单如果原型已经写好运用原型和其他的商务信息去声明可接受的响应时间但是切记不要在开始任何实现性能调整前忽略声明响应时间需求如果代码调整在性能需求声明前开始那么要实现的目标将会被不恰当定义并且调整成就将浪费在应用根本不需要的地方 如果你的开发环境是基于层的（应用层组件层技术体系层）尝试一下在每一个层定义性能规范使得每一个团队有他们自己的性能目标去实现如果不这样性能专家将需要能够跨层调整并且与所有的小组进行交流 ． 在分析中充分关注性能 在分析阶段主要的焦点是为应用中共享的和有限的资源分析需求例如一个网络连接既是共享的又是有限的资源一个数据库表是一个共享的资源线程是一个有限的资源如果没有正确的设计这些在以后安装时将需要花费最多的资源应该分析数据卷和装载携带容量以确定系统的限制 这个任务应该融合到正常分析阶段站在安全的一方考虑或者为了突出性能分析需求你可能希望为性能分析分配计划分析时间的%分析小组明白不同的设计选择对于性能的影响是很重要的因此了解这些他们不会错过需要分析的系统的某些方面分析小组可能首先需要精通于性能目标设计的书籍诸如《高性能Client/Server》（可以参考更多这方面的资料）分析应该与技术体系结构分析联合进行结束时你应该有一本清楚的确定性能方面的体系结构蓝皮书 ． 需要从设计中得到性能预报 在设计阶段中分析阶段性能考虑的进展应该聚焦于应用使用的共享资源以及已考虑的要部署的应用物理体系结构的性能地位 确保设计者清楚不同决策的性能结果这些决策要求性能影响预报应该包含正常设计的各个方面客观的设计验证应该包含精通设计抉择方面的性能设计专家的意见另外一个精通设计的副手性能专家应该检查应用设计如果应用了一个重要的第三方产品——例如中间件或者数据库产品——产品的卖主应该有性能专家能够验证设计和识别潜在的性能问题为了突出性能的重要性为性能方面分配%的预算是正常的安全选择 设计应该包含关于用户和数据/对象卷的可升级性应用分布的可能数量依赖于两个分布组件消息的需求级别事务处理机制和模式（乐观的悲观的要求锁事务处理期间和锁有效）多用户应用的性能理论限制是共享资源的数量和锁有效期限如果相关设计也应该包含一个关于处理查询大数据集的章节 ． 创建一个性能测试环境 开发阶段开始时的性能任务是建立性能测试环境（代码性能调试时间应该确定在开发阶段的末尾参考第点）你需要 · 声明基于制定规范阶段的基准功能和要求的响应时间（第点） · 为系统确保合理精确的测试环境 · 为测试环境制定规则的唯一的性能测试时间表如果测试环境是共享的性能测试不能与其他活动同时发生 · 购买或者创建一个性能测试工具这个工具能够用模拟用户和外部活动驱动来驱动应用 · 创建提供可再生应用活动的可重用性能测试（注意这不是QA测试不应该一直测试系统的失败模式除非所有的正常活动全在预期范围之内） · 准备测试和监视环境（这是正常的系统细节并且通常随着测试进行而进展你将最终既需要有网络统计表和应用级性能（将在点进一步讨论））还需要有性能监视工具或者监视潜在的系统性能的脚本 · 按照你的性能测试计划从你的开发环境到你的性能环境为代码定版本和发行制定计划（注意这常常需要一轮打补丁来严格地运行测试并且时间限制通常意味着等待完整的QA 证书是不可能的因此将需要一些开发者的支持并且应该为之制定计划） ． 为验收测试模拟或者框架系统 创建系统的模拟该模拟要如实表现应用的主要组件应该实现该模拟这样你就能够测试系统的可升级性可确定共享资源如何响应增长的负载并且确定受限资源在哪个阶段开始用尽或者成为瓶颈当组件可用时该模拟应该允许完成组件的一体化（组件的整合）如果预算资源不可用可以跳过初始模拟但是一旦有足够的可用组件来实现系统的框架版本就要开始测试这样做的目的是为了尽可能早点为设计验收反馈确定系统的响应时间和可升级性 如果你有一个已计划的概念证明阶段它能够提供模拟或者一个好的模拟基础理想情况下验收会作为概念证明的一部分发生 ． 将性能日志整合到应用层边界 将性能纪录整合到应用这些记录应该与发布的应用部署在一起性能日志应该添加到所有主要层的边界I/O和marshaling层小应用程序I/O和marshalingJVM服务器I/O和marshalingDB访问和更新事务处理边界诸如此类应该设计性能日志它能给所有应用行为添加至少%的时间理想情况下它可配置成集合大量数据这样纪录能够被配置成在每一个可配置时间单元产生一个摘要纪录行（例如每分钟一个摘要行）为了更容易处理和分析你的记录结构应该进行完美的设计这样输出可以在其他工具里使用 ． 多等级范围内性能测试系统并运用结果信息进行调整 在代码实现期间单元性能测试应该与QA一起安排时间进度在没有为QA做好准备之前在单元级别性能调整不会有要求单元性能调整通过将单元整合到系统模拟运行伸缩性测试并作剖析(profiling) 只要可行测试整个系统或者仿真是非常重要的即使有许多单元是不完善的在系统性能测试的早期模拟单元是可接受的最初系统性能测试的目的是验证设计和体系结构以及来鑒定将不scale的设计或者实现的任何部分(点和点)到最后测试应该提供详细的记录和概要文件这些允许开发者直接找到系统中的瓶颈并且产生应用的更快的版本 为了在最后阶段支持性能测试应该能设置testbed(搞不明白怀疑原文有误推测为测试纪录)不仅提供任何JVM进程的性能概要文件还要提供除了性能日志以外的系统和网络统计短期（到天）预算一下以获得来自你的目标系统的系统统计并加以分析最理想的情况是系统管理员已经具备了这些技术 性能测试应该测量用户和数据的较高负载两次测试预期的高峰负载 · 与预期数据量高峰和预期用户高峰一起测试两次预期吞吐量最高峰 · 与预期吞吐量高峰和预期用户高峰一起测试两次预期数据量最高峰 · 与预期数据量最高峰和预期吞吐量峰值一起测试两次预期用户最高峰 用户活动应该尽可能精确的模拟但是模拟数据产生预期真实的数据种类是最为重要的否则高速缓存活动能够产生完全误导的结果用对象的数量来衡量合理的数量这对检索测试和批量更新尤为重要万万不要低估为衡量测试而创建大量现实数据的复杂性 结合性能日志特征部署系统 性能日志特征应该与发布的应用部署在一起该日志允许为已经部署的应用进行远程分析和持续的性能监视最好是你自己编写应用工具自动分析性能日志最简单的能让人接受的性能日志分析工具要能用日志和一套参考日志来比较性能和突出异常 另外还有其他一些有用的工具包括能识别性能日志中长期倾向的能确定什么时候特异的性能尺度超出范围的一个图形接口的或者支持标准GUI管理工具的工具也很有用(最后更新) |
