51Testing软件测试论坛

标题: 性能调优从哪些方面入手？（2011-12-15）（获奖名单已经公布） [打印本页]

作者: lsekfe 时间: 2011-11-14 10:04
标题: 性能调优从哪些方面入手？（2011-12-15）（获奖名单已经公布）
本周的问题为“性能调优从哪些方面入手”？期望各位能踊跃的参加有丰厚的奖品等着各位哦！

如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	fatfish	中国移动手机充值卡50元	23#
二等奖	yzylion	300论坛积分	9#

作者: 真实的追求者 时间: 2011-11-14 11:21
沙发

作者: kasumi 时间: 2011-11-14 11:27
1、页面响应时间2、每秒的点击量3、资源的消耗率

一般都是从这三个方面着手的吧
我之前进行性能测试是从这三个方面着手的

作者: wangyanzhao 时间: 2011-11-14 12:25
1 前端分析
2 后台分析
3 网络分析

作者: mick 时间: 2011-11-14 13:23
B/S架构：
1.前段分析，如发现一个页面非常慢，先分析网络原因，再分析网页中是那些元素占用时间较长，对其进行调优；
2.后端分析，如应用程序和数据库服务器的硬件分析，CPU，内存，磁盘IO等，这是比较好调优的地方；
3.应用程序服务器调优，如IIS，Tomcat，Apache等，这里的调优不是去修改程序，而是选择最合适自己的服务器；数据库选择也一样；
4.程序的调优，如SQL语句、存储过程的效率，程序执行过程中释放内存等，这些我也不太懂，希望广大同仁多多解答。
C/S架构：
由于C/S架构的很多往往不是Http协议，如果是Http协议的，那调优方法和B/S架构的相类似，如果不是Http协议的，前段分析就不太好调优，这点也希望大家给我解答一下，此外B/S调优的2,3,4也符合C/S

作者: futogether 时间: 2011-11-14 16:40

B/S架构：
1.前段分析，如发现一个页面非常慢，先分析网络原因，再分析网页中是那些元素占用时间较长，对其 ...
mick 发表于 2011-11-14 13:23

补充web应用：
1、CSS和JavaScript：不规范的CSS 会对页面效率有严重影响，这个往往会被忽略。如果JavaScript 性能不足，就会造成浏览器负荷过重。
2、网络传输：如：有些代码程序是在服务器端而不需要被传输的，而有些代码是要用Javascript 实现并在Browser 端执行的，后者会牵涉到更多http请求，可能大大增加网络传输时间。再如：我们会用SSL 协议进行传输，但是在传输时，没有考虑是不是整个网页文件都要用SSL来传输，比如图片文件就可以不用SSL，从而减少传输负载。

作者: henry_yan 时间: 2011-11-14 17:09
1.首先要了解性能调优，一般是当用户抱怨“太慢了”、“性能不足”、“软硬件需要升级
了”等问题时，提供较佳的性能。但不是要解决用户所说的“这系统毁了”、“它不会工作了”等问题，这可能需要的是备援回滚、提高系统可获得性（HA high Availability）等解决方案。但就数据库系统而言，规划高可获得性的架构（如SQL Cluster、Mirroring、Log Shipping、Replication等）不会提升系统性能，还要注意是否降低了性能。
2.要看现象，而一般观测性能问题的现象有：　　 系统响应速度太慢。　　 每秒所完成的系统输出/入低于预期。　　 相同的环境，但每秒钟所完成的批操作较先前少。　　 系统资源（如CPU、内存、硬盘或网络等）长时间处于耗尽的状态。　　通常调校的目标是以用户的期望为依据，除非你的数学与信息基本功非常扎实，否则很难知道调校的极限在哪。因此，我们的目标往往是符合用户的期盼即可
3.调校性能的第一个工作应该是建立性能的基线（baseline），所需的类型有：1）昔日系统正常运行时的数据。 2）调校前系统的各种数据。3） 用户希望达到的目标。系统响应比较慢，要知道正常是多少、慢了多少、时间差是多少、数据量多少、多少人同时上线、处理量多少等。也就是要有基线，有客观的数据，这才有好的调校基础。
4.要考虑支出，性能调校代表着成本（cost）的支出，成本可能是实质的钱，也可能是工程师的时间与精力，用户的忍耐等待。在理想状况下，是把系统中最贵的部分发挥到极限，能够以最低的成本来发挥系统最大的性能。若是自己开发的程序，这往往代表着硬件采购是系统开发中最贵的部分，因此，会采取重新设计系统的解决方式，如数据库逻辑使用方式重新切割、查询方式大量重载、以消耗内存的方式减少对硬盘的访问等。你可能要花掉数个工程师个把月的时间，才得以将架构重新规划，程序全面重载，或许花费如此的人力成本还不如直接更新设备，但性能调校的总体成本（total cost）并不容易计算。
5.要有目标，这些落于纸上的目标应越明确越好，若目标是 “我想要调低内存的使用率，因为它的值太高了”就不如“我想要调低某个程序开始获取内存的设置，因为它可能吃掉太多的内存，但实际没有用到这么多，而其他的应用程序没有足够的内存，导致整体系统性能不佳”。后者的描述有目标，且可以比较，因为实际调整后可以观察调低内存的程序执行起来是否有问题，整体的性能与没调整前是否有差异。
上述只是性能调优的概括做法，对于具体的性能调优，例如B/S结构或者数据库调优，都有各自的特点，还有从各自的需求出发，有针对性的性能调优。

