性能测试分析及调优原理

    技术2022-07-10  75

    性能测试的目的就评估当前系统性能的指标,分析定位解决性能瓶颈,预防规避性能风险。

    性能分析是为了确定导致性能瓶颈的原因,而调优就是用来解决性能瓶颈。

    通过某些手段让系统性能得到提高,是性能调优的主要目的。

    性能分析主要有两种方法:

    1.将测试结果与用户需求做比较,如果达到用户需求,则测试通过。

    *系统满足10万注册用户(其中1万为活跃用户)的访问

    *系统处理能力,20个注册/秒,45个并发浏览/秒,35个登录操作/秒。

    *服务器资源利用率在满负荷的情况下,忙时峰值cpu负载不超过75%,内存占用不超过80%。

    例如:需要赛前对一个要参加100米跑的选手进行性能测试,为了确保冠军,那么首先就要明确,第一名所需要达到的指标。(100米跑的总时间),对其进行性能测试,当发现测试结果能够达到冠军指标后,性能测试即结束。

    2.最优化分析法

    通过分析并消除系统性能瓶颈,使系统的处理能力达到最大化,系统资源得到充分利用。

    性能调优也分为两种方法

    1.应用程序诊断

    应用程序诊断是性能测试的最初目的。通过模拟多用户操作形成负载。检验应用程序是否能够满足用户性能需求。

    如果不满足,则定位应用瓶颈,并寻找解决该瓶颈的方案。确保系统在修正后能够满足用户需求。对于一个项目来说,一般以应用诊断为主。

     2。性能调优

    在性能调优中,最基本的目标是满足用户,而进一步的目标是超越自己,此时要做的就是要让系统比以前更加优秀的运行,通过生成负载,对测试结果进行分析,并且准备大量的软硬件环境进行迭代测试,找出影响性能的要素,最终提升性能。

    一般产品都用采用系统调优的方式来逐步完善系统性能。

    常见的性能瓶颈有如下一些情况:

    1)硬件上的瓶颈

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

    例如:确定了在服务器数据库上需要6个CPU、12GB内存,但是在测试时发现,CPU的持续利用率超过95%,这时可以认为在硬件上出现了性能瓶颈。

    2)应用软件上的瓶颈

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

    例如:在weblogic平台上配置了JDBC连接池的参数,最大连接数为50,最小连接数为5,增加量为10。测试时发现,当负载增加时,现有的连接数不足,系统会动态生成10个新的连接,导致交易处理的响应时间大大增加。这时可以认为在应用软件上出现了性能瓶颈。

    3)应用程序上的性能瓶颈

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

    例如:程序员开发了一个缴费处理程序,在测试时发现,这个缴费处理程序在处理用户并发缴费请求时,只能串行处理,无法并行处理,导致缴费处理响应时间非常长,这个可以认为在应用程序上出现了性能瓶颈。

    4)操作系统上的性能瓶颈

    一般指的是LInux windows unix等操作系统

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

    5)网络设备上的性能瓶颈

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

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

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

     

    一般性能调优的步骤:

    1.确定问题

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

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

    才能投产的。

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

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

    *网络:网络负载过重会引起网络冲突和网络延迟。

    确定原因:

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

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

    3.确定调整目标和解决方案

    提高系统吞吐量,缩短响应时间,更好的支持并发。

    4.测试解决方案

    对通过解决方案调优后的系统进行基准测试。

    5.分析调优结果

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

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

    例如:在数据库查询中经常出现查询响应时间较长的问题,解决这种SQL查询响应时间长的问题通常以使用索引来解决问题。

    什么是索引?

    比如,你有很多的小抽屉,每个抽屉内都有一些杂物,假如你要找东西,最原始的方法就是一个抽屉一个抽屉的翻,这就是没有索引的情况。

    聪明一点,给每个抽屉一个编号(唯一键),把哪个号码有什么东西都记录在纸上。找东西先看看这张纸,这就是普通索引。加入你要知道哪个抽屉有什么,你可以在纸上迅速的找到抽屉号码,(大家都知道这种使用查找树),

    然后得到相关的信息。这种情况普通索引是很快的。但是要找到特定的东西哪些抽屉有,就需要将整张纸遍历一遍,这就是LIKE查询。假如你要找哪些抽屉同时有两种甚至更多种东西,LIKE就更加繁琐了。假如一个表有上千万的记录,大家可以想象查询的代价。

    在索引中又分为聚集索引和非聚集索引两种模式。

    聚集索引:

    表中存储的数据按照索引的顺序存储,检索效率比普通索引高,索引占用硬盘存储空间小(1%左右),但对数据的新增/修改/删除的速度影响比较大。

    如下:

    *无索引,数据无序

    *有索引,数据与索引同序

    *数据会根据索引的顺序重新排列数据。

    *一个表只能有一个索引。

    *叶节点指针指向的数据也在同一位置储存。

    TSQL语法:

    create CLUSTERED INDEX idxempID ON emp(empID)

    2)非聚集索引

    不影响表中的数据存储顺序,检索效率比聚集索引低,索引占用硬盘存储空间大(30%~40%),对数据新增/修改/删除的影响很少。特点如下:

    *一个表可以最多创建249个非聚集索引。

    *先建聚集索引才能创建非聚集索引

    *非聚集索引数据与索引不同序

    *数据与非聚集索引在不同位置

    *非聚集索引在叶节点上存储,在叶节点上有一个‘指针’直接指向要查询的数据区域。

    *数据不会根据非聚集索引键的顺序重新排列数据。

    TSQL语法:create NONCLUSTERED INDEX idximpID ON emp(empID)

    对于索引有一些错误的观点,具体如下:

    *主键就是聚集索引

    *只要建立索引就能显著提高查询速度

    *把所有需要提高查询速度的字段都加进聚集索引,以提高查询速度。

     

    一般来说以下规则是正确的:

    *用聚集索引比引用非聚集索引的主键速度快

    *用聚集索引比用一般的主键做order by时速度快,特别是在小数据量情况下。

    *使用聚集索引内的时间段,搜索时间会按数据占整个数据表的百分比成比例减少,而无论聚集索引使用了多少个

    *‘水可载舟,亦可覆舟’,索引也一样,不要过度使用索引。

     

    对于SQL语句优化的额基本原则如下。

    *使用索引更快地遍历表。默认情况下建立的索引是非聚集索引,但有时它并不是最佳的。在非聚集索引下,数据在物理机上随机存放在数据页上。合理的索引设计要建立在对个汇总查询的分析和预测上,一般来说:

    》有大量重复值且经常有范围查询(between,>,<,>=,<=)和order by、group by 发生的列,可考虑建立聚集索引。

    》经常同时存取多列,且每列都要包含有重复值可考虑建立组合索引

    》组合索引要尽量使用关键查询形成索引覆盖,其前导列一定是使用最频繁的列。

    * IS NULL 与IS NOT NULL 不能用NULL作为索引,任何包含NULL值得列都将不会被包含在索引中。

     

     

    Processed: 0.038, SQL: 9