文章目录一、性能测试瓶颈分析二、性能调优2.1 调优原则2.2 性能调优的步骤三、性能调优案例3.1 案例1-获取首页数据CPU3.1.1 场景描述3.1.2 测试结果数据3.1.3 问题分析3.1.4 解决方案3.2 案例2-查看商品详情网络3.2.1 场景描述3.2.2 测试结果数据3.2.3 问题分析3.2.4 解决方案3.3 案例3-搜索商品慢查询3.3.1 场景描述3.3.2 测试结果数据3.3.3 问题分析3.3.4 解决方案3.4 案例4-JVM内存溢出3.4.1 场景描述3.4.2 测试结果数据3.4.3 问题分析3.4.4 解决方案一、性能测试瓶颈分析在实际的性能测试中 会遇到各种各样的问题 比如TPS压不上去 导致这种现象的原因很多 作为测试人员应配合开发人员进行分析尽快找出瓶颈的所在。常见性能瓶颈分析1、服务器资源分析CPU瓶颈分析CPU已压满接近100%需要再看其他指标的拐点出现的时刻是否与CPU压满的时刻基本一致内存瓶颈分析内存不足时操作系统会使用虚拟内存从虚拟内存读取数据影响处理速度磁盘I/O瓶颈分析磁盘I/O成为瓶颈时会出现磁盘I/O繁忙导致交易执行时在I/O处等待网络带宽如果接口传递的数据包过大超过了带宽的传输能力就会造成网络资源竞争导致TPS上不去2、JVM瓶颈分析内存泄漏内存不释放内存溢出内存不够用3、数据库瓶颈分析慢查询数据库的连接池设置太小 导致数据库连接出现排队数据库出现死锁4、程序内部实现机制5、压测机JMeter单机负载能力有限 如果需要模拟的用户请求数超过其负载极限 也会导致TPS压不上去二、性能调优2.1 调优原则按照由难到易的顺序1.硬件资源CPU、内存、磁盘2.网络资源3.中间件应用服务器、数据库配置4.源代码、数据库脚本5.系统架构设计2.2 性能调优的步骤确定问题 根据性能监控的数据和性能分析的结果 确定性能存在的问题要求确定原因 确定问题后 对问题进行分析 找出问题的原因确定调整目标和解决方案改服务器参数配置、增加硬件资源配置、修改代码测试给出的解决方案分析调优的结果注意性能测试调优并不是一次完成的过程针对同一个性能问题上面的五步可能要经过多次循环才能最终完成性能调优的目标即测试发现问题-找原因-调整-验证-分析-再测试。 。 。 三、性能调优案例3.1 案例1-获取首页数据CPU3.1.1 场景描述进入首页后 加载首页的相关数据 包括 轮播图、 频道、 优惠券、 团购专区、 品牌商直供、 新品首发、 热卖商品、 专题精选等数据。3.1.2 测试结果数据3.1.3 问题分析1从目前的测试结果来看性能存在问题并发数达到50时TPS达到52此时虽然响应时间为4.4s小于5s但是数据库服务器的CPU使用率非常高接近100%重点关注数据库。2CPU分为用户CPU和系统CPU综合其他的各项资源指标来分析内存、磁盘IO、网络等指标无任何异常因此此处不是系统CPU占用高主要原因是用户进程占用的CPU高目前CPU占用高的为数据库服务器而数据库服务器主要的任务就是执行SQL语句3数据库服务器CPU高可能的原因SQL执行时间太长SQL语句过多确定SQL执行时间是否过长查看慢查询日志看看是否有超过预期指标的SQL语句并分析排查目前案例经过慢查询日志的分析没有超长时间执行的SQL语句确定是否SQL语句过多查看当前数据库中正在执行的SQL语句及连接池的状态发现大量SQL在等待执行4再结合操作过程中的系统日志进行分析执行进入首页脚本抓取日志 通过日志分析每进入一次商城首页就需要在数据库中执行19条查询的SQL语句3.1.4 解决方案1、CPU高——增加CPU提高服务器配置2、根本上解决问题的方法分析这19条SQL都是在查询什么数据包括轮播图、频道、优惠券、团购专区、品牌商直供、新品首发、热卖商品、专题精选等数据。考虑使用分批次、异步加载的方式展示到什么位置就查询什么位置的数据3.2 案例2-查看商品详情网络3.2.1 场景描述进入商品详情页面时 加载商品的详细信息。3.2.2 测试结果数据3.2.3 问题分析从监控图表可以看出当前的网络流量已经基本将网络带宽占满因此网络存在瓶颈。网络带宽已跑满一次请求中返回了全部数据3.2.4 解决方案提升服务器网络带宽宽带便宜分批次、异步加载商品数据分析进入商品详情时的数据传送内容内容是否有可用精简的内容或者是否可以异步传送 3.3 案例3-搜索商品慢查询3.3.1 场景描述进入首页在搜索框中输入关键字搜索商品3.3.2 测试结果数据搜索关键字“床”时 出现慢查询SQL语句通过日志查看慢查询语句 cat /var/lib/mysql/localhost-slow.logselectid,name,keywords,desc,pid,icon_url,pic_url,level,sort_order,add_time,update_time,deletedfromlitemall_categoryWHERE(idin(1008009,1008009,1008008,1008008,1015000,1015000,1008009,1008009,1008009,1008008,1036000)andlevelL2anddeleted0);3.3.3 问题分析1、性能测试结束后通过慢查询日志查看到执行时间超长的SQL语句[rootlocalhost ~]# tail -f /var/lib/mysql/localhost-slow.log # 实时查看日志文件信息[rootlocalhost ~]# cat /var/lib/mysql/localhost-slow.log # 查看日志文件信息2、结合业务来分析确定每个SQL的作用尤其关注与慢查询的SQL语句相关的那几条SQL-- 1.统计所有名称或关键词包含 “床” 字的在售商品总数用于展示 “找到 11 个相关商品”SELECTcount(0)FROMlitemall_goodsWHERE(keywordsLIKE%床%ANDis_on_sale1ANDdeleted0)OR(nameLIKE%床%ANDis_on_sale1ANDdeleted0);-- 2.分页获取满足条件的商品列表selectid,name,brief,pic_url,is_hot,is_new,counter_price,retail_pricefromlitemall_goodsWHERE(keywordslike%床%andis_on_sale1anddeleted0)or(namelike%床%andis_on_sale1anddeleted0)orderbyadd_timedescLIMIT10;-- 3.查询满足条件的商品分类idselectcategory_idfromlitemall_goodsWHERE(keywordslike%床%andis_on_sale1anddeleted0)or(namelike%床%andis_on_sale1anddeleted0);-- 4.根据商品分类id获取商品分类信息selectid,name,keywords,desc,pid,icon_url,pic_url,level,sort_order,add_time,update_time,deletedfromlitemall_categoryWHERE(idin(1008009,1008009,1008008,1008008,1015000,1015000,1008009,1008009,1008009,1008008,1036000)andlevelL2anddeleted0);3、定位问题分析慢查询SQL本身是否有优化空间。当搜索关键字匹配到大量的商品时 第3条SQL语句会返回大量重复数据第4条SQL语句中的in查询条件中同样包含大量重复的商品分类id第3条和第4条SQL都会出现查询时间较长3.3.4 解决方案优化第3条SQL语句 因该SQL语句的查询结果大部分都是重复的 可以进行去重处理。第4条SQL慢查询SQL自身无优化空间但是在查询时条件中的ID有大量重复而ID又是第3条SQL返回的结果因此可以优化第3条SQL语句进行去重处理selectDISTINCTcategory_idfromlitemall_goodsWHERE(keywordslike%床%andis_on_sale1anddeleted0)or(namelike%床%andis_on_sale1anddeleted0);3.4 案例4-JVM内存溢出3.4.1 场景描述请求测试接口/wx/index/oom模拟内存溢出3.4.2 测试结果数据3.4.3 问题分析JVM内存占用随着时间的推移占用越来越多 直至内存溢出 系统退出3.4.4 解决方案排查代码存在的问题 及时释放无用的对象