我前一段听百度一哥们讲了几个实战，还是很有感触的，其实也是那些调优的方式方法，主要是看怎么去合理的应用。
如果只回答这个“性能调优从哪些方面入手”，我想首先当然是从性能测试入手，从基于经验和前辈的总结的性能分析入手，先进行理想化的配置也好，设置也好，部署也好。想想也是，如果不测试，我们就不知道，甚至猜都猜不好哪儿可能有问题。
然后，就结合本贴7#，9#两位兄弟的经验，加日常测试的积累，进行调优工作呗。
调优的内容应该包含了这个系统能跑起来所用的所有因素：如:意想不到的配置，OS集成，网络因素，代码因素，存储机制。
具体要做的事，针对不同问题，具体问题具体分析（相当于没说，哈）
再附上百度那哥们讲的一些案例，就像网上的其他案例一样，一些案例虽说比较不太大众化，或者不太容易被模拟，但是启发性很强，可以让大家的思路更开阔，更容易下手。
性能调优之我见（二）
本帖最后由 fatfish 于 2011-11-22 09:41 编辑四） 意识层面
当今社会万事讲求以人为本，如果从软件应用系统涉及的各级人员角色的内心没有把性能表现当回事，那么一切调优最多也都是亡羊补牢而已。比如：
a) 产品经理：项目乙方产品总负责人，产品目标、市场定位、基本框架的制定者。
b) 一线人员：售前咨询、实施顾问等。
c) 需求设计：对产品具体功能设计提出明确要求的角色。
d) 代码实现：按需求定义进行产品的具体实现的角色。
e) 测试人员：对产品质量进行检测、对开发过程进行监管的角色。
f) 最终用户：系统最终的使用者、应用效果的影响者。
对于一个软件产品来讲，只有以上这些环节的角色人等在各自的工作岗位上，真正的在意识层面上提高优化系统性能的地位，而不是把它作为功能优先实现之外的附属品，才能把系统性能优化的工作最大程度的作在前面、作的全面、作得到位！
综上所述，我们看到了各类导致性能瓶颈的可能原因（也可以说是性能调优的入手点），下面我们用一个比较常用的鱼骨图分析法来展示一下，可能会更为清晰：
然后我们再把这些原因按一定的规则进行分门别类，一般采用如下的二维矩阵分析的方法，按可推行的难易度和收效的影响度高低来形成四个象限，把这些问题按具体情况分布在这四个象限中，看到这些问题中哪些是我们要优先解决的，哪些是可以暂时放一放的，调优时可以借鉴这个顺序来进行。
当然在不同的企业这四个象限中的原因分布是会相互转化的，比如在一个预算有限的私企中可能额外的硬件投资对其来说就是应该放入暂时搁置的象限，而对于财大气粗的单位中可能费用预算不是问题但是想改变他的办事流程和组织架构将是非常困难的，这时解决的优先次序也就要相应调整了。
以上就是我对性能调优方面的一些浅见，在此声明：本人并非技术人员出身，只是在测试管理岗位上多多少少会接触到一些这方面的事情，因此本文尽量避免引述一些很专、很深的技术名词以免贻笑大方，只希望更多的测试人员都能看的明白一些，获取一些对自己有价值的东西罢了。
性能调优之我见（一）
本帖最后由 fatfish 于 2011-11-22 09:42 编辑谈到软件产品的性能调优，我认为可以从狭义和广义两个范围来理解。从狭义的范畴来看，性能调优主要是指通过修改软件程序逻辑、结构等技术手段提升软件产品的各项性能指标，如响应时间等等；而从广义的层面来看，就不仅限于程序内部了，因为造成系统性能问题的瓶颈很可能来源于方方面面，而这种情况往往是性能调优很普遍的情况，下面就从广义的范围细分成几个角度来进行阐述。一）
软件层面a)
首先要谈到的肯定是我们自己提供的软件产品，因为它的内部设计是我们最清楚的，用户在应用时遇到性能问题首先要质疑的也是我们的产品，因此这个层面的调优肯定是我们软件供应者的重中之重！举例来说：比较复杂的业务，通常会在程序中输出一些关键操作的执行时间，然后再分析哪些操作比较耗时，之后再找原因。具体分析原因就比较多了，比如多次循环查询数据库，复杂耗时的SQL语句，频繁的远程调用，复杂算法，等等。
b)
数据库层面：设计数据库时应考虑到在少访问和简化、优化访问的前提下实现产品功能，多用存储过程代替完整SQL，尽量用连接池使用户和服务的连接实现可复用，尽量不使用游标结构等，对基本表的设计进行优化如第三范式、引入“中间表”的技术思路，控制用户实际数据量的增长；对数据库进行索引优化，避免整表扫描；对数据库的事务处理进行调优（去除不必要的锁、将事务切分成小的粒度、适当降低隔离级别、减少访问热点等）；SQL语句调优（尽量优化那些无意义的、拙劣的、复杂的SQL）等等。这方面主要就是本着一个通过尽可能少的磁盘访问而获得所需要的数据这么一个基本原则。
c)
中间件软件：某些软件产品为数据库、中间件、客户端的三层架构设计，此时为系统运行提供服务的中间件软件也将成为制约性能的一个瓶颈。因此在这个层面上也是有很大调优空间的，比如各种相关参数的设置优化，使用性能包、性能监控分析工具等，避免竞争线程资源，批处理，堆大小的设置，为溢出条件设置执行队列，后备缓冲，减少非重要应用的资源占用，使用集群等。举个简单的实例，我曾经遇到一个产品的性能问题，当查询数据大到一定程度时，系统一直灰屏死机状态，结果只是通过把JVM内存参数设置从默认值的128调为256就轻松解决了，只是参数值的一个小变动，反映到具体的用户面前就是出的来和出不来数据的本质差别！
d)
操作系统：无论是服务器还是用户终端，都脱离不了操作系统这个基础的应用平台的支持，因此这个层面的性能调优工作也千万不能遗漏。例如同厂商的不同版本(如WINDOWS各系列)、不同厂商（MS/HP/SUN等）不同的操作系统（WINDOWS/LINUX/UNIX等），这些操作系统的性能表现本身就有所差异，如内存的分配、虚拟内存的处理、数据的读写交换、兼容稳定抗压性等等方面，利用相应的调优方法和工具，可以对此环节进行优化。
二）
硬件层面a)
CPU：中央处理器，决定数据处理速度的核心部件，与性能表现的相关度可想而知，硬件方面具体调优方法及工具本文中不再赘述，下同！
b)
内存、缓存：数据交换的临时存储空间，它的大小形象的说就像是火车站候车室的面积，与性能的关系可想而知。比如有些程序设计的操作对内存回收设计有漏洞，导致频繁操作时内存泄漏越来越多，系统就会越来越慢。
c)
硬盘、I/O：数据存储、调用的载体，如果存储器像候车室，那这些就像是车箱的大小与节数等。
d)
网络：如果还是用坐火车为例，网络的差别就像是普通、快速、动车、磁浮等各种等级的差别，如果一个“系统”频繁需要通过火运完成，那它的性能表现和网络的相关性就不言而喻了。比如某些软件功能设计时没有考虑网络流量方面的风险，导致每次操作时网络连接次数很多，频繁调用或是数据包过大，这些都会导致在一定网络条件下产生性能问题。
e)
显卡等特殊硬件：不同软件产品应用的业务可能用到不同的专用硬件或外设，比如一个很炫的游戏对显卡的要求就会很高，当显示成为短板时死机、跳帧等异常；一个收款台的扫描、信用卡POS机如果质量或兼容性、稳定性不佳时，也可能会造成性能表现的不理想，等待诸如此类问题。
三）
业务层面a)
业务流程重组：项目甲方在购买软件产品或系统服务前，一般会找相关专家、售前人员作一些相关的评估或“体检”，找出现有运作模式下的一些存在优化空间的错误环节或繁冗流程、制度体系等。因此在这个阶段是否对项目应用方作了足够的优化，也对未来产品上线后的应用性能表现在宏观上起着决定作用。取例来说：如果一个系统设计前没有作过这方面的优化，最后应用时需要100人操作10个步骤才能完成，通过流程重组后，从业务上只需要40个人干5个步骤就搞定了，那么没上软件前我们就能从理论上把性能表现优化80%！
b)
需求定位：与上一条阐述的类似，只是介入的阶段和角色有所区别。需求人员有时是从项目乙方发起的，主动地、有策略性的去选择一些有代表性的单位去调研软件产品的概要或详细需求，为后续的产品开发设计提供依据。在这一阶段是否有效的考虑了未来产品的性能表现，对其提出相关的设计目标，也对后续的性能表现有一定的影响。
c)
实施方案：一般当大型一些的项目合同签订完毕后，就会分期安排实施人员负现场牵头并组织双方成立实施小组团队，共同制订系统的上线、操作培训、应用方案等，并执行方案直至系统正常上线运行，项目交付。因此，这个方案制定的是否精简、高效，也直接关系了用户应用系统的性能表现。
谈到软件产品的性能调优，我认为可以从狭义和广义两个范围来理解。从狭义的范畴来看，性能调优主要是指通 ...
fatfish 发表于 2011-11-21 22:10 http://bbs.51testing.com/images/common/back.gif
不错，原来下载过这样的PPT，感悟很多，一直不是知道是谁做的，原来是你，多谢！ 不错，原来下载过这样的PPT，感悟很多，一直不是知道是谁做的，原来是你，多谢！
zhyb_2008 发表于 2011-11-22 09:42 http://bbs.51testing.com/images/common/back.gif
不太可能吧，这个。。。这个真的是我昨天刚刚自己写的呀！ 不太可能吧，这个。。。这个真的是我昨天刚刚自己写的呀！
fatfish 发表于 2011-11-22 09:43 http://bbs.51testing.com/images/common/back.gif
我看那个可执行，影响度的这个图 真的很熟，我应该之前看过的。 我看那个可执行，影响度的这个图 真的很熟，我应该之前看过的。
zhyb_2008 发表于 2011-11-22 11:17 http://bbs.51testing.com/images/common/back.gif
那个鱼骨图和矩阵分析法是一种通用的分析问题的方法，不仅限于分析这个问题，你遇到比较纠结的问题时，都可以用来帮你理理思路的，这只是该分析方法的一部分，后面还要进行相关风险分析、落实具体的解决方案和行动计划等等，与本话题有点远，这里就写写入手点，点到为止就可以了。 写的好 回复 22# fatfish
挺齐全的，但是还是要看具体项目 学习~~~ 性能的灌输应该是自顶向下的，从领导层面，从开发阶段就树立性能的观念。进入性能调优阶段说明已经在测试过程中发现了问题，这就需要自底向上的探索问题，从硬件、网络、操作系统、数据库、中间件、被测程序逐步排查，当然要首先保证你的测试策略是正确的，一般包括铺底数据量是否足够，被测程序版本是否正确，参数化的数量和离散度是否足够，测试场景是否真实、典型，测试脚本是否正确等。
问题排查过程中需要涉及的知识很多，通常中间件，数据库和被测程序代码的问题最多。我所在的公司里测试环境和生产环境差异很大，因此我们只能从软件角度尽量发现潜在的性能问题。
中间件的配置参数很重要，在测试前要首先检查，根据测试环境的配置做相应调整。数据库的参数也需要关注，但一般程序SQL的问题更多，这需要测试人员掌握一定的SQL调优能力，通过工具可以看到消耗大的SQL，分析语句的业务背景，检查执行计划，给出优化建议。程序代码问题也会反映到应用服务器的资源消耗过大，中间件log中频繁报错，不同的被测程序有不同的监控工具，这块目前我了解的还不够，只能写这么多。 一是了解业务系统的性能需求，掌握系统侧重的性能目标和面向客户的性能需求。重点了解访问量大的模块、系统的高峰时刻。
二是在需求的基础上，利用相关的工具侦测系统的性能，如测试系统的并发用户数，页面的响应时间，监控数据库和应用程序服务器的运行情况。
三对性能测试的结果进行分析，结合需求有所针对进行调优，借助工具的分析具体页面元素的性能情况，细化问题，如是否因为页面上的图片、从数据库读取记录时间过长、浏览器服务器缓存过大进行代码和空间的优化。 B/S架构：
1.前段分析，如发现一个页面非常慢，先分析网络原因，再分析网页中是那些元素占用时间较长，对其 ...
mick 发表于 2011-11-14 13:23 http://bbs.51testing.com/images/common/back.gif
这个很不错，自己就是从事b/s这一块的，说得这几点基本上都用过 占个位置。空 了来回复。 看起来这次的话题大家都很感兴趣嘛！希望各位踊跃参与进来。 经验不足，来学习的。吞噬星空
凡人修仙传
猎国
仙逆
医道官途
永生
吞噬星空
唐寅在异界 遮天
唯我独尊
驻马太行侧 全职高手
战天
唯我巅峰
偷天
曹贼
黄金瞳
易鼎
赘婿
锦衣夜行
超级医生
全球论剑
武动乾坤
通天之路
焚天
闪电匹格
将夜
不眠高手
傲世九重天
官气
魔师
重生之百将图修真界败类 蜀山旁门之祖 裁决
斩仙
最终进化
不朽神王
最终信仰
神印王座 关注.... 刚刚入门，接触功能测试都没多少，性能测试还很遥远。看得似懂非懂，不过，谢谢高手解答。 刚刚入门，接触功能测试都没多少，性能测试还很遥远。看得似懂非懂，不过，谢谢高手解答。 学习中。