作者: 黄袖标 时间: 2011-11-15 09:55
学习了

作者: yzylion 时间: 2011-11-16 18:44
看了各位对于性能调优的观点，受益不少啊，我谈谈我个人的一些见解，权当拍砖引玉
我个人觉得现在大多数的性能测试工作人员分为以下三个阶段：
1、出了问题就看资源，资源占用如果很高，报以窃喜的心态，恩，发现了，原理是资源瓶颈
2、资源没有出现瓶颈，通过一些技术手段分析，发现是组件的配置文件有问题，例如：server的并发策略有问题，带宽有问题，找到了线路短板性能中的短板，到了这个阶段在我看来是比较牛的测试拉
3、以上均无问题的情况下，考虑数据结构和算法
就我个人接触到的来说，现在大多数的人员都是在仰望第二阶段，摸索第三阶段，希望从代码级就发现出性能的问题，进行问题的发现和解决，也符合我们的bug越早发现修复的成本越低的理论。同时，也是一名性能测试工程师高薪的象征。
那么谈完了现状，回到我们的这个话题：性能调优从哪些方面入手，个人觉得有如下几点：
1、对于所测系统所设计到的知识领域的了解。例如：所测系统开发语言，牵涉到的中间件，web，app 两大server等的配置参数是什么意思，如何监控，分析它们的哪些数据等
2、注重基础知识的学习和积累。例如：对于web的性能测试，对于TCP/IP原理，基本知识，数据的转发实现，交换机和路由器的带宽设置策略对性能的影响等需要了解，掌握清楚，思路清晰
3、确定性能测试本身的有效。例如：脚本的优化，场景的设置等。因为，有些本身脚本的优化带来的执行效率的问题，往往被我们忽略，而一股脑的在那里研究是我们本身哪里出了问题
性能测试调优是一条说简单简单，要做好不是那么容易的路，共勉～～～

作者: PeterKang 时间: 2011-11-17 10:40

1.首先要了解性能调优，一般是当用户抱怨“太慢了”、“性能不足”、“软硬件需要升级
了”等问题时，提供 ...
henry_yan 发表于 2011-11-14 17:09

4.考虑支出非常有实际意义，如果在不改动代码的情况能提高性能这个成本比较低，所以可以优先考虑

作者: yinjianying1982 时间: 2011-11-17 10:57
好好学习，刚开始接触，多多指教

作者: da乐 时间: 2011-11-17 15:10
这个问题很不错越来越高端了

作者: QqiaoQ 时间: 2011-11-17 16:03
1.3/5/8秒：能在3秒反应过来，说明很好；3-5秒，不错；5-8秒，还行；8秒后很差
2.服务器资源，是否占用率居高不下
3.数据库容量是否不够用
4.事务处理速度是否变慢，优化性能脚本

暂时只想到这么点

作者: msnshow 时间: 2011-11-17 22:10
这个调优主要还是得状况来进行分析

作者: wzc 时间: 2011-11-18 14:30
田口方法，计算最优用例，从而抽取个要素的最优水准，并加以印证。

作者: 愚人 时间: 2011-11-18 23:21
愿听高手详解……

作者: 夏日摸摸茶 时间: 2011-11-19 16:29
经验不多，来学习的飘过~~~

作者: shigejinian1 时间: 2011-11-21 10:40
关注。

作者: jin_002 时间: 2011-11-21 11:14

，性能方面涉及比较少，过来偷师的。

作者: 我在找虫子 时间: 2011-11-21 11:54
偶也是飘过，我觉得大家讲非常好，值得我们学习！

