zoukankan      html  css  js  c++  java
  • 性能测试--tps---响应时间关键数据的一个方法

    先说结论

    一般推荐,如果你:

    • 没啥人用的服务 tps 20,返回有300ms就行了
    • 十万到百万级的服务,响应能达到tps50 /200ms就可以了
    • 后台服务,能达到tps 20 / 200ms即可(通常后台同时使用也没多少人)
    • 秒杀类的短时间高并发……TPS100或200 在 100ms内响应 应该也能撑一段时间(具体情况还是要看业务量)

    背景

    做项目开发的时候,不止一次被性能测试问“这个服务性能要求是多少?”他期望能得到一个这次接口TPS压到50还是100,返回时间是100ms还是200ms的回答。然后压力测试的脚本就跑起来,挨个接口就去压了。

    但作为产品我怎么知道报多少合适呢?(是的,在某些团队这是研发负责人应该考虑的)。通常我们是只知道业务量,怎么转换成tps、返回时间的要求呢?(有时候业务量都估算不出来,那这种场景下你就按最顶部的推荐的来测吧。)
    现在,只要10分钟,让你了解怎么计算这些内容。

    首先,需要知道不同的产品有不同的应对要求

    • 手机发货的抢购秒杀场景和美团的场景需求不一致,导致产品性能要求就不一致
    • 千万级用户的app和十万级app,同样的性能要求,转换为技术指标上也不一致

    继续计算,我们需要了解

    什么是TPS

    Transactions Per Second(每秒传输的事物处理个数,或者说每秒系统接收的任务数量),系统接收到任务后会有一个处理时间。
    在压力测试时,测试人员会主动按一定tps的量来主动发起接口请求,比如tps=50,就是每秒请求50次,获取一个平均的响应时间(单位一般都是毫秒ms)。压力测试人员口中的TPS50 200ms返回,就是指每秒测试人员主动发起50次请求,这些请求会在平均200ms返回。
    由于其他技术指标如QPS(数据的每秒查询个数)等性能都会在tps这个维度上展示出来,因此可通过tps对系统性能进行简单判断,以满足日常性能测试需求。

    性能测试的指标是怎么来的呢?

    1. 产品和运营要给出业务匡算:
      这个服务,在多长时间段,多少人会访问
    2. 性能要求上,通常情况下的APP应该如何?
      页面访问的2、5、8原理(用户进入服务2s内要展示完所有内容,超过5秒用户就无法忍受了,超过8秒就没有人再等了,直接关闭服务)
      因此页面的渲染时间+资源文件的载入时间+接口的获取时间需要保证1s~2s内完成
    3. 这个条件下接口获取时间多长合适?
      无脑建议200ms以内(考虑到你页面也要2s打开,还要给其他工作留时间)

    怎么通过业务量来计算TPS多少合适呢?

    直接上公式不太好理解,我们先看案例

    案例1,秒杀型算法

    案例的业务量要求

    某业务,类似秒杀型,用户估算有2W左右,每个用户平均请求2次接口(查询用户信息接口、查询业务接口), 这些用户大概率会在2分钟内会访问我们的系统,业务要保证用户2s能打开页面

    TPS的分析

    TPS是系统每秒钟处理的任务数量,给定二业务场景,我们就需要先计算出来每秒需要系统处理多少任务,从而反推在压力测试的时候,需要给多大的TPS了。

    • 首先,整个系统的总请求数=用户(2W)* 每个用户请求数(2次)= 40000次
    • 其次,每秒要求处理的请求数=总请求数/时间(切换到秒) 即约350(333向上取个整吧)。
    • 最后,TPS并发数量与每个请求所消耗的时间,可实际计算出每秒实际能够处理的请求数。
      每秒实际处理请求数量=tps数量 * 1000【1秒,需要切换为毫秒】/单组tps处理时间【这里是按200ms返回】
    • 因此,我们只要保证 每秒实际处理请求数>每秒要求处理的请求数 就可以了。

    最终结果就是
    TPS数量 > 每秒要求处理的请求数 * tps返回时间【按200ms计算】/1000ms

    带入数据计算

    tps>(350 * 200)/1000,具体tps>70。
    因此可让压力测试人员按照tps100来压接口,返回在200ms以内就满足性能要求。
    当然如果实际tps50的返回时间为100ms,则按照这个粗略的公式来推算,也是能够支撑的(350 * 100/1000=35,也就是说tps高于35,返回100ms以内也是可以的)

    案例2,我们来看一个日常服务的算法

    如:一个100w访问的服务,每天访问集中白天8小时,每个用户大约会请求3个接口,每天早上9点是峰值。

    首先计算日均请求数(每秒)
    按8小时 100w访问量、平均3个接口请求计算
    每秒日均请求数=100w(访问量)* 3(每个访问量平均请求接口数)/8(小时)/3600(切换成秒),结果就是每秒请求100次。
    按接口200ms返回,tps需要> 100 * 200/1000,即>20就行了。

    如考虑日常服务的峰值,则按4 * 日均,即每秒请求400次,则tps>80即可,因此可推荐按tps=100来做接口的压力测试。

    相关总结

    1. 时间段越短,数据也越接近于瞬间并发
    2. 如果用整日的数据来计算总请求数,需要按照日流量分布来估算一个峰值数据,日常APP可考虑使用 峰值=4 * 日均【当然还是要看你具体的访问量】

    如果觉得以上繁杂,反正你也可以参考这个结论:

    • 没啥人用的服务 tps 20,返回有300ms就行了
    • 十万到百万级的服务,响应能达到tps50 /200ms就可以了
    • 后台服务,能达到tps 20 / 200ms即可(通常后台同时使用也没多少人)
    • 秒杀类的短时间高并发……TPS100或200 在 100ms内响应 应该也能撑一段时间(具体情况还是要看业务量)




  • 相关阅读:
    新概念第二册(1)--英语口语听力课1
    外企面试课程(一)---熟悉常见的缩略词
    公司 邮件 翻译 培训 长难句 结课
    workflow
    公司 邮件 翻译 培训 长难句 20
    公司 邮件 翻译 培训 长难句 19
    Engineering Management
    公司 邮件 翻译 培训 长难句 18
    公司 邮件 翻译 培训 长难句 17
    第14.5节 利用浏览器获取的http信息构造Python网页访问的http请求头
  • 原文地址:https://www.cnblogs.com/youkongkankan/p/13740155.html
Copyright © 2011-2022 走看看