LoadRunner中TPS该如何定义值

TPS ：Trasaction per second也就是事务数/秒。它是软件测试结果的测量单位。

TPS是指一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，最终利用这些信息来估计得分。客户机使用加权协函数平均方法来计算客户机的得分，测试软件就是利用客户机的这些信息使用加权协函数平均方法来计算服务器端的整体TPS得分。一般来说系统的TPS取决于系统事务最低处理能力的模块的TPS，经验值10-100

性能测试针对系统的性能指标，建立性能测试模型，制定性能测试方案，制定监控策略，在场景条件之下执行性能场景，分析判断性能瓶颈并调优，最终得出性能结果来评估系统的性能指标是否满足既定值

步骤：

在线用户数、并发用户数、压力线程数、TPS的关系如下：

1单个用户的TPS计算：通过日志，拉取一个用户的 *** 作记录，记录下来一个事务的 *** 作时间。例如：1个用户，100秒内，完成了一个完整流程，有4个 *** 作（查询商品、填写信息、支付、订单详情），调用了20个接口。

用户级TPS：1 1/100=001TPS。 (1个用户) （1个完成业务）/100s

*** 作级： 1 4/100=004 TPS (1个用户) （4个 *** 作）/100s

接口级： 1 20/100=02TPS (1个用户) （20个接口）/100s

2多用户的TPS。从生产拉取1天的用户量，记算下平均完成的时间（这会有一个问题就是很多用户没有真实走完一个完整业务，所以这个TPS计算是要注意？为了方便仅做假设每个用户是在100秒内完成）假如有一100万的用户，在1天内完成业务

用户级TPS：1000000 1 1/24/60/60=1157TPS。 1000000 (1个用户) （1个完成业务）/24小时/60分钟/60秒

*** 作级： 1000000 1 4/24/60/60=4629 TPS 1000000 (1个用户) （4个 *** 作）/24小时/60分钟/60秒

接口级： 1000000 1 20/24/60/60=23148TPS 1000000 (1个用户)（20个接口）/24小时/60分钟/60秒

3峰值时的TPS。 1000人，在1分钟内完成业务

用户级TPS：1000 1 1/60=1667TPS。 1000 (1个用户) （1个完成业务）/60秒

*** 作级： 1000 1 4/60=6667 TPS 1000 (1个用户) （4个 *** 作）/60秒

接口级： 1000 1 20/60=33333TPS 1000 (1个用户)（20个接口）/60秒

4,怎么计算并发用户数和TPS之间的关系。

假如在jmeter中，完成一个完整的流程5秒钟。

用户级TPS：1 1/5=02TPS。 (1个用户) （1个完成业务）/5s

*** 作级： 1 4/5=08 TPS (1个用户) （4个 *** 作）/5s

接口级： 1 20/5=4 TPS (1个用户) （20个接口）/5s

5,无停顿（并发用户）相当于多少有停顿的用户（在线用户）

02/001=20 即无停顿TPS/有停顿TPS。

并发度=1/20100% =5%

6压力线程数

a)100万在1天内：1000000的在线TPS/并发TPS=1157/02=5785

b)1000在1分钟内： 1000的峰值TPS/并发TPS=1667/02=8335

7并发用户数的计算

并发用户数=在线用户数×有停顿时间的单线程TPS/无停顿时间的单线程TPS

8并发度：并发度=并发用户/在线用户×100%（取值要在同一时间段）

1抽取业务模型，可以通过日志系统或埋点等手段获取。

2业务模型的作用：一是评估线上的性能；二是为后面的容量测试做准备

也可称之为混合容量性能场景，即将所有业务根据比例加到一个场景中，在数据、软硬件环境、监控等的配合之下，分析瓶颈并调优的过程。

1，业务指标

2，对各业务进行基准性能场景测试，对各业务基线测试，并优化以满足业务性能指标

3，抽取线上业务模型

4，根据业务模型，编写执行脚本，进行容量测试

核心就是时长。在长时间的运行之下，观察系统的性能表现，分析瓶颈并调优的过程