作者: zhyb_2008 时间: 2011-11-21 16:05
理论上也好，实战上也好，好像关于性能调优的文章和方法以及码的字已经很多了，我这儿也没什么新鲜的要去说，也为了很久不回贴，就扯一些没用的吧：
我前一段听百度一哥们讲了几个实战，还是很有感触的，其实也是那些调优的方式方法，主要是看怎么去合理的应用。
如果只回答这个“性能调优从哪些方面入手”，我想首先当然是从性能测试入手，从基于经验和前辈的总结的性能分析入手，先进行理想化的配置也好，设置也好，部署也好。想想也是，如果不测试，我们就不知道，甚至猜都猜不好哪儿可能有问题。
然后，就结合本贴7#，9#两位兄弟的经验，加日常测试的积累，进行调优工作呗。
调优的内容应该包含了这个系统能跑起来所用的所有因素：如:意想不到的配置，OS集成，网络因素，代码因素，存储机制。
具体要做的事，针对不同问题，具体问题具体分析（相当于没说，哈）
再附上百度那哥们讲的一些案例，就像网上的其他案例一样，一些案例虽说比较不太大众化，或者不太容易被模拟，但是启发性很强，可以让大家的思路更开阔，更容易下手。
[attach]76197[/attach]

作者: fatfish 时间: 2011-11-21 21:41
标题: 性能调优之我见（二）
本帖最后由 fatfish 于 2011-11-22 09:41 编辑

四）       意识层面
当今社会万事讲求以人为本，如果从软件应用系统涉及的各级人员角色的内心没有把性能表现当回事，那么一切调优最多也都是亡羊补牢而已。比如：
a)    产品经理：项目乙方产品总负责人，产品目标、市场定位、基本框架的制定者。
b)    一线人员：售前咨询、实施顾问等。
c)       需求设计：对产品具体功能设计提出明确要求的角色。
d)       代码实现：按需求定义进行产品的具体实现的角色。
e)       测试人员：对产品质量进行检测、对开发过程进行监管的角色。
f)       最终用户：系统最终的使用者、应用效果的影响者。

   对于一个软件产品来讲，只有以上这些环节的角色人等在各自的工作岗位上，真正的在意识层面上提高优化系统性能的地位，而不是把它作为功能优先实现之外的附属品，才能把系统性能优化的工作最大程度的作在前面、作的全面、作得到位！

   综上所述，我们看到了各类导致性能瓶颈的可能原因（也可以说是性能调优的入手点），下面我们用一个比较常用的鱼骨图分析法来展示一下，可能会更为清晰：

   然后我们再把这些原因按一定的规则进行分门别类，一般采用如下的二维矩阵分析的方法，按可推行的难易度和收效的影响度高低来形成四个象限，把这些问题按具体情况分布在这四个象限中，看到这些问题中哪些是我们要优先解决的，哪些是可以暂时放一放的，调优时可以借鉴这个顺序来进行。
[attach]76204[/attach]
   当然在不同的企业这四个象限中的原因分布是会相互转化的，比如在一个预算有限的私企中可能额外的硬件投资对其来说就是应该放入暂时搁置的象限，而对于财大气粗的单位中可能费用预算不是问题但是想改变他的办事流程和组织架构将是非常困难的，这时解决的优先次序也就要相应调整了。
[attach]76205[/attach]
   以上就是我对性能调优方面的一些浅见，在此声明：本人并非技术人员出身，只是在测试管理岗位上多多少少会接触到一些这方面的事情，因此本文尽量避免引述一些很专、很深的技术名词以免贻笑大方，只希望更多的测试人员都能看的明白一些，获取一些对自己有价值的东西罢了。

作者: fatfish 时间: 2011-11-21 22:10
标题: 性能调优之我见（一）
本帖最后由 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)
实施方案：一般当大型一些的项目合同签订完毕后，就会分期安排实施人员负现场牵头并组织双方成立实施小组团队，共同制订系统的上线、操作培训、应用方案等，并执行方案直至系统正常上线运行，项目交付。因此，这个方案制定的是否精简、高效，也直接关系了用户应用系统的性能表现。

[attach]76202[/attach]

[attach]76203[/attach]

作者: zhyb_2008 时间: 2011-11-22 09:42

谈到软件产品的性能调优，我认为可以从狭义和广义两个范围来理解。从狭义的范畴来看，性能调优主要是指通 ...
fatfish 发表于 2011-11-21 22:10

不错，原来下载过这样的PPT，感悟很多，一直不是知道是谁做的，原来是你，多谢！

作者: fatfish 时间: 2011-11-22 09:43

不错，原来下载过这样的PPT，感悟很多，一直不是知道是谁做的，原来是你，多谢！
zhyb_2008 发表于 2011-11-22 09:42

不太可能吧，这个。。。这个真的是我昨天刚刚自己写的呀！

作者: zhyb_2008 时间: 2011-11-22 11:17

不太可能吧，这个。。。这个真的是我昨天刚刚自己写的呀！
fatfish 发表于 2011-11-22 09:43

我看那个可执行，影响度的这个图真的很熟，我应该之前看过的。

作者: fatfish 时间: 2011-11-22 13:51

我看那个可执行，影响度的这个图真的很熟，我应该之前看过的。
zhyb_2008 发表于 2011-11-22 11:17

