性能测试知多少---性能分析与调优的原理

  最近一直纠结性能分析与调优如何下手,先从硬件开始,还是先从代码或数据库。从操作系统(CPU调度,内存管理,进程调度,磁盘I/O)、网络、协议(HTTP, TCP/IP ),还是从应用程序代码,数据库调优,中间件配置等方面入手。

  单一个中间件又分web中间件(apache 、IIS),应用中间件(tomcat 、weblogic 、webSphere )等,虽然都是中间件,每一样拎出来往深了学都不是一朝一夕之功。但调优对于每一项的要求又不仅仅是“知道”或“会使用”这么简单。起码要达到“如何更好的使用”。

  常看到性能测试书中说,性能测试不单单是性能测试工程师一个人的事儿。需要DBA 、开发人员、运维人员的配合完成。但是在不少情况下性能测试是由性能测试人员独立完成的,退一步就算由其它人员的协助,了解系统架构的的各个模块对于自身的提高也有很大帮助,同进也更能得到别人的尊重。

 

  再说性能调优之前,我们有必要再提一下进行测试的目的,或者我们进行性能测试的初衷是什么?

能力验证:验证某系统在一定条件具有什么样的能力。

能力规划:如何使系统达到我们要求的性能能力。

应用程序诊断:比如内存泄漏,通过功能测试很难发现,但通过性能测试却很容易发现。

性能调优:满足用户需求,进一步进行系统分析找出瓶颈,优化瓶颈,提高系统整体性能。

 

 

 

一般系统的瓶颈                                                                                          

 

性能测试调优需要先发现瓶颈,那么系统一般会存在哪些瓶颈:

硬件上的性能瓶颈

一般指的是CPU、内存、磁盘I/O 方面的问题,分为服务器硬件瓶颈、网络瓶颈(对局域网可以不考虑)、服务器操作系统瓶颈(参数配置)、中间件瓶颈(参数配置、数据库、web服务器等)、应用瓶颈(SQL 语句、数据库设计、业务逻辑、算法等)。

 

应用软件上的性能瓶颈

一般指的是应用服务器、web 服务器等应用软件,还包括数据库系统。

例如:中间件weblogic 平台上配置的JDBC连接池的参数设置不合理,造成的瓶颈。

 

应用程序上的性能瓶颈

一般指的是开发人员新开发出来的应用程序。

例如,程序架构规划不合理,程序本身设计有问题(串行处理、请求的处理线程不够),造成系统在大量用户方位时性能低下而造成的瓶颈。

 

操作系统上的性能瓶颈

一般指的是windows、UNIX、Linux等操作系统。

例如,在进行性能测试,出现物理内存不足时,虚拟内存设置也不合理,虚拟内存的交换效率就会大大降低,从而导致行为的响应时间大大增加,这时认为操作系统上出现性能瓶颈。

 

网络设备上的性能瓶颈

一般指的是防火墙、动态负载均衡器、交换机等设备。

例如,在动态负载均衡器上设置了动态分发负载的机制,当发现某个应用服务器上的硬件资源已经到达极限时,动态负载均衡器将后续的交易请求发送到其他负载较轻的应用服务器上。在测试时发现,动态负载均衡器没有起到相应的作用,这时可以认为网络瓶颈。

 

  性能测试出现的原因及其定位十分复杂,这里只是简单介绍常见的几种瓶颈类型和特征,而性能测试所需要做的就是根据各种情况因素综合考虑,然后协助开发人员\DBA\运维人员一起定位性能瓶颈。

 

 

一般性能调优步骤                                                                                      

 

一般性能问题调优的步骤:

步骤一:确定问题

应用程序代码:在通常情况下,很多程序的性能问题都是写出来的,因此对于发现瓶颈的模块,应该首先检查一下代码。

数据库配置:经常引起整个系统运行缓慢,一些诸如oracle 的大型数据库都是需要DBA进行正确的参数调整才能投产的。

操作系统配置:不合理就可能引起系统瓶颈。

硬件设置:硬盘速度、内存大小等都是容易引起瓶颈的原因,因此这些都是分析的重点。

网络:网络负载过重导致网络冲突和网络延迟。

 

步骤二:确定问题

  当确定了问题之后,我们要明确这个问题影响的是响应时间吞吐量,还是其他问题?是多数用户还是少数用户遇到了问题?如果是少数用户,这几个用户与其它用户的操作有什么不用?系统资源监控的结果是否正常?CPU的使用是否到达极限?I/O 情况如何?问题是否集中在某一类模块中? 是客户端还是服务器出现问题? 系统硬件配置是否够用?实际负载是否超过了系统的负载能力? 是否未对系统进行优化?