1，根据实际的业务需求设置。如我们每周一个发布周期，平均2个月所有的业务线会发布一次（即服务器重启）。那么我们的稳定性测试的策略应该是以最大TPS，执行7~30天。不可少于7天。但可以多于30天。

2,为什么以容量测试的最大TPS？ 如果容量测试下来的最大TPS不能稳定执行，其容量测试的结果又什么意义？

一楼说得很对，TPS是丰田生产方式，即Toyota Production System的第一个字母缩写，也称精益生产，是丰田公司通过几代人的努力发展起来的代表当今制造业最先进的一种生产方式，主要杰出人物有丰田喜一郎 、丰田英二(EiJi Toyoda) 、大野耐一(Taichi Ohno )：丰田生产方式之祖、丰田章一郎 (Kiichiro Toyota) ，自丰田公司创办以来，就一直坚持透过制造高品质的产品与服务以贡献社会的核心理念，本诸此核心理念的事业实务与活动所发展出来的价值观、信念、与事业方法在历经多年后，已经成为竞争优势的来源，这些管理的价值观与事业方法就是所谓的「丰田模式」。

因为TPS是精益生产的一种，所以开生产型公司的人导入这种模式会省很多钱，而不是赚很多钱，因为目前的市场是卖方市场，而不是买方市场了，只有降低成本就能赚取更大的利润。

如果你的是计算机的TPS，应该是TPS 是Transactions Per Second 的 缩 写， 也 就 是 事 务 数/ 秒。 它 是软件测试结 果 的 测 量 单 位。 一 个 事 务 是 指 一 个 客 户 机 向 服 务 器 发 送 请 求 然 后 服 务 器 做 出 反 应 的 过 程。 客 户 机 在 发 送 请 求 时 开 始 计 时， 收 到 服 务 器 响 应 后 结 束 计 时， 以 此 来 计 算 使 用 的 时 间 和 完 成 的 事 务 个 数， 最 终 利 用 这 些 信 息 来 估 计 得 分。 客 户 机 使 用 加 权 协 函 数 平 均 方 法 来 计 算 客 户 机 的得 分，测试软件就是 利 用 客 户 机 的 这 些 信 息 使 用 加 权 协 函 数 平 均 方 法 来 计 算 服 务 器 端 的 整 体TPS 得 分。

网络带宽影响redis效率。对于100M的内网，redis单链接每秒处理约2000请求，当带宽被占用30到40M时,处理数降为约500，使用netperf工具将带宽占满，处理数降为250。因此，带宽必须足够大才能确保redis效率恒定。

对所需内网带宽的估算。测试环境中，3x2000TPS占用约30M带宽（5kB/s）。如果需求为10W TPS，则占用约500M带宽，因此总带宽应在5000M以上才能保证redis速率波动在10%以内。

log影响收包速率。在log完全打开时收包速率始终无法超过1500TPS，关闭绝大部分log，收包TPS可以突破5000。分析，单看CPU占用率，log完全打开时，CPU占用率并没有特别明显上升，因此不觉得会影响收包，实际情况因该是log占用大量io *** 作，影响了收包速率。同样问题在消息模拟器也出现了，不同的是，影响的是发包速率。

业务进程数以及比例影响TPS。

使用redid-benchmark测试redis速率要注意，因该在实际网络环境下测试，并且最好是使用redis的系统在运行中，这样的测试结果才有实际参考意义。

优化一般分两步，单进程函数CPU占用率，和并发系统效率。

单redis和redis集群比较。单从速度来说，前者速率稍慢，且单redis CPU 常常成为瓶颈。以3个主机对一个redis或集群为例：

对于单redis，TPS达到1500x3时，redisCPU已达到95%左右。对于集群，TPS达到2500x3时，CPU均为80%左右。

常用的网站性能测试指标有：TPS、吞吐量、并发数、响应时间、性能计数器等。

系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间。

性能计数器是描述服务器或 *** 作系统性能的一些数据指标，如使用内存数、进程时间，在性能测试中发挥着“监控和分析”的作用，尤其是在分析统统可扩展性、进行性能瓶颈定位时有着非常关键的作用。

