QPS、TPS、并发用户数、吞吐量关系

1、QPS

---

QPS Queries Per Second  是每秒查询率 ,是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准, 即每秒的响应请求数，也即是最大吞吐能力。

2、TPS

---

TPS Transactions Per Second  也就是事务数/秒。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，

3、QPS和TPS区别

---

个人理解如下：

1、Tps即每秒处理事务数，包括了

• 用户请求服务器  

• 服务器自己的内部处理  

• 服务器返回给用户

这三个过程，每秒能够完成N个这三个过程，Tps也就是N；

2、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)：每秒钟request/事务 数量

• 并发数：系统同时处理的request/事务数

• 响应时间：一般取平均响应时间

关系

QPS(TPS)=并发数/平均响应时间

一个系统吞吐量通常有QPS(TPS),并发数两个因素决定，每套系统这个两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换，内存等等其他消耗导致系统性能下降。

6、PV

---

PV（Page View）：页面访问量，即页面浏览量或点击量，用户每次刷新即被计算一次。可以统计服务一天的访问日志得到。 

7、UV 

---

UV（Unique Visitor）：独立访客，统计1天内访问某站点的用户数。可以统计服务一天的访问日志并根据用户的唯一标识去重得到。响应时间（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我们就可以推算日流量。

通常的技术方法：

1、找出系统的最高TPS和日PV，这两个要素有相对比较稳定的关系（除了放假、季节性因素影响之外）

2、通过压力测试或者经验预估，得出最高TPS，然后跟进1的关系，计算出系统最高的日吞吐量。B2B中文和淘宝面对的客户群不一样，这两个客户群的网络行为不应用，他们之间的TPS和PV关系比例也不一样。

11、软件性能测试的基本概念和计算公式

---

软件做性能测试时需要关注哪些性能呢？

首先，开发软件的目的是为了让用户使用，我们先站在用户的角度分析一下，用户需要关注哪些性能。

对于用户来说，当点击一个按钮、链接或发出一条指令开始，到系统把结果已用户感知的形式展现出来为止，这个过程所消耗的时间是用户对这个软件性能的直观印 象。也就是我们所说的响应时间，当相应时间较小时，用户体验是很好的，当然用户体验的响应时间包括个人主观因素和客观响应时间，在设计软件时，我们就需要 考虑到如何更好地结合这两部分达到用户最佳的体验。如：用户在大数据量查询时，我们可以将先提取出来的数据展示给用户，在用户看的过程中继续进行数据检 索，这时用户并不知道我们后台在做什么。

用户关注的是用户操作的相应时间。

其次，我们站在管理员的角度考虑需要关注的性能点。

1、 响应时间
2、 服务器资源使用情况是否合理
3、 应用服务器和数据库资源使用是否合理
4、 系统能否实现扩展
5、 系统最多支持多少用户访问、系统最大业务处理量是多少
6、 系统性能可能存在的瓶颈在哪里
7、 更换那些设备可以提高性能
8、 系统能否支持7×24小时的业务访问

再次，站在开发（设计）人员角度去考虑。

1、 架构设计是否合理
2、 数据库设计是否合理
3、 代码是否存在性能方面的问题
4、 系统中是否有不合理的内存使用方式
5、 系统中是否存在不合理的线程同步方式
6、 系统中是否存在不合理的资源竞争

来源：http://suo.im/63c1WA

- END -

Kubernetes全栈技术培训

往期精彩文章

kubernetes全栈技术+企业案例演示【带你快速掌握和使用k8s】

突破运维和开发瓶颈、Python、k8s、DevOps转型一网打尽！

python运维开发实战-基础篇

python运维和开发实战-高级篇

python运维和开发实战-安装和创建Django项目

Docker公司禁止被列入美国"实体名单"的国家、企业使用

Jenkis pipeline构建项目实践-编写podTemplate实现和k8s对接

安装kubernetes集群-灵活安装k8s各个版本高可用集群

Kubernetes v1.19 正式发布

高效的Nginx负载均衡器

5个维度对 Kubernetes 集群优化

kubernetes面试题汇总

DevOps视频和资料免费领取

kubernetes技术分享-可用于企业内部培训

谈谈我的IT发展之路

kubernetes系列文章第一篇-k8s基本介绍

kubernetes系列文章第二篇-kubectl

了解pod和pod的生命周期-这一篇文章就够了

Kubernetes中部署MySQL高可用集群

Prometheus+Grafana+Alertmanager搭建全方位的监控告警系统-超详细文档

k8s1.18多master节点高可用集群安装-超详细中文官方文档

k8s中蓝绿部署、金丝雀发布、滚动更新汇总

运维常见问题汇总-tomcat篇

关于linux内核参数的调优，你需要知道

kubernetes挂载ceph rbd和cephfs

报警神器Alertmanager发送报警到多个渠道

jenkins+kubernetes+harbor+gitlab构建企业级devops平台

kubernetes网络插件-flannel篇

kubernetes网络插件-calico篇

kubernetes认证、授权、准入控制

限制不同的用户操作k8s资源

面试真题&技术资料免费领取-覆盖面超全~

Prometheus监控MySQL

Prometheus监控Nginx

Prometheus监控Tomcat

linux面试题汇总

测试通过storageclass动态生成pv

通过编写k8s的资源清单yaml文件部署gitlab服务

helm安装和使用-通过helm部署k8s应用

k8s基于Ingress-nginx实现灰度发布

k8s的Pod安全策略

Prometheus Operator-上篇-安装和使用篇

Prometheus Operator-下篇

通过kubeconfig登陆k8s的dashboard ui界面

通过token令牌登陆k8s dashboard ui界面 

kubernetes集群的etcd数据库详细介绍

Linux网络流量监控工具

kubernetes搭建EFK日志管理系统

prometheus operator监控k8s集群之外的haproxy组件         

kubernetes ConfigMap存储卷                                           

技术交流

学无止境，了解更多关于kubernetes/docker/devops/openstack/openshift/linux/IaaS/PaaS相关内容，想要获取更多资料和免费视频，可按如下方式进入技术交流群

微信：luckylucky421302

按如下指纹可关注