通过这些分析及一些与系统相关的问题,可以对系统瓶颈有更深入的了解,进而分析出真正的原因。

 

步骤三: 确定调整目标和解决方案

得高系统吞吐理,缩短响应时间,更好地支持并发。

 

步骤四:测试解决方案

对通过解决方案调优后的系统进行基准测试。(基准测试是指通过设计科学的测试方法、测试工具和测试系统,实现对一类测试对象的某项性能指标进行定量的和可对比的测试)

 

步骤五:分析调优结果

系统调优是否达到或者超出了预定目标?系统是整体性能得到了改善,还是以系统某部分性能来解决其他问题。调优是否可以结束了。

  最后,如果达到了预期目标,调优工作就基本可以结束了。

 

下面算是一个技巧,如面试官问到一个性能问题假设,我不知道性能问题出在哪儿时,可以按照这个思路回答^_^

   • 查找瓶颈时按以下顺序,由易到难。
    服务器硬件瓶颈---〉网络瓶颈(对局域网,可以不考虑)---〉服务器操作系统瓶颈(参数配置)---〉中间件瓶颈(参数配置,数据库,web服务器等)---〉应用瓶颈(SQL语句、数据库设计、业务逻辑、算法等)
    注:以上过程并不是每个分析中都需要的,要根据测试目的和要求来确定分析的深度。对一些要求低的,我们分析到应用系统在将来大的负载压力(并发用户数、数据量)下,系统的硬件瓶颈在哪儿就够了。
    • 分段排除法 很有效

 

 

性能测试调优应该注意的要点:

  • 要点1: 在应用系统的设计开发过程中,应始终把性能放在考虑的范围内。
  • 要点2: 确定清晰明确的性能目标是关键。
  • 要点3: 必须保证调优后的程序运行正确。
  • 要点4: 系统的性能更大程度上取决于良好的设计,调优技巧只是一个辅助手段。
  • 要点5: 调优过程是迭代渐进的过程,每一次调优的结果都要反馈到后续的代码开发中去。
  • 要点6: 性能调优不能以牺牲代码的可读性和可维护性为代码。

 



 

 

  本文只介绍了一些性能调优的要关注的东西以及性能调优的一般要点。并没有具体说如何对系统的每个部件进行调优,如何要细说也不是一两书能说清的,对知识面的要求也非常高,是我目前的能力无法触摸的。

 

这里做个总结

  《性能测试知多少》系列基本完结,虽然时间拉得比较长,但我没有把它给太监。虽然内容都在空谈性能测试理论知识,但我认为这些东西对于你从事性能测试工作必不可少。当然,我在“ jmeter基础 ” 与“ loadrunner 技巧 ” 中讲解两个性能测试工具的使用。

  如果我的这些文章对于想了解和学习性能的同学带来一丝的帮助,我将非常开心。我不是高手,只是和你一起热爱测试技术的初学者,只是比较喜欢总结;也时常为前途迷茫,但我知道只要断去学习,路就在前方。我后面会整理性能调优的相关文章。

性能测试所有文章汇总:http://www.cnblogs.com/fnng/archive/2012/08/17/2644878.html 

 

时间: 2024-11-02 17:02:26

性能测试知多少---性能分析与调优的原理的相关文章

性能测试知多少---性能测试计划

上一章节中我们对性能的需求进行了分析,知道了测试对象,了解了测试需求,那么下面就需要制定一份详细的计划,来规划和指导性能测试工作的进行.为了使你对性能测试计划更清晰明白,这里以测试计划的格式来描述.   一.简介   简介部分就不用过多描述了,无非项目的背景,进行此次性能测试的原因,以及性能测试覆盖的范围等等,几乎所有项目文档都在开端对项目进行简单的阐述.   二.性能测试需求   寻找的被测试对象和压力点 要测试的对象不是凭空想象出来,而是经过分析与系统数据收集得到.下取几个典型的压力点 登录

对话马丁·福勒(Martin Fowler)——第六部分:性能与过程调优

第一部分:重构第二部分:设计原则与代码所有权第三部分:进化型设计第四部分:灵活性与复杂性第五部分:测试驱动开发第六部分:性能与过程调优 可维护性与效率 比尔:我在丹佛机场的红地毯俱乐部(Red Carpet Club)[1]中常常碰到名人.今年夏天我碰到了 Calista Flockhart (卡莉斯塔·弗洛克哈特)[2], 而去年我碰到了你.我是个追星族,但是由于害怕哈里森·福特,没敢跟 Calista 搭讪.不过,你和我倒是坐下来喝了杯啤酒.记得当时你曾对我说过,应该以程序员能读懂的字符格式

