WEB
QPS
QPS：全名 Queries Per Second，意思是“每秒查询率”，是一台服务器每秒能够响应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
简单的说，QPS = req/sec = 请求数/秒。它代表的是服务器的机器的性能最大吞吐能力。
对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。
原理：每天 80% 的访问集中在 20% 的时间里，这 20% 时间叫做峰值时间。
公式：( 总 PV 数 80% ) / ( 每天秒数 20% ) = 峰值时间每秒请求数（QPS）。
PV（page view）即页面浏览量，通常是衡量一个网络新闻频道或网站甚至一条网络新闻的主要指标。网页浏览数是评价网站流量最常用的指标之一，简称为 PV。
再来看一个计算机器数量的公式：
需要的机器数量：峰值时间每秒 QPS / 单台机器的 QPS。
举个例子，每天 300w PV 打在单台机器上，这台机器需要多少 QPS？
( 3000000 0.8 ) / (86400 0.2 ) = 139 (QPS)。
一般需要达到 139 QPS，因为是峰值。（200 万 PV 才有 100 峰值 QPS）
TPS
TPS：Transactions Per Second（每秒传输的事物处理个数），即服务器每秒处理的事务数。
TPS 包括一条消息入和一条消息出，加上一次用户数据库访问。
TPS是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
一般的，评价系统性能均以每秒钟完成的技术交易的数量来衡量。系统整体处理能力取决于处理能力最低模块的TPS值。
TPS基本类似于 QPS，但是不同的是，对于一个页面的一次访问，形成一个 Tps；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入“Qps”之中。
例如，访问一个 Index 页面会请求服务器 3 次，包括一次 html，一次 css，一次 js，那么访问这一个页面就会产生一个“T”，产生三个“Q”。
RT（响应时长）
响应时间是指：系统对请求作出响应的时间（一次请求耗时）。
PV
页面访问次数：Page View。
UV
访客数（去重复）：Unique Visitor。
吞吐量
系统吞吐量要素：
一个系统的吞吐量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。
系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间
QPS（TPS）：每秒钟request/事务 数量
并发数： 系统同时处理的request/事务数
响应时间： 一般取平均响应时间
（很多人经常会把并发数和TPS理解混淆）
理解了上面三个要素的意义之后，就能推算出它们之间的关系：
QPS（TPS）= 并发数/平均响应时间
并发数 = QPS*平均响应时间
一个典型的上班签到系统，早上8点上班，7点半到8点的30分钟的时间里用户会登录签到系统进行签到。公司员工为1000人，平均每个员上登录签到系统的时长为5分钟。可以用下面的方法计算。
QPS = 1000/(30*60) 事务/秒
平均响应时间为 = 5*60 秒
并发数= QPS平均响应时间 = 1000/(3060) (560)=166.7
一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降。
AB的指标
在学习ab工具之前，我们需了解几个关于压力测试的概念
- 吞吐率（Requests per second）
概念：服务器并发处理能力的量化描述，单位是reqs/s，指的是某个并发用户数下单位时间内处理的请求数。某个并发用户数下单位时间内能处理的最大请求数，称之为最大吞吐率。
计算公式：总请求数 / 处理完成这些请求数所花费的时间，即
Request per second = Complete requests / Time taken for tests - 并发连接数（The number of concurrent connections）
概念：某个时刻服务器所接受的请求数目，简单的讲，就是一个会话。 - 并发用户数（The number of concurrent users，Concurrency Level）
概念：要注意区分这个概念和并发连接数之间的区别，一个用户可能同时会产生多个会话，也即连接数。 - 用户平均请求等待时间（Time per request）
计算公式：处理完成所有请求数所花费的时间/ （总请求数 / 并发用户数），即
Time per request = Time taken for tests /（ Complete requests / Concurrency Level） - 服务器平均请求等待时间（Time per request: across all concurrent requests）
计算公式：处理完成所有请求数所花费的时间 / 总请求数，即
Time taken for / testsComplete requests
可以看到，它是吞吐率的倒数。
同时，它也=用户平均请求等待时间/并发用户数，即
Time per request / Concurrency Level
服务器指标
CPU使用率
内存使用率
系统负载
- 磁盘读写 IOPS
- 内网/公网带宽 bit/s
- 连接数
- Inode使用率
Load（系统负载）
Linux 的 Load 是一个让新手不太容易了解的概念。Load 就是一定时间内计算机有多少个 active_tasks，也就是说是计算机任务执行队列的长度，CPU 计算的队列。
top/uptime 等工具默认会显示 1 分钟、5 分钟、15 分钟的平均 Load。
具体来说，平均 Load 是指，在特定的一段时间内统计的正在 CPU 中运行的（R 状态）、正在等待 CPU 运行的和处于不可中断睡眠的（D 状态）任务数量的平均值。
最后，说一下 CPU 使用率和 Load 的关系吧。如果主要是 CPU 密集型的程序在运行，那么 CPU 利用率高，Load 一般也会比较高。
If CPU utilization is near 100 percent (user + nice + system), the workload sampled is CPU-bound
而 I/O 密集型的程序在运行，可能看到 CPU 的 %user, %system 都不高，%iowait 可能会有点高，这时的 Load 通常也比较高。
同理，程序读写慢速 I/O 设备（如磁盘、NFS）比较多时，Load 可能会比较高，而 CPU 利用率不一定高。这种情况，还经常发生在系统内存不足并开始使用 swap 的时候，Load 一般会比较高，而 CPU 使用率并不高。
Inode
查询Inode使用率
1 | df -i |
碎片文件会占用较多的Inode