Linux中可以使用 top 或者 uptime 命令看到当前系统的负载及资源利用率情况。

资源利用率：指系统各种资源的使用情况，如cpu占用率为68%，内存占用率为55%，一般使用“资源实际使用/总的资源可用量”形成资源利用率。

所以，一个网站优化的目的是，最大限度的利用好服务器硬件资源提升资源利用率，减少用户请求的响应时间，提高系统吞吐量，提高系统并发数。

吞吐量： 一段时间内应用系统处理用户的请求数（以下介绍指单位时间内，也可以理解为吞吐率），这个定义考察点一般是系统本身因素；当然也可以用单位时间内流经被测系统的数据流量，一般单位为b/s,即每秒钟流经的字节数，这个定义的考察点既有系统本身因素也有网络，外设等因素，也可以理解为除客户端以外的测试环境及被测系统。

并发用户数： 指同一时间点对业务功能同时 *** 作的用户数，可以分为两种： 一种 是严格意义上的并发，即所有的用户在同一时刻做同一件事或 *** 作，这时业务功能一般指同一类型的业务； 另外一种 并发是广义范围的并发，这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了 *** 作，但是这些请求或都 *** 作可以是相同的，也可以是不同的，这时业务功能可能不是同一类型的业务。

并发数 >= 吞吐量

一般来说，在系统的设计范围之内，吞吐量随系统的并发用户数的增加呈现增加趋势，也就是说你客户端来多少请求数系统吃（处理）多少请求数；当超出这个范围时有两种情况，一种是系统只能处理这么多，超过这个数系统不接收了，最后随着并发用户数的增多吞吐量是一个水平的直线；

还有一种情况是不管来多少系统都接收最后导致系统吞吐量下降甚至系统崩溃。并发用户数是客户端单位时间内对服务器端施加的压力，具体能不能接受并处理要看被测系统的吞吐量，而吞吐量是被测系统单位时间内处理的请求数或者说单位时间内处理的字节数；一个着重于客户端的 *** 作即测试手段，一个着重于应用系统的处理能力即查看对象；（上面的讨论没有考虑两者的单位，如一个用户同时有多个请求情况）

两者的计算公式如下：

其中C是平均的并发用户数，n是平均每天访问用户数，L是一天内用户从登录到退出的平均时间（ *** 作平均时间），T是考察时间长度（一天内多长时间有用户使用系统）

其中C^是并发用户峰值，C是平均并发用户数，该公式遵循泊松分布理论。（该公式针对一般被测系统，特殊不做讨论）

吞吐量计算：当没有遇到性能瓶颈的时候，吞吐量与虚拟用户数之间存在一定的联系，可以采用以下公式计算：

其中F为吞吐量，VU表示虚拟用户个数，R表示每个虚拟用户发出的请求数，T表示性能测试所用的时间，其实通过这个公式就能看出吞吐量与并发用户数之间的关系了（这里的VU就是我们用工具模拟的并发用户数）。

参考：

>

TPS

压力测试工具中的线程数和TPS并不会完全等于服务端的线程数和TPS，在具体的项目性能测试过程中，我们应该尽可能关注服务端能处理的请求数即关注服务端的TPS。

并发

建议做性能测试不要总说系统能支持多少并发，这个瞬时概念不能很好的衡量系统性能，那还是用TPS来的和谐。

并发数和TPS

有50个并发线程，每个线程都可以在1秒内完成100个事务，那么TPS=5000。

在线用户估算TPS

很多业务中，并发度都会低于5%，甚至低于1%。假设5%并发度，100w用户来计算：

TPS=100w x 5%=50000

根据TPS估算并发线程数

如果这时响应时间是 10ms，那显然并发线程数理论上是 50000TPS/(1000ms/10ms)=5000(响应时间是波动的所以是理论值)。

压测机器与线程数

运行压力测试工具的机器所能启动的线程数是与其硬件相关的，所以使用线程数一定要合理，并且把压测机器纳入压测的监控范围

以上就是关于LoadRunner中TPS该如何定义值全部的内容，包括:LoadRunner中TPS该如何定义值、性能测试基础概念1、tps是什么等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！