Alice南京
- 浏览: 21146 次
- 性别:
- 来自: 南京
-
最新评论
文章列表
参考：http://www.blogjava.net/qileilove/archive/2014/04/02/411826.html
在Controller里运行脚本，运行一段时间以后出现如下error messages。
Code - 60990 Error: Two Way Communication Error: Function two_way_comm_post_mess
问题诱因1：
共享内存缓存溢出，造成Controller和Load Generator之间通讯出现问题。
解决方案：
修改两个配置文件。
1. $installation folde ...
5个用户，使用一台压力机
5个用户，使用五台压力机
不过脚本相同写法，调用另一个系统不存在此问题。（就系统和接口不同）
所以说压力机问题。。。。哎，哎，哎
import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import org.springframework.context.support.FileSystemXmlApplicationContext;
import com.suning.ssf.endpoint.ser ...
我这里写下参数类型为file的
Select Next Row
Sequential：顺序
Random： 随机
Unique： 唯一
Update Value On
Each iteration： 每次迭代
Each occurrence：每次出现
once： 只取一次
我想特别说下的是unique。
所需的场景是用户登陆一次不断的去支付。
这儿介绍下参数在init里面
只能使用一次，使用多台压力机
参数化里有10个用户，压力机上了11个用户。
11个用户，成功上了9个用户，有2个报参数用尽。
（1）unique成功的每台压力机上登陆的用户都是不一致 ...
loadrunner 日志打印
- 博客分类：
- 性能
参考：
http://bbs.51testing.com/thread-136652-1-1.html
http://bbs.51testing.com/thread-112085-1-1.html
日志存放位置分两种设置：
1.在VUGEN中运行后的日志
2.在controller中运行后的日志
当然打印日志需要先设置日志开关是打开的。
思考问题
log的输出 会不会影响到客户端，会不会使客户端成为瓶颈？（认为是会的，任何程序都是要消耗资源的，loadrunner也一样，所以选取日志输出的模式是要谨慎考虑尽量以适用为前提）
所以开日志建议是出现报错或确认参数化取值的的时候 ...
1.AIX小机 压测CPU的sys请求过多
尝试调整日志级别，sys请求少很多。
2.还是上面的场景去除日志后，tps也提高了些。
优化指打日志和不打日志。
梯度测试线性越好，可伸缩性越好。
可伸缩性测试：进行负载测试，记录不同负载下的平均响应时间，然后查看平均响应时间是否线性增加。如线性增加，则说明系统具有可伸缩性；否则说明系统可伸缩性较差或者没有可伸缩性。
正好印证了一把。
3.tps较高的情况下，开发做了日志打包。
影响：响应时间阶段性超时每隔7分钟就会出现一批超时。
http://124358959.iteye.com/blog/2232846
需要保证手机终端和电脑在同一无线网络内，手机终端可以通过代理将请求信息通过电脑进行转发。
1.对手机进行代理设置（图一、二）
1.1查看电脑ip
1.2手机连接台式机随身wifi并设置一个不常用的端口号
2.对loadrunner进行协议设置
2.1找到Loadrunner11.0，wplus_init_wsock.exe文件的地址，如：
C:\Program Files (x86)\HP\LoadRunner\bin\wplus_init_wsock.exe
2.2无线上网卡的笔记本或台式机（台式机可使用随身Wifi作为无线上网卡）
2.3需要进行测试的server地址：fiapppre.** ...
关联：从响应消息中取出我们需要的字段值。
每一次执行时都会变动的值，就有可能需要做关联。
一．关联操作的条件
客户端需要从服务端返回的数据中获取部分数据，并将这部分数据处理后作为自己下一次请求的一部分发出。
二．如何找出要关联的数据呢
序列号和随机数一般需要关联。
常见的需要关联的情景：
1.登录操作
2.先查后修改，先查后删除
3.并发控制：防止两个用户同时修改或同时删除一条记录
订单号和Token。
下单页面生成的订单号，需要在下单页面的响应消息里抓取，在放到收银台页面的相关参数中，才能够完成一个完整的支付。
还有一类必填参数但是会被我们忽略的叫做Token。
原文：http://z ...
1.小压力跑场景不到1MIN，请求消息都返回失败。
报抓关联失败，日志报响应消息失败。
a.开始定位账号问题，后测试数据走页面OK。
b.请求已发到esb了，esb报403，怀疑esb丢包。
c.最后确认是防火墙拦截了。
403forbidden----防火墙拦截。
业务背景：
随着业务发展，单表的数据量已达实际应用推荐的极限，继续增加可能会性能瓶颈，考虑到后续业务发展，必须把现有数据按比例拆分到多张分表，这样变相地提高了单表容量。
分表性能关注：
分表索引数据的读取比较频繁，需要考虑使用缓存机制，以及定期更新缓存的机制，减少单表压力，提高性能。
批量操作时如果涉及到多个分表的读写，应该顺序执行，减少数据库的并发请求。同时业务系统应该关注批量查询的时间段，减少无意义的大范围查询功能。
分表测试方案设计：
压测场景 (单表铺底500w)
单条数据插入：A表
单条按主键查询，数据集中在同一张分表：A表
单条按主键查询，数据分散在不同分表：A表
单条按条件查 ...
运行时报错：
Action.c(8): Error -26601: Decompression function (wgzMemDecompressBuffer) failed, return code=-5 (Z_BUF_ERROR), inSize=0, inUse=0, outUse=0
分析：
这个错误为数据包较大，未下载完整或其他原因导致解压错误。
请求页面的脚本，出现的此问题。接口的脚本都是返回响应消息无此问题
解决一：
1.进入运行时设置 ；
2.internet protocol->preferences->options->general->ne ...
同一脚本，响应时间不一样（回放VS场景压测）
回放过程中事务的响应时间3s左右,实际运行场景的时候平均响应时间只有0.6s。
为什么两者的差距这么大呢？
我们写脚本时用的“generator”模式下和运行场景在“Controller”模式下，两种不同模式下的响应时间比较。
在 generator 模式下 回放时， LR首先会对您的代码进行边编译边执行的处理方式(如果你把每个函数的处理时间打印出来就会发现函数处理时间非常的大~甚至占总运行时间的 80% 以上)。这样就导致响应时间变得很慢。
如果在 controller 模式下执行场景的时候，是首先对您的脚本进行编译，编译后才进行真正的事物 ...
接口调通了接收到响应消息，数据库查不到账号相关信息。
就逗你一乐，所有连接信息不变开发让我换一用户登录，就查到了。
开发解释
接口用的表在这个实例下的FDM_APP模式下，这个实例下同时有FBISSFDS是默认生成的模式，虽然建了表但后来没有用这个模式名。
我学习了
我用loadrunner11.0录制B/S模式的程序，用的是web协议录制的，客户端能录制成功产成脚本，但是回放的时候非常慢。在别的同事的机器上录制一样的脚本，能够很快的回放，不知道为什么我的机器回放的很慢。
java脚本速度回放正常。
解决：
修改C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config 文件里的<runtime/>为
<runtime>
<generatePublisherEvidence enabled="false"/> ...
MAX Response time
java脚本，ssf接口
A系统面向用户展示，B系统是外围系统。
A系统要求B的响应在500ms以内。如果超过500ms则算超时，计入error日志。
根据日志捞了两次错误日志，根据压力不同，超时个数为
大压力 超时大约100:1
小压 ...
压测执行报错：This Vuser already started a transaction with the same name, and has not yet
单脚本调测报错：Error: Vuser started transaction "预约提交", but did not reached a corresponding end transaction statement. The transaction ended automatically with status 'fail'.
检查脚本发现，
if(respCode0==0)
...