Java web应用性能分析之性能指标【TPS和QPS】

Client:客户浏览器，比如Chrome等访问WEB页面
Load Machine:生成负载的机器，即我们的压测机器用来模拟用户负载②
Web Server:提供Web服务的服务器，即我们访问的Web页面由此中间件提供服务，比如Nginx等
Middlerware:中间件，比如Tomcat jboss webLogical等
OS：操作系统
System Resource:系统硬件资源③
App Server:应用服务，实现业务逻辑，比如生成统计
DB：数据库分别对应的调优参数：
①
RT：响应时间，一个业务逻辑的完成时间
TPS：每秒完成的事务数
CPU：CPU性能指标，比如cpu利用率/负载
Mem：内存性能指标，比如可用物理内存/虚拟内存使用率
Diks：Disk性能指标，比如Disk Time io等待
Network: 网络指标②
Tcp Connections:指TCP连接数，可以用netstat命令统计得到
Thread Pool：建建建建立的线程池，监控线程状态
JVM: JVM性能指标，比如GC情况，heap使用情况。
Load Average: CPU负载队列长度③
DB Connections: 中间件与数据库之间建立的连接数及链接状态④
DB Time：消耗在数据库操作上的CPU时间
TOP SQL：按内存占用有多到少排序SQL,按CPU占用由多到少排序sql
PGA/SGA内存使用情况

        

先说结论
一般推荐，如果你：

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

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

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

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

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

继续计算，我们需要了解TPS、QPS。

        Transactions Per Second（每秒传输的事物处理个数），即服务器每秒处理的事务数。TPS包括一条消息入和一条消息出，加上一次用户数据库访问。

        TPS是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。一般的，评价系统性能均以每秒钟完成的技术交易的数量来衡量。系统整体处理能力取决于处理能力最低模块的TPS值。

        Queries Per Second（每秒查询率）QPS每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。

对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。

        qps即每秒处理事务数，包括了用户请求服务器、服务器自己的内部处理、服务器返回给用户。这三个过程，每秒能够完成N个这三个过程，Tps也就是N；Qps基本类似于Tps，但是不同的是，对于一个页面的一次访问，形成一个Tps；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入“Qps”之中。

实际举例
        我们通过一个实例来把上面几个概念串起来理解。按二八定律来看，如果每天 80% 的访问集中在 20% 的时间里，这 20% 时间就叫做峰值时间。

        公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS) 
        机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器
        1、每天300w PV 的在单台机器上，这台机器需要多少QPS？ 
        ( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)

        2、如果一台机器的QPS是58，需要几台机器来支持？
        139 / 58 = 3

系统吞吐量

        一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。

        系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间、QPS（TPS）：每秒钟request/事务 数量、并发数： 系统同时处理的request/事务数、 响应时间： 一般取平均响应时间。

系统响应时长变化

        随着并发数的增加，系统响应时间的变化可以分为三个阶段。

第一阶段

        低负载阶段，系统资源利用率很低，系统响应时间随着并发数增加变化不明显，也可以理解为并发数增加并未对系统响应时长造成太大影响。

第二阶段

        高负载阶段，系统利用率较高，系统响应时长随着并发数增加出现大幅增长，在此阶段并发数对系统响应时长的影响很大，其主要原因是因为系统资源满载了，请求数量大于 CPU 的核心数，导致进程或者线程不断切换，响应耗时增大。

第二阶段

        过载阶段，系统利用率接近最大，系统过载。由于请求数量远大于 CPU 核心数量，系统为了处理如此大量的请求，进程（线程）频繁切换，导致系统响应时长成指数增长。