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