QPS Queries Per Second 是每秒查询率 ,是一台服务器每秒可以相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准, 即每秒的响应请求数，也便是最大吞吐能力。面试
TPS Transactions Per Second也就是事务数/秒。一个事务是指一个客户机向服务器发送请求而后服务器作出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数， redis
三、QPS和TPS区别数据库
我的理解以下： 服务器
一、Tps即每秒处理事务数，包括了微信
这三个过程，每秒可以完成N个这三个过程，Tps也就是N；网络
二、Qps基本相似于Tps，可是不一样的是，对于一个页面的一次访问，造成一个Tps；但一次页面请求，可能产生屡次对服务器的请求，服务器对这些请求，就可计入“Qps”之中。架构
例子：并发
例如：访问一个页面会请求服务器3次，一次放，产生一个“T”，产生3个“Q”例如：一个大胃王一秒能吃10个包子，一个女孩子0.1秒能吃1个包子，那么他们是否是同样的呢？答案是否认的，由于这个女孩子不可能在一秒钟吃下10个包子，她可能要吃好久。这个时候这个大胃王就至关于TPS，而这个女孩子则是QPS。虽然很类似，但实际上是不一样的。app
四、并发数运维
并发数（并发度）：指系统同时能处理的请求数量，一样反应了系统的负载能力。这个数值能够分析机器1s内的访问日志数量来获得
吞吐量是指系统在单位时间内处理请求的数量，TPS、QPS都是吞吐量的经常使用量化指标。
系统吞吐量要素
一个系统的吞吐量（承压能力）与request（请求）对cpu的消耗，外部接口，IO等等紧密关联。
单个request 对cpu消耗越高，外部系统接口，IO影响速度越慢，系统吞吐能力越低，反之越高。
重要参数
QPS(TPS),并发数，响应时间
关系
QPS(TPS)=并发数/平均响应时间
一个系统吞吐量一般有QPS(TPS),并发数两个因素决定，每套系统这个两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统吞吐量就上不去了，若是压力继续增大，系统的吞吐量反而会降低，缘由是系统超负荷工做，上下文切换，内存等等其余消耗致使系统性能降低。
PV（Page View）：页面访问量，即页面浏览量或点击量，用户每次刷新即被计算一次。能够统计服务一天的访问日志获得。
UV（Unique Visitor）：独立访客，统计1天内访问某站点的用户数。能够统计服务一天的访问日志并根据用户的惟一标识去重获得。响应时间（RT）：响应时间是指系统对请求做出响应的时间，通常取平均响应时间。能够经过Nginx、Apache之类的Web Server获得。
DAU(Daily Active User)，日活跃用户数量。经常使用于反映网站、互联网应用或网络游戏的运营状况。DAU一般统计一日（统计日）以内，登陆或使用了某个产品的用户数（去除重复登陆的用户），与UV概念类似
MAU(Month Active User)：月活跃用户数量，指网站、app等去重后的月活跃用户数量
咱们在作系统设计的时候就须要考虑CPU运算，IO，外部系统响应因素形成的影响以及对系统性能的初步预估。
而一般状况下，咱们面对需求，咱们评估出来的出来QPS，并发数以外，还有另一个维度：日pv。
经过观察系统的访问日志发现，在用户量很大的状况下，各个时间周期内的同一时间段的访问流量几乎同样。好比工做日的天天早上。只要能拿到日流量图和QPS咱们就能够推算日流量。
一般的技术方法：
一、找出系统的最高TPS和日PV，这两个要素有相对比较稳定的关系（除了放假、季节性因素影响以外）
二、经过压力测试或者经验预估，得出最高TPS，而后跟进1的关系，计算出系统最高的日吞吐量。B2B中文和淘宝面对的客户群不同，这两个客户群的网络行为不该用，他们之间的TPS和PV关系比例也不同。
软件作性能测试时须要关注哪些性能呢？
首先，开发软件的目的是为了让用户使用，咱们先站在用户的角度分析一下，用户须要关注哪些性能。
对于用户来讲，当点击一个按钮、连接或发出一条指令开始，到系统把结果已用户感知的形式展示出来为止，这个过程所消耗的时间是用户对这个软件性能的直观印 象。也就是咱们所说的响应时间，当相应时间较小时，用户体验是很好的，固然用户体验的响应时间包括我的主观因素和客观响应时间，在设计软件时，咱们就须要 考虑到如何更好地结合这两部分达到用户最佳的体验。如：用户在大数据量查询时，咱们能够将先提取出来的数据展现给用户，在用户看的过程当中继续进行数据检 索，这时用户并不知道咱们后台在作什么。
用户关注的是用户操做的相应时间。
其次，咱们站在管理员的角度考虑须要关注的性能点。
一、 响应时间
二、 服务器资源使用状况是否合理
三、 应用服务器和数据库资源使用是否合理
四、 系统可否实现扩展
五、 系统最多支持多少用户访问、系统最大业务处理量是多少
六、 系统性能可能存在的瓶颈在哪里
七、 更换那些设备能够提升性能
八、 系统可否支持7×24小时的业务访问
再次，站在开发（设计）人员角度去考虑。
一、 架构设计是否合理
二、 数据库设计是否合理
三、 代码是否存在性能方面的问题
四、 系统中是否有不合理的内存使用方式
五、 系统中是否存在不合理的线程同步方式
六、 系统中是否存在不合理的资源竞争
来源：
https://juejin.im/post/5c2cb5...
最新整理的 2TB 技术干货：包括架构师实战教程、大数据、Docker容器、系统运维、数据库、redis、MogoDB、电子书、Java基础课程、Java实战项目、ELK Stack、机器学习、BAT面试精讲视频等。只需在「 民工哥技术之路」微信公众号对话框回复关键字：1024便可获取所有资料。