那个鱼骨图和矩阵分析法是一种通用的分析问题的方法，不仅限于分析这个问题，你遇到比较纠结的问题时，都可以用来帮你理理思路的，这只是该分析方法的一部分，后面还要进行相关风险分析、落实具体的解决方案和行动计划等等，与本话题有点远，这里就写写入手点，点到为止就可以了。

作者: 真实的追求者 时间: 2011-11-22 17:55
写的好

作者: wendyjl1314 时间: 2011-11-22 19:59
回复 22# fatfish

挺齐全的，但是还是要看具体项目

作者: yefisher 时间: 2011-11-23 15:09
学习~~~

作者: dionysus 时间: 2011-11-23 16:51
性能的灌输应该是自顶向下的，从领导层面，从开发阶段就树立性能的观念。进入性能调优阶段说明已经在测试过程中发现了问题，这就需要自底向上的探索问题，从硬件、网络、操作系统、数据库、中间件、被测程序逐步排查，当然要首先保证你的测试策略是正确的，一般包括铺底数据量是否足够，被测程序版本是否正确，参数化的数量和离散度是否足够，测试场景是否真实、典型，测试脚本是否正确等。
问题排查过程中需要涉及的知识很多，通常中间件，数据库和被测程序代码的问题最多。我所在的公司里测试环境和生产环境差异很大，因此我们只能从软件角度尽量发现潜在的性能问题。
中间件的配置参数很重要，在测试前要首先检查，根据测试环境的配置做相应调整。数据库的参数也需要关注，但一般程序SQL的问题更多，这需要测试人员掌握一定的SQL调优能力，通过工具可以看到消耗大的SQL，分析语句的业务背景，检查执行计划，给出优化建议。程序代码问题也会反映到应用服务器的资源消耗过大，中间件log中频繁报错，不同的被测程序有不同的监控工具，这块目前我了解的还不够，只能写这么多。

作者: panxi@2011 时间: 2011-11-24 11:47
一是了解业务系统的性能需求，掌握系统侧重的性能目标和面向客户的性能需求。重点了解访问量大的模块、系统的高峰时刻。
二是在需求的基础上，利用相关的工具侦测系统的性能，如测试系统的并发用户数，页面的响应时间，监控数据库和应用程序服务器的运行情况。
三对性能测试的结果进行分析，结合需求有所针对进行调优，借助工具的分析具体页面元素的性能情况，细化问题，如是否因为页面上的图片、从数据库读取记录时间过长、浏览器服务器缓存过大进行代码和空间的优化。

作者: jenery 时间: 2011-11-24 14:13

B/S架构：
1.前段分析，如发现一个页面非常慢，先分析网络原因，再分析网页中是那些元素占用时间较长，对其 ...
mick 发表于 2011-11-14 13:23

这个很不错，自己就是从事b/s这一块的，说得这几点基本上都用过

作者: madwolfer 时间: 2011-11-24 17:28
占个位置。空了来回复。

作者: lsekfe 时间: 2011-11-25 11:01
看起来这次的话题大家都很感兴趣嘛！希望各位踊跃参与进来。

作者: xsjzcom 时间: 2011-11-26 13:12
经验不足，来学习的。吞噬星空
凡人修仙传
猎国
仙逆
医道官途
永生
吞噬星空
唐寅在异界遮天
唯我独尊
驻马太行侧全职高手
战天
唯我巅峰
偷天
曹贼
黄金瞳
易鼎
赘婿
锦衣夜行
超级医生
全球论剑
武动乾坤
通天之路
焚天
闪电匹格
将夜
不眠高手
傲世九重天
官气
魔师
重生之百将图修真界败类蜀山旁门之祖裁决
斩仙
最终进化
不朽神王
最终信仰
神印王座

作者: wu_xlei 时间: 2011-11-26 14:10
关注....

作者: 什么高深莫测 时间: 2011-11-28 18:37
刚刚入门，接触功能测试都没多少，性能测试还很遥远。看得似懂非懂，不过，谢谢高手解答。

作者: sdwangna 时间: 2011-11-29 09:09
学习中。

作者: msnshow 时间: 2011-11-30 13:34
很多因素都可能引起性能问题，主要还是从现像进行分析

作者: 愚人 时间: 2011-11-30 19:53
俺的感觉是无从下手，惭愧……

作者: wangyanzhao 时间: 2011-12-1 12:57
回复 9# yzylion

支持

作者: yzylion 时间: 2011-12-13 23:03
这个结束了吗？！

作者: lsekfe 时间: 2011-12-15 10:52
回复 44# yzylion

刚结束！！

作者: piaolingxue423 时间: 2011-12-15 14:04
很多分析还是很中肯的 22楼的鱼骨图画的不错

作者: xppxyy 时间: 2012-4-17 17:44
学习啊。。。。。。。。。。

作者: tengmy 时间: 2018-3-11 21:00
学习了。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)