目录
一.概要
二.指标
1、QPS(Queriespersecond ) )。
2、传输密码(TPS )。
2、RT(RES(onsetime ) ) ) ) ) ) ) ) )。
3、同时数
4、吞吐量(Throughput )。
5、页面视图)。
6、通用可视化(uv ) )。
7、负载)系统负载
三.结束
一、概括分布式、微服务、服务mesh是现在大家耳熟能详的词汇，现在不管哪个互联网公司说了大家都在做微服务。
但是，我们要试试看，怎么衡量APP的当前状态怎么样？ 需要扩张吗？ 需要横向扩展还是需要重建项目？
此时，需要大量监控指标来分析当前的APP应用程序的状态，以便在发生某些事故之前调配或优化资源。
在此，让我阐述一下这些重要指标。 请一定要记住。 无论是面试还是自己用，都必须滴下。
请记住。 所有指标都是根据时间单位计算的。 例如，每秒XX，每分钟XX。 请记住这个大前提。 以下均以秒为单位进行计算。
二、指标1、QPS(Queriespersecond )概念：服务器每秒可处理的查询次数是服务器每秒可处理的查询次数。 如果用户在一秒钟内完成了50次查询请求，则服务器QPS为50，用户只启动一次查询请求并响应服务器。
2、传输密码(TPS )概念：服务器每秒处理的事务数量，其中之一是用户发起查询并向服务器响应。 纳尼？ 这不是QPS的概念吗？划重点，这里就要说清楚一个概念了，在针对单接口，TPS可以认为是等价于QPS的，如访问 ‘order.html’ 这个页面而言，是一个TPS。而访问 ‘order.html’ 页面可能请求了3此服务器（如调用了css、js、order接口），这实际就算产生了三个QPS
因此，总结起来，对于单接口，TPS=QPS，否则QPS是实际请求次数的第几次。
2、rt(RES ) onsetime )概念：实际响应是指从客户端请求开始到服务器响应结果的时间。 RT这一参数是系统最重要的指标之一，其大小直接反映了当前系统的响应状态。 基本上与我们的用户体验密切相关，但目前监控系统一般有平均、最大、最小三个RT。
一般的系统一般在RT 100ms以内，300ms才可以接受，但是1s加上了其他的外因，给用户带来体验真的很不愉快。
3、同时数的概念：系统能够同时处理的请求数量，很多人往往混淆了对同时数和TPS的理解。 例如，如果客户端请求启动三个请求(css、js和index接口)的index.html页，则TPS=1、QPS=3和并发计数为3。
>SO，计算公式 ：QPS=并发数/RT || 并发数=QPS*RT 4、吞吐量（Throughput）概念：每秒承受的用户访问量，吞吐量（系统能承受多少压力）和当前请求对CPU消耗、内存、IO使用等等紧密相关。单个请求消耗越高，系统吞吐量越低，反之越高。
一个系统的吞吐量和其TPS 、QPS、并发数息息相关，每个系统针对这些值都有一个相对极限值，只要其中某一个达到最大，系统的吞吐量也就到达极限了。如此时压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，各种资源切换等等的消耗导致系统性能下降。
关系：
所以，理解上面几个关系后，就可以推算出：
QPS（TPS）= 并发数/平均响应时间
5、PV（Page View）概念：即每个页面的浏览次数，用户每次刷新就算一次。
6、UV（Unique Visitor）概念：独立访客数，每天访问的用户数，此数据需要根据用户唯一标识进行去重。
7、Load（系统负载）概念：此数据指的是Linux系统的负载情况，也就是咱们平时所用Top命令时，最上面显示的数据信息( load average: 0.1, 0.2, 0.5)。此时会显示1分钟、5分钟、15分钟的系统平均Load，很显然load average 的值越低，你的系统负荷越小。
简单的说下这个值应该怎么看，如果你是单核cpu,那此值为1的时候就是系统已经满负荷状态了，需要你马上去解决。但实际经验告诉我们，当系统负荷持续大于0.7的时候（也就是70%），就需要你马上来解决问题了，防止进一步恶化。
为什么需要三个值 load average: 0.1, 0.2, 0.5，其实就是给你个参考。比如只有1分钟的是1，其他俩都是0.1，这表明只是临时突发的现象，问题不大。如果15分钟内，系统负荷都是1或大于1，那表明问题持续存在啊。所以你应该主要观察15分钟的系统负荷。
三、结束好了，简单又开心的概念说完了。可以继续进行我的王者大业了——荣耀王者在等待着我。