性能测试TPS目标值确定-二八原则

最新推荐文章于 2025-05-31 00:08:45 发布
转载 最新推荐文章于 2025-05-31 00:08:45 发布 · 1w 阅读 · 9

 在性能测试中通常使用二八原则来量化业务需求。

二八原则：指80%的业务量在20%的时间里完成。

例：如某个公司1000个员工，在周五下午3点-5点有90%的员工登陆公司周报系统

则：业务量=1000个，时间=2x60x60=7200秒

根据二八原则来计算3点到5点的TPS=(90%*业务量*80%)/(20%*时间)=0.9*1000*0.8/(0.2*7200)=0.5个/s

注：二八原则计算的结果并非在线并发用户数，是系统要达到的处理能力（吞吐量）


【性能测试】压力测试指标全解之TPS、响应时间
CynthiaJuJu的博客
01-09 6789
​hello，大家好！我是磨磨唧唧小蘑菇~ 接上期阐述了《TP50/90/99/999》的含义及计算方式，本期将阐述压力测试的其他指标，如TPS、响应时间、并发数等。
软件测试知识点和面试题--性能测试篇
行走在路上
02-14 5561
基础理论 概念 性能测试：使用自动化工具，模拟不同的场景，对软件各项性能指标进行测试和评估的过程 ​ QPS：即Queries Per Second的缩写，每秒能处理查询数目。是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。每秒钟处理完请求的次数；注意这里是处理完，具体是指发出请求到服务器处理完成功返回结果。可以理解在server中有个counter，每处理一个请求加1，1秒后counter=QPS。QPS = 并发量 / 平均响应时间 ​ TPS：即
你真的知道如何制定性能测试的目标吗？
我乐了的博客
02-20 1048
比如有的业务第一次在数据库请求到数据后，应用层本地缓存会将数据存储在应用服务器上，也就是接下来在缓存有效时间内不会再去数据库取数据，而是在应用层得到数据后就会直接返回，所以响应时间会比第一次低不少，这也是随着性能测试的进行响应时间变低的原因之一。流量复制是不能解决指标制定的问题的，并且在落地过程中还会花费大量的时间和人力成本，所以关于目标的制定和分析我们需要一步一步进行，花费一定的时间是难以避免的，并且线上未来的访问趋势只能尽可能覆盖，无法完全预测到。我们都明白在测试领域，提早发现问题修复成本是最低的。
QPS 和 TPS 详解
最新发布
非猿
05-31 1102
QPS（每秒查询数）和TPS（每秒事务数）是衡量系统吞吐性能的关键指标。QPS统计每秒处理的请求数，适用于接口和缓存测试；TPS衡量每秒完成的事务数，关注业务完整性，如支付流程。两者区别在于QPS包含所有请求，而TPS仅统计成功事务。一个事务可能包含多个请求，因此QPS≈TPS×N。性能优化时，提高QPS可通过扩展服务器或使用缓存，提升TPS需优化事务逻辑或数据库结构。理解两者差异有助于精准评估系统性能瓶颈。
二八原则
weixin_34342905的博客
09-05 552
巴列特定律总结果的80%是由总消耗时间中的20%所形成的。按事情的“重要程度”编排事务优先次序的准则是建立在“重要的少数与琐碎的多数”的原理的基础上。举例说明：80%的销售额是源自20%的顾客；80%的电话是来自20%的朋友；80%的总产量来自20%的产品；80%的财富集中在20%的人手中；20%的客户为企业带来80%的利润！80%的客户为企业带来20%的利润！这启示我们在工作中要善于抓主要矛盾，...
性能测试二八原则
weixin_30537391的博客
09-28 526
二八原则定义：指80%的业务量在20%的时间里完成。 例：如某个公司1000个员工，在周五下午3点-5点有90%的员工登陆公司周报系统 则：业务量=1000个，时间=2x60x60=7200秒 根据二八原则来计算3点到5点的TPS=(90%*业务量*80%)/(20%*时间)=0.9*1000*0.8/(0.2*7200)=0.5个/s 注：二八原则计算的结果并非在线并发用户数，是...
TPS计算规则
weixin_50984559的博客
10-18 1502
总时间：由于不知道每个请求的具体时间，我们按照普通方法，我们可以按照一周的时间进行计算，总时间 = 1天 = 1 * 24 小时 = 24 * 3600 秒。需要在测试环境模拟用户正常业务操作（稳定性测试）的并发量为：TPS = 40474 * 0.8请求数 / 16*3600*0.2秒 = 2.81 请求数/秒。**按照公式进行计算：TPS = 41300 * 0.8请求数 / 24*3600*0.2秒 = 1.91 请求数/秒。计算压力测试的并发数：TPS = 峰值请求数/峰值时间 * 系数。
秒杀笔记 —— 二八原则
Genius only means hard-working all one's life.
03-04 854
秒杀笔记 —— 二八原则 有针对性的处理好系统的“热点数据” 认识“热点” 为什么关注热点 什么是热点 发现“热点” 发现静态热点数据 发现动态热点数据 处理“热点” ...
软件测试--性能测试工具JMeter
weixin_42603991的博客
03-04 1240
存放可执行文件和配置文件元件：多个类似功能组件的容器（类似于类组件：实现独立的某个功能（类似于方法例如：取样器的组件作用：定义全局变量添加方式：测试计划 --> 线程组–> 配置元件 --> 用户定义的变量引用名称：存放提取出的值的参数名称，供下一个请求引用，如填写title，则可用${title}引用它正则表达式: 左边界(.*?)右边界()：括起来的部分就是要提取的。.：匹配任何字符串。*：0次或多次。?：不要太贪婪，在找到第一个匹配项后停止。模板。
【软件测试】--性能测试Jmeter
qq_63051355的博客
07-29 750
性能测试需求覆盖情况，性能测试过程中出现的问题，如何去分析、调优、解决的测试人员、进度控制与实际执行偏差和性能测试过程中遇到各类风险是如何控制的经过该项目性能测试后，有哪些经验和教训等内容功能测试报告总结回顾测试过程（测试环境、测试方法、测试工具）分析测试结果（测试了多少用例、发现了多少bug、通过率怎样、bug解决了多少、缺陷分析）展望未来（潜在风险）测试总结（遗留问题、评价、经验教训）在没有接口文档的就项目中，快速录制web页面产生的http接口请求，帮助编写接口测试脚本录制原理。
性能测试笔记2-总
weixin_69378630的博客
10-05 841
添加方式：测试计划 --> 线程组--> HTTP请求 --> (右键添加) 后置处理器 --> XPath提取器。添加方式：测试计划 --> 线程组--> HTTP请求 --> (右键添加) 后置处理器 --> JSON提取器。0：表示随机，-1：表示提取所有结果，1表示第一个值。测试计划 --> 线程组--> HTTP请求 --> (右键添加) 后置处理器 --> 正则表达式提取器。测试计划 --> 线程组--> HTTP请求 --> (右键添加) 断言 --> JSON断言。
TPS计算公式
m0_74090098的博客
05-23 1529
TPS计算公式
tps计算方法
cae_520_ww的博客
11-18 1万+
假如平台总注册用户数有100w，有10w用户约定好同时对某一接口进行访问，比如1分钟，陆续来访10w用户，那么我们系统并发用户是比实际的10w要小的
估算tps
滴水穿石
11-10 2269
性能 TPS
二八定律在性能测试中的应用
suancai1993的博客
04-19 2379
在生活中，做任何事情之前，最好先确定一个目标。 同样的，在我们日常做性能测试之前，最好把本次预期性能指标确定下来，没有预期指标的衡量，将无法评估测试结果数据是否满足预期。比如以下这样的指标： 在实际工作中呢，最理想的情况是，开发/产品/项目经理已经提前确定好了性能指标，然后把指标明确的告诉你。 但是理想很丰满，现实很骨感，根据我多年的性能测试经验来看，大多数提性能需求的人，大多是不太懂性能的...
【性能测试】稳定性/并发压力测试的TPS计算+5W并发场景设计...
大佬云集技术答疑交流群：743262921(进群暗号:222)
11-21 6074
1、稳定性测试TPS计算①普通计算公式：TPS=总请求数 / 总时间按照需求得到基础数据。在去年第20周，某平台有5万的浏览量那么总请求数我们可以估算为5万（1次浏览都至少对应1个请求）总请求数 = 50000请求数总时间：由于不知道每个请求的具体时间，我们按照普通方法，我们可以按照一天的时间进行计算总时间=1天=124 小时=24 * 3600 秒套入公式可得：TPS = 50000/243600秒= 0.58tps。
性能测试TPS指标到底多算才算合适呢？二八定律
热门推荐
weixin_43865008的博客
08-12 1万+
前言 通常我们在压测的时候，都会有一个指标去衡量，比如搜索商品接口，我们预期TPS需要达到多少。 最理想的情况就是开发/产品/项目经理提前确定好了性能指标，但是通常大多数公司对于性能不是很理解，可能你问产品经理，产品经理说TPS是什么。那么这种情况下，我们就需要根据实际情况进行分析，确认性能指标。 明确压测项目类型 一般我们压测的项目会分为两类，一种是老项目，一个是新项目。像我们公司的项目已经上线运行了很长一段时间了，那么在生产环境中，会生成一些历史数据，并且线上也业务监控系统，定期监控各个业务模块核心接口
qps预估量
chuixue24的博客
04-25 5143
qps预估量:一般预估是有开发测试运维同学一起评估。采用8/2原则。即80%的请求访问在20%的时间内到达。此时根据系统pv测算出qps值 峰值qps=（总Pv * 80%）/（60*60*24*20%）。 然后再将峰值qps/单台能承受的最高qps，就是需要的机器数量。 机器数= 总峰值pqs/压测单台机子极限qps...
性能测试中怎么确定TPS
01-14
### 如何在性能测试中计算和确定 TPS #### 定义与重要性 TPS (Transactions Per Second)，即每秒事务数，是衡量系统处理能力的重要指标之一。这一数值反映了单位时间内服务器能够完成的交易数量，直接影响用户体验和服务质量[^1]。 #### 计算基础数据收集 为了准确地计算并设定合理的TPS目标值，在开始之前需先获取一些基本参数： - **预期最大并发用户数**：指在同一时间段内可能同时访问系统的最高人数。 - **单个用户的操作频率**：通常以每次会话期间发起请求的数量来表示。 - **业务高峰期持续时间**：识别一天中的哪些时段流量最为集中。 通过上述三个要素可以初步估计出所需的最小TPS水平[^3]。 #### 应用二八法则优化预估精度 考虑到实际应用场景下的不均匀分布特性，采用二八原则可以帮助更好地贴近真实情况。具体来说就是80%的工作负载集中在20%的时间段里发生。因此即使全天平均下来TPS较低，但在某些特定时刻仍需具备较高的处理能力以应对突发高峰。例如，如果根据历史数据分析得出日常运营状态下平均每秒只需处理约1次请求，则依据此规律推断出峰值时期至少应达到2.3次/秒以上才能确保服务稳定运行[^4]。 #### 设定合理的目标范围 基于前期调研所得的数据以及行业标准或同类产品表现作为参照系，确立一个既具挑战又切实可行的具体数值区间作为最终追求的理想状态。值得注意的是这个过程并非一次性完成而是随着项目进展不断调整完善的过程[^2]。 ```python def calculate_tps(expected_users, operations_per_user, peak_duration_seconds): """ Calculate the estimated Transactions per second. :param expected_users: Expected number of concurrent users during peak time. :param operations_per_user: Average number of transactions initiated by each user within one session. :param peak_duration_seconds: Duration in seconds when most traffic occurs. :return: Estimated minimum required TPS value. """ total_operations = expected_users * operations_per_user tps_estimate = total_operations / peak_duration_seconds # Apply Pareto Principle adjustment factor pareto_adjustment_factor = 2.3 # Based on 80/20 rule from reference material adjusted_tps = tps_estimate * pareto_adjustment_factor return round(adjusted_tps) # Example usage: print(calculate_tps(1000, 5, 60)) # Assuming 1000 concurrent users making an average of 5 requests over a minute's peak period. ```
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值