1、QPS
QPS：Queries Per Second，是每秒查询率，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，即每秒的响应请求数，也即是最大吞吐能力。
2、TPS
TPS：Transactions Per Second，也就是事务数/秒。
一个事务是指一个客户机向服务器发送请求后，服务器所做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
3、QPS和TPS区别
个人理解如下：
一方面，Tps即每秒处理事务数，包括用户请求服务器、服务器自己的内部处理、服务器返回给用户三个过程。
每秒能够完成N个这样的“三个过程”，Tps也就是N。
另一方面，Qps基本类似于Tps，但不同的是，对于一个页面的一次访问，形成一个Tps；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求就可计入“Qps”之中。
举例说明，访问一个页面会请求服务器3次，一次放，产生一个“T”，产生3个“Q”。
这就好比一个大胃王一秒能吃10个包子，一个女孩子0.1秒能吃1个包子，那么这俩人是不是一样的呢？答案是否定的。因为这个女孩子不可能在一秒钟吃下10个包子，她可能要吃很久。而这个大胃王就相当于TPS，而这个女孩子则是QPS。虽然很相似，但其实是不同的。
4、并发数
并发数（并发度）：指系统同时能处理的请求数量，同样反应了系统的负载能力，这个数值可以分析机器1s内的访问日志数量。
5、吐吞量
吞吐量：指系统在单位时间内处理请求的数量，TPS和QPS都是吞吐量的常用量化指标。
系统吞吐量的要素如下：
一个系统的吞吐量（承压能力）与request（请求）对CPU的消耗、外部接口、IO等紧密关联；
单个request对CPU消耗越高、外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。
它们的关系可以表示为：QPS（TPS）=并发数/平均响应时间
一个系统吞吐量通常有QPS（TPS）和并发数两个因素决定，在每套系统中，这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等其它消耗导致系统性能下降。
6、PV
PV：Page View，页面访问量，即页面浏览量或点击量，用户每次刷新即被计算一次，可以统计服务一天的访问日志得到。
7、UV
UV：Unique Visitor，独立访客，统计一天内访问某站点的用户数，可以统计服务一天的访问日志，并根据用户的唯一标识去重得到。
响应时间（RT）：指系统对请求作出响应的时间，一般取平均响应时间，可以通过Nginx、Apache之类的Web Server得到。
8、DAU
DAU：Daily Active User，日活跃用户数量，常用于反映网站、互联网应用，或网络游戏的运营情况。
DAU通常统计一日（统计日）之内，登录或使用了某个产品的用户数（去除重复登录的用户），与UV概念相似。
9、MAU
MAU：Month Active User，月活跃用户数量，指网站、APP等去重后的月活跃用户数量。
10、系统吞吐量评估
我们在做系统设计的时候，就需要考虑CPU运算、IO、外部系统响应因素造成的影响，以及对系统性能的初步预估。
而通常情况下，我们面对需求所评估出来的QPS、并发数之外，还有另外一个维度，那就是日PV。
通过观察系统的访问日志可以发现，在用户量很大的情况下，各个时间周期内的同一时间段的访问流量几乎一样。比如，工作日的每天早上，只要能拿到日流量图和QPS，我们就可以推算日流量。
通常的技术方法有两种：
一是，找出系统的最高TPS和日PV，这两个要素有着相对比较稳定的关系（除了放假、季节性因素影响之外）；
二是，通过压力测试或者经验预估得出最高TPS，然后跟进1的关系，计算出系统最高的日吞吐量。B2B中文和淘宝面对的客户群不一样，这两个客户群的网络行为不应用，他们之间的TPS和PV关系比例也不一样。
11、软件性能测试的基本概念和计算公式
软件做性能测试时，需要关注哪些性能呢？
首先，开发软件的目的是为了让用户使用，所以我们先站在用户的角度分析一下，用户需要关注哪些性能。
对于用户来说，当点击一个按钮、链接或发出一条指令开始，到系统把结果已用户感知的形式展现出来为止，这个过程所消耗的时间是用户对这个软件性能的直观印象，也就是我们所说的响应时间。当相应时间较小时，用户体验是很好的。当然，用户体验的响应时间包括个人主观因素和客观响应时间，在设计软件时，我们需要考虑到如何更好地结合这两部分达到用户最佳的体验。
比如，用户在大数据量查询时，我们可以将先提取出来的数据展示给用户，在用户看的过程中继续进行数据检索。这时候，用户并不知道我们在后台做了什么，而用户关注的是用户操作的相应时间。
其次，我们站在管理员的角度，看看需要关注哪些性能。
◆ 响应时间；
◆ 服务器资源使用情况是否合理；
◆ 应用服务器和数据库资源使用是否合理；
◆ 系统能否实现扩展；
◆ 系统最多支持多少用户访问、系统最大业务处理量是多少；
◆ 系统性能可能存在的瓶颈在哪里；
◆ 更换那些设备可以提高性能；
◆ 系统能否支持7×24小时的业务访问。
再次，我们站在开发（设计）人员的角度去考虑一下。
◆ 架构设计是否合理；
◆ 数据库设计是否合理；
◆ 代码是否存在性能方面的问题；
◆ 系统中是否有不合理的内存使用方式；
◆ 系统中是否存在不合理的线程同步方式；
◆ 系统中是否存在不合理的资源竞争。
免责声明：本文系网络转载，版权归原作者所有。如有问题，请联系删帖，谢谢！
↑↑ 扫码关注更多精彩内容
|
楼主
标题置顶
标题高亮