Hadoop虚拟化的性能对比和调优经验

虚拟化为Hadoop注入了前所未有的活力,从IT生产管理的角度,表现为以下几点: ·Hadoop和其他消耗不同类型资源的应用一起部署共享数据中心可以提高总体资源利用率: ·灵活的虚拟机操作使得用户可以动态的根据数据中心资源创建.扩展自己的Hadoop集群,也可以缩小当前集群.释放资源支持其他应用如果需要: ·通过与虚拟化架构提供的HA.FT集成,避免了传统Hadoop集群中的单点失败,再加之Hadoop本身的数据可靠性,为企业大数据应用提供了可靠保证. 基于这些原因,vSphere Big Da

快速定位隐蔽的sql性能问题及调优

在前几天,有个开发同事问我一个问题,其实也算是技术救援,他说在有个job数据处理的频率比较高,在测试环境中很难定位出在哪有问题,而且速度也还能接受,但是在生产环境中总是会慢一些,希望我能在测试环境中协助他们,看看是不是sql语句出什么问题了还是其它相关的问题. 这种类似实时监控的语句,从第一印象来说,很可能通过awr捕获不到,如果通过ash来捕获,因为测试环境中有几十套测试环境在运行,就算得到某个时间点的一些sql语句,直接在报告中映射到语句对应的schema信息还是有一些困难的.因为测试时间确

图表分析系统调优全面性的必要

继昨天对系统进行了初步的调优后,效果还是比较显著,DB time从500%降到了100%以内,当然过程还是充满艰辛,期间也是各种工具和分析语句斟酌了再三. 今天也没有收到任何报警,所以感觉问题似乎已经彻底解决了.在下午的时候查看了一下,发现在凌晨的时候有一个大的抖动,然后DB time基本持续在300%~400%左右.比预期的要高很多. 这个时候的第一感觉就是是不是调优出问题了,性能还是不够稳定啊,带着疑问查看了今天的数据归档情况,发现在这段时间内的数据归档频率还是很高的.在短短几个小时之内就会

性能测试知多少---性能需求分析

需求分析是个繁杂过程,它并非我们想象的那么简单,而性能测试需求除了要对系统的业务非常了解,还需要有深厚性能测试知识.才能够挖掘分析出真正的性能需求.   如何获得有效的需求   1.客户方提出 客户方能提出明确的性能需求,说明对方很重视性能测试,这样的企业一般是金融.电信.银行.医疗器械等:他们一般对系统的性能要求非常高,对性能也非常了解.提出需求也比较明确. 曾经有一个银行项目,已经到最后的性能测试极端,因为数据库设计不合理,导致性能出现很大的问题,最终不得不把整合项目 作废,对于这样的项目,

使用TPTP对Eclipse插件进行性能剖析和调优

TPTP 及其各子项目简介 TPTP(Eclipse Test & Performance Tools Platform) 是 Eclipse 基金 会下的一个开源子项目,提供了一组基于 Eclipse 的工具,对软件开发的各个 阶段提供支持.基本已经覆盖了从测试到运行时性能分析.运行状态.日志分析 的全过程.从其项目首页来看,其主要开发者来自包括 IBM 和 Intel 在内的大 公司.更重要的是,由于其开放性,使得基于其上来开发自己的工具变得非常容 易,这样一来就极大地降低了开发 "

mysql性能的检查和调优方法

我一直是使用mysql这个数据库软件,它工作比较稳定,效率也很高.在遇到严重性能问题时,一般都有这么几种可能: 1.索引没有建好; 2.sql写法过于复杂; 3.配置错误; 4.机器实在负荷不了; 1.索引没有建好 如果看到mysql消耗的cpu很大,可以用mysql的client工具来检查. 在linux下执行 /usr/local/mysql/bin/mysql -hlocalhost -uroot -p 输入密码,如果没有密码,则不用-p参数就可以进到客户端界面中. 看看当前的运行情况 s

mysql 性能的检查和调优方法_Mysql

在遇到严重性能问题时,一般都有这么几种可能:1.索引没有建好; 2.sql写法过于复杂; 3.配置错误; 4.机器实在负荷不了; 1.索引没有建好 如果看到mysql消耗的cpu很大,可以用mysql的client工具来检查. 在linux下执行 /usr/local/mysql/bin/mysql -hlocalhost -uroot -p 输入密码,如果没有密码,则不用-p参数就可以进到客户端界面中. 看看当前的运行情况 show full processlist 可以多运行几次 这个命令可