目的不明确,容易找不到北。只能根据项目项次试试各部分功能 看看有没有bug。 你指的性能测试是哪方面呢?
只要你算对了,就能控制对。需求:各个交易的TPS分别是多少计算每个交易的并发数、pacing算对,凑出这个TPS即可注意1)别把压力机压垮,给压力机一些余量2)pacing别太小,小于20ms 基本是控制不稳的
3)并发数也要合理,太大了,压力机也撑不住(没那么多内存),调度开销也大,最后性能反而下降。...
1)如何模拟核心系统的正常压力不确定你问的是哪一方面,就我的理解先回答一部分一个交易或者请求的链路可以很长,那么,可以从这条链路中任意一个节点,采用某种压力工具进行施加压力。比如,a)可以模拟end user的页面操作,用Loadrunner、JMeter等性能测试工具录制用户的页面操作,采用...
对测试环境和生产环境的差异做分析。比如说架构是分布式的,各台服务器之间没有资源共用或者资源争用或者可控范围内的资源共用,那么测一台服务器就可以推演出N台的能力。如果有资源共用,那么这个资源能支撑多少业务量,总之,是有一些推算的方法,虽然不一定很准确。同理,资源少的...
(一)一种方法是直接比照生产,这种方法也可以有几个小的选择:1)把生产环境的情况直接转化为性能测试模型,在测试环境测。比如生产环境的存量数据是多少、TPS是多少,业务配比大概是多少,占比最多的业务量是多少。2)直接做生产数据回放。Oracle有录制回放的功能。也可以把生产日志cop...
不熟悉想办法熟悉,找相关业务人员参与进来,特别是银行,成立一个小组,不就解决了
一套正规的线上业务系统的测试环境至少有一个开发环境,UAT环境,如果想达到和线上业务系统一样的效果,那至少有一个模拟生产的准生产环境。你都说了,你测试环境就是虚拟化,估计数据也都是很少,硬件也达不到,测试结果怎么能和生产相比呢?...
1)找类似的系统进行类比预估2)如果没有任何系统可以对比,也没有任何预计的业务量的指标,2.1)需要确认架构的可扩展性2.2)如果架构不具备快速的容量扩展能力,那就需要进行典型场景的负载测试,不断加压,找到性能的拐点、瓶颈点,分析解除瓶颈的方法。这样,在生产上如果业务量过大,压垮系...