性能测试思想
文章平均质量分 69
haoluojie
对平时工作中遇到的问题做一些总结,不断积累,不断提高,记录不只是能帮助别人,也是对知识的总结,以后再遇到相似问题也知道如何去解决,感谢帮助过我的人,也希望我遇到的问题能够帮助到别人,欢迎加微信探讨:haoluojie123
展开
-
性能测试中SQL引起的性能问题
在做XXX系统性能测试的时候,100个并发对该业务进行查询操作,平均响应时间都大于10s,经过排查,应用服务器资源,数据库资源,IO,网络都正常,查询 相关业务sql,其中一条sql执行耗时很长,该sql就是对应查询业务的sql,具体sql为公司机密,不便透漏。sql大致为:SELECT count(*)FROM XXX WHERE XX != 0 and NAME like '%jie性能测原创 2015-11-03 15:30:59 · 672 阅读 · 0 评论 -
前端页面响应时间长简单定位分析
利用firebug-yslow进行分析,也可利用loadrunner的analysis的拆分细节图进行定位分析。代理商号段新增、编辑、删除执行效率低下,根据页面细分图详细结果分析,95%以上的响应时间耗费在如下:http://192.168.1.201:8055/pm_out/FrPsamRange/saveFrPsamRangeAction?rel=FrPsamRangeNext&nav原创 2016-08-30 19:53:49 · 5301 阅读 · 0 评论 -
别太轻信测试脚本中返回的测试信息就判断脚本成功,需要核对数据库数据,日志信息才最真实
如下信息图,调试结果成功,数据也是按照预期的获取:很多人都说设置检查点就能判断测试业务是否成功,但是有的时候或者说部分特殊的业务,即使使用了web_reg_find函数,也无法真正判定脚本就是执行成功,我们需要核对数据库数据,日志信息才最真实,也要注意打印的日志中的各种异常信息,最好在linux服务器利用grep 过滤出相关异常信息,只是看检查点数据就判断成功,也许其实存在着我们并原创 2016-08-30 20:03:09 · 781 阅读 · 0 评论 -
Loadrunner开发的socket协议脚本服务端无法通过解决方法
loadrunner测试socket协议接口脚本时候,发送数据,客户端报如下错误:解决:由于发送的数据中含有中文,与服务器编码方式不一致,更改本地客户端为UTF8或者更改为英文数据,发送报文正常。原创 2016-08-30 20:06:12 · 1414 阅读 · 0 评论 -
socket协议的接口测试方法
1.loadrunner使用socket协议写C调用底层socket协议数据2.jmeter添加websocket相关依赖包,可以添加websocket协议的sampler3.专门的socket协议测试工具,比如socket工具,tcpudptest等工具。tcpudptest无法设置并发数据量,不方便,而socket工具可以设置并发数据量,而且有相关的数据发送接收包的图像实时图,8583原创 2016-08-30 20:21:20 · 9699 阅读 · 0 评论 -
mysql数据库部分性能问题分析及优化
好久没更新东西,都更新在自己的本地world中了,比较忙碌,最近在python+selenium搞自动化方面的东西,后续有开发个自己的监控系统的想法(python搞比较好,虽然python掌握得很low,这个可以学,对!),python搞起来,还是以性能测试为主吧,有多余的精力再去搞鼓那些,先记录下公司刚做的一个项目的部分性能问题一些分析思路:目前在做公司一个项目性能测试xxxxx,后端主要涉原创 2016-07-09 14:35:37 · 933 阅读 · 0 评论 -
Socket协议Loadrunner脚本+8583报文解析及组装
本交易为POS消费交易,报文类型为8583通讯报文,一般在银联通讯方面,金融交易方面用的比较多,如下为手动编写我们的测试脚本,并非录制而成,在此类直接与接口交互的性能测试项目中,经常会用到报文组装、拼接等工作,这里记录想整个数据的解析拼装过程以及我们测试思路一:pos交易(8583协议)报文处理部分:必须熟悉不同交易每个域的划分及每个域的数据长度,具体详细报文结构不做具体描述,每个报文有其原创 2016-11-03 16:12:03 · 7041 阅读 · 2 评论 -
压测系统交易出现响应超时性能问题分析及解决。
问题:在大于10并发,xx交易开始大量报交易超时,持续压测,无法正常交易。分析:先查看网络问题,从前置ping加密机,经过2个路由,发现部分响应数据时间比较长,如图:最后确认为加密机不是在同一网段内,网络连接方面出现延时现象导致交易超时失败,将加密机切换到同一网段后,正常。B/S端、app端、或其他终端的此类现在问题分析及总结:1.先确定压力机的负载情况,是不是原创 2017-01-11 18:17:35 · 5398 阅读 · 0 评论 -
性能测试脚本运行一段时间后TPS突然下降,过段时间后又恢复正常的原因
现象:1并发运行5分钟,脚本全部执行成功,所有指标正常,并发设置为20脚本运行一段时间后TPS突然下降为0,响应时间线条无打点记录,过段时间后相关指标又恢复正常,查看报错信息为连接不上服务器,如图所示:Error信息:连接服务器失败:定位分析:根据图中曲线走势和报错信息,“连接不上服务器,连接超时”,查看应用服务器的资源使用情况,内存,CPU,NET几乎没任原创 2017-01-11 18:43:38 · 15519 阅读 · 4 评论 -
java.lang.OutOfMemoryError内存泄露 代码定位及优化
问题现象:20并发登录系统户,刚开始所有指标正常,压测10分钟左右后,页面报java.lang.OutOfMemoryError,系统无法登陆,脚本无法正常压测,出现内存泄露,如图:监控分析:查看到应用服务器CPU一致持续97%以上,监控JVM,堆内存每次回收不彻底,无法正常释放,持续加压下heap内存消耗完,最终导致服务宕掉,无法访问系统页面。可确定,代码存在内存泄露原创 2017-01-11 18:52:27 · 1523 阅读 · 0 评论 -
php-fpm backlog参数潜在问题
原文来自http://blog.csdn.net/willas/article/details/11634825前几天有业务在新机器上线测试时,发现个问题:同样的资源的虚机、同样配置的ngxin+PHP-fpmweb后端的两台机器,测试后发现:访问.html文件时QPS相差不大,但是访问php页面时其中一台的QPS是另一台的数倍。通过分析,发现是php-fpm的backlog参数引转载 2017-07-25 14:43:43 · 4764 阅读 · 0 评论 -
代码死锁,TPS低,RedisQPS低性能问题定位优化
问题:压测公司某业务线接口,TPS最大处理能力20左右,整个服务端资源无任何压力,cpu利用率较低6%,redis QPS较低原因排查:出现此问题,根据经验一般是代码存在死锁导致,jstack查看堆栈信息和查看业务代码。根据业务功能是发表祝福时候会生成一个楼层数据,而生成楼层加了锁,以防止并发导致楼层重复,如图:优化:由获取数据库id加锁改为redis自增获取。优化后,TP原创 2017-12-10 09:32:38 · 1742 阅读 · 0 评论 -
TPS波动各种原因总结,做过的项目大概总结下有5中以上情况...
tps具有一定的波动性--->找到tps波动原因:①、原创 2017-12-10 15:14:23 · 6422 阅读 · 4 评论 -
走redis缓存和不走缓存TPS差异明显对比
接口处理逻辑:获取天气预报信息,1500个左右城市天气:程序第一次处理时候,会先判断redis key是否存在,若存在,直接返回对应数据;若不存在key,读取mysql对应表数据,同时把该数据缓存到redis,并返回数据;若第二次在访问同样数据,直接走redis获取对应数据。 对比业务的mysql和redis处理性能情况: 断掉redis服务,不走redis,走mysql取原创 2017-12-10 15:25:56 · 1712 阅读 · 0 评论 -
heap消耗(-xms设置大小决定),GC频繁,GC overheadlimit exceeded解决办法
经过对JVM堆内存使用监控,xxxx程序压测过程中yong gc正常,GC比较频繁,如图:如下系统配置参数JAVA_OPTS="-server -Xms256m -Xmx256m -XX:PermSize=64M-XX:MaxNewSize=256m -XX:MaxPermSize=128m"系统分润跑批报:java.lang.OutOfMemoryError:GC原创 2016-08-30 19:51:04 · 4029 阅读 · 0 评论 -
压测xx业务数据库资源大量等待,存在表锁问题,导致数据库无法正常执行解决办法
压测xxxx业务期间,监控oracle数据库资源大量等待,存在表锁问题及相关sql,如图:数据库查询详细表锁情况如图: 跑xxxx业务操作的时候,数据库无响应,经查询,执行xx表无响应,经查看,存在锁表情况导致。原因是update xx表时候没做commit操作。解决方法:①查询表锁详细信息,找到对应的SID,SERIAL#:SELECT l.session_i原创 2016-08-30 19:43:14 · 2525 阅读 · 0 评论 -
服务器端签购单数据量和压测数据量不一致
压测前服务器有24张签购单,压测10次后,只有27张签购单,丢失7张查看服务器对应目录下的数据统计:ls -l | wc -l 统计得出服务器端丢失3条数据解决:重新启动服务器,再次压测,数据能够保持一致。具体原因可能是两台服务器同步导致数据丢失,只一台服务器数据正常原创 2016-08-30 19:18:32 · 460 阅读 · 1 评论 -
CPU使用高问题分析
今日性能测试过程中发现CPU使用率过高,出现性能瓶颈,于是开始了问题的监控分析:1)首先定位是us态cpu高还是sys cpu高,如果是sys态cup高,那问题估计出现在linux内核,需要对linux内核进行优化,如果是us态cpu高,可对引用进行排查分析2)top命令找到最耗cpu进程的PID,发现28400占用CPU最高3)确定该进程后,定位该进程下的具体线程,找到占用cpu最长原创 2015-10-09 21:06:15 · 660 阅读 · 1 评论 -
性能测试过程中前端某图片显示异常问题及解决思路
性能测试过程中出错,手动访问系统首页,验证码显示不出来,如下图:查找原因:1)刚开始以为是tomcat出现问题,重启192.168.1.201:8088的tomcat服务后,显示还是不正常,更换浏览器访问也不正常,怀疑是验证码相关的代码出现了问题。2)开启192.168.1.201:8055服务(相同项目,之前访问正常,没改动过代码,只是应用服务器为weblogic),打开页面原创 2015-10-28 17:02:06 · 609 阅读 · 0 评论 -
nmon安装部署及结果分析
好东西,nmon安装部署好了,nmon监控linux服务器数据强大,以后以nmon监控为主,监控时候需要注意时间的记录,在配合linux相关工具命令监控linux服务器性能,zabbix可做相关参考。公司内部完整版nmon安装部署,以及性能测试结果分析如下:原创 2015-11-10 18:26:45 · 745 阅读 · 0 评论 -
峰值的部分计算方法
1) 二八法若80%的访问量集中在20%的时间里,可用此分析方法,其图形就是一个正态分布图,如下。---性能测试需求收集" alt="性能测试(1) ---性能测试需求收集" src="http://s8.sinaimg.cn/middle/639aa085gbab530b29f37&690" width="360" height="273">具体计算公式为:tps = (原创 2015-12-28 15:57:15 · 15678 阅读 · 0 评论 -
data factory快速生成大批量数据
上次在我的博客中讲述了quest公司的spotlight系列软件,这次来扯淡一下quest公司的另一测试辅助软件 datafactory(数据工厂),顾名思义,数据工厂是生产数据的,主要应用领域是性能测试中的大数据量测试, 也就是性能测试数据准备阶段。原理说明:通过和数据库进行连接后,对选定表的字段设定一定的插入规则,然后批量插入记录。Datafactory支持各种主流数据库(orac转载 2015-12-28 16:21:42 · 1506 阅读 · 0 评论 -
JVM内存管理与调优
1、Java虚拟机运行时的数据区2、常用的内存区域调节参数-Xms:初始堆大小,默认为物理内存的1/64(-Xmx:最大堆大小,默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时,JVM会减少堆直到 -Xms的最小限制-Xmn:新生代的内存空间大小,注意:此处的大小是(eden+ 2 survivor space)。与jmap -heap中显示的New转载 2015-12-03 23:38:16 · 536 阅读 · 0 评论 -
浅谈软件性能测试中关键指标的监控与分析
浅谈软件性能测试中关键指标的监控与分析一、软件性能测试需要监控哪些关键指标?软件性能测试的目的主要有以下三点:Ø 评价系统当前性能,判断系统是否满足预期的性能需求。Ø 寻找软件系统可能存在的性能问题,定位性能瓶颈并解决问题。Ø 判定软件系统的性能表现,预见系统负载压力承受力,在应用部署之前,评估系统性能。而对于用户来说,则最关注的是当前系统:转载 2016-03-02 14:52:32 · 817 阅读 · 0 评论 -
登录界面验证码显示不出来及解决
查找原因:1)刚开始以为是tomcat出现问题,重启192.168.1.201:8088的tomcat服务后,显示还是不正常,更换浏览器访问也不正常,怀疑是验证码相关的代码出现了问题。2)开启192.168.1.201:8055服务(相同项目,之前访问正常,没改动过代码,只是应用服务器为weblogic),打开页面,也是同样的问题,排除代码方面问题3)怀疑内存是否够用,查看内存使用情况原创 2016-08-30 18:52:28 · 37458 阅读 · 1 评论 -
1000并发时候,监控日志出现此问题:java.lang.OutOfMemoryError: unable to create new native thread
1000并发时候,监控日志出现此问题:java.lang.OutOfMemoryError: unable to create new native thread原创 2016-08-30 19:06:21 · 569 阅读 · 0 评论 -
100并发运行一段时候后xx接口失败及原因
解决方法:修改程序最大连接数accepts="10000",并发能够支持到1000调节后配置参数如下: 调节改配置参数后100并发持续压测2小时,接口全部成功。原创 2016-08-30 19:09:20 · 1037 阅读 · 0 评论 -
20并发下支付接口存在响应时间超时问题及排查思路
支付接口主数据流向:压测脚本-->网关(81服务器)-->zookeeper分配服务器-->74和75服务器-->支付-->队列-->核心(237服务器)-->mokerserver 经监控20并发对服务器硬件资源没明显瓶颈,脚本执行到81,74,75服务器时候速度都很快,到达核心时候(237服务器),速度变慢,由核心负责人员协助优化,经查询,核心设置最大连接数过小,导致线程排队等待,原创 2016-08-30 19:12:49 · 3482 阅读 · 0 评论 -
大并发压测下,redis连接异常Read timed out排查优化
压测业务流程:获取全国范围地区信息,第一次从mysql获取信息,获取到信息后hset到redis,后面的获取信息都走redis获取并返回接口数据。问题:20并发压测获取全国范围地区信息, 应用报错,getList:merchant:area:listerror,redis连接异常Read timed out(10并发正常),应用抛出错误:redis.clients.jedis.except原创 2017-12-10 15:54:14 · 28654 阅读 · 0 评论