性能指标
在设计系统时，应该多思考**墨菲定律**
- 任何事情都没表面看起来那么简单。
- 所以事情都会比你预期的时间长。
- 可能出错的事情总会出错。
- 如果你担心某一件发生，那么它就更有可能发生。
在系统划分的时，也要思考**康威定律 **
- 系统架构是公司组织架构的反映。
- 应该按照业务闭环进行系统拆分/组织架构拆分,实现闭环/高内聚/低耦合,减少沟通成本。
- 在合适的时间进行系统拆分,不要一开始就吧系统/服务拆分非常细。虽然闭环，但是每个人维护的系统多,维护成本高。
—亿级流量网站架构核心技术
性能指标
在技术人员的职业生涯中，总是不断开发新的系统。在设计系统的时候，因场景、时间而异。一个系统并不是开始就能设计的非常完美，绝对多数的情况是在有限的资源，优先解决核心问题。并预测可能发生的问题，通过反复迭代的逐步消除痛点。这本身是一个持久性的过程。但是早期优良的架构设计能为未来的工作带来非常大的帮助，如何去评判设计是否合理需要数据佐证。吞吐量、PV、QPS、TPS、RPS、I/O这些指标早设计初期能为开发人员提供非常大的帮助。
- 吞吐量:指单位时间内系统处理用户的请求数,不同的角度评估方式也不同。
- **PV ** : 是Page View的缩写。来自浏览器的一次html内容请求会被看作一个PV。
- QPS：Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
- TPS：是Transactions Per Second的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
- RPS : 是Requests Per Second的缩写,指并发数/平均响应时间。
- I/0 负载: I/O 是 input/output的缩写，即输入输出端口。每个设备都会有一个专用的I/O地址，用来处理自己的输入输出信息。一个系统要能正确工作，必须要有数据通道（data paths）的机制，软件和硬件系统都概莫能外。对于计算机系统而言，必须要有data paths的机制来确保CPU, RAM和I/O设备之间的信息数据能正确的流动。这些data paths,通常被称为总线(BUS)，是计算机内部主要的通信通道。若想深入可以参考 Understanding the Linux Kernel。
吞吐量
一个系统的承压能力。单位时间内完成的工作量的量度。通常，平均响应时间越短，系统吞吐量越大；平均响应时间越长，系统吞吐量越小。但是，系统吞吐量越大，未必平均响应时间越短。因为在某些情况（例如，不增加任何硬件配置）吞吐量的增大，有时会把平均响应时间作为牺牲，来换取一段时间处理更多的请求。
混合场景负载测试，混合场景测试会将多个接口按照实际大促时候的比例混合起来，然后增加线程数找出多个接口 TPS 的和对应的峰值。这个比例也是混合场景的关键。
影响吞吐量的几个重要参数指标
- QPS、TPS、并发数、响应时间、报错率。
名词概述
- 并发数 ： 系统同时处理的 reqeust / 事物数。
- 响应时间 : 一般取reqeust的平均响应时间，很大程度上受客户端环境因素影响。
- TPS （QPS ）: 并发数 / 响应时间。
- 报错率：报错率的计算方式是在统计时间范围内不符合返回期望的请求数除以总共的请求数。
- 状态码的校验，这在性能工具中不需要特别设置，如 4XX、5XX 这样的状态码会直接报错；
- 业务层面的校验，为了保证业务的基本准确性，会通过返回的数据包进行校验；
- 数据库校验， 相对于业务测试，性能测试的每一次请求不会都做数据库校验，这样会影响性能测试结果，我一般会在一轮性能测试之后去统计落库数据的数量和状态是否正常。
流量模型
- 以网络流量左右基础数据，筛选出流量占比、服务级的访问数据统计、根据时间维度评估流量趋势。
系统健壮
- 尽可能早测试、推荐测试驱动开发。
正确率
- 统计网络中流量的正确处理比例。
- 整体处理能力是否稳定，会不会存在处理能力的下滑。
- 接口之间的比例是否稳定，随着时间的进行接口之间的访问比例会不会偏离。
系统响应时间计算
用于测量完成一个特定请求需要花费多少时间。它是一个非常重要的度量值因为它是用户体验的一个指数。尽管这样，你必须确保你理解你测量的是什么：
- 系统级的反应时间。
- 组件级的反应时间。
它们是完全不同的，因为系统级包括像队列时间这样的变量是差别很大的。
值得注意的是，响应时间同时也是不容易测量的度量值，因为它比其它的度量值更容易变化。因此你必需了解反应时间的分布。如果应用对你大部分用户的反应时间是2秒钟，而对10％用户的反应时间却是10秒钟，在这种情况下，你必须知道这个反应时间的分布，才能精确地评估该问题和解决它。这就要测量它们的反应时间并且得到它们的标准偏差，理想的情况是用一个柱状图把反应时间的分布显示出来。
举个🌰 场景：
- 一位用户通过浏览器访问网站查看新闻。栗子中每个操作用别名代替，比如客户请求服务器过程、时间同称N1。
实线（请求），虚线（响应）。
网络传输时间: N1+N2 。
应用服务器处理时间: A1 + A11 OR A2 + A22。
数据库服务器处理时间: D1 + D11 OR D2 + D22。
响应时间 N1+N2+A1+A11+D1+D11 OR N1 + N2 + A2 + A22 + D2 + D22。
假设参数耗时 :
- N1 = 150ms ; N2 = 200ms。
- A1 = 10ms ; A11 = 10ms ; A2 = 10ms ；A22 = 10ms 。
- D1 = 10ms ; D11 = 20ms ; D2 = 20ms ; D22 = 30。
单次reqeust 。
- 流程：P1 = N1–> A1 – > D1 –> D11 – > A11 –> N2。
- 耗时：T1 = N1 + A1 + D1 + D11 + A11 + N2。
- 请求一次网站首页响应时间： 150 + 200 + 10 + 10 + 10 + 20 = 400，也就是客户请求网站地址的那一刻到看到网站至少需要400ms（半秒）。
- 流程：P1 = N1–> A1 – > D1 –> D11 – > A11 –> N2。
并发用户数的计算公式
- 系统用户数: 系统额定的用户数量，如一个OA系统，可能使用该系统的用户总数是4000个，那么这个数量，就是系统用户数。
- 同时在线用户数: 在一定的时间范围内，最大的同时在线用户数量。
- 同时在线用户数 = 每秒请求数RPS(吞吐量) + 并发连接数 + 平均用户思考时间。
- 平均并发用户数的计算: C = nL / T
- C是平均的并发用户数。
- n是平均每天访问用户数(login session)。
- L是一天内用户从登录到退出的平均时间(login session的平均时间)。
- T是考察时间长度(一天内多长时间有用户使用系统)。
- 并发用户数峰值计算: C^约等于C + 3* 根号C 其中 C^ 是并发用户峰值，C 是平均并发用户数，该公式遵循泊松分布理论。
吞吐量的计算公式
- 从业务角度看
- 吞吐量可以用
- 请求数/秒。
- 页面数/秒。
- 人数/天或处理业务数/小时等单位来衡量。
- 吞吐量可以用
- 从网络角度看，吞吐量可以用:
- 字节/秒来衡量
- 对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，他能够说明系统的负载能力。
- 以不同方式表达的吞吐量可以说明不同层次的问题，例如：
- 以字节数/秒方式可以表示数要受网络基础设施、服务器架构、应用服务器制约等方面的瓶颈。
- 已请求数/秒的方式表示主要是受应用服务器和应用代码的制约体现出的瓶颈。
思考时间的计算公式
Think Time，从业务角度来看，这个时间指用户进行操作时每个请求之间的时间间隔，为了模拟这样的时间间隔，引入了思考时间这个概念，来更加真实的模拟用户的操作。
在吞吐量这个公式中 F = VU * R / T说明吞吐量 F 是 VU 数量、每个用户发出的请求数 R 和时间 T 的函数，而其中的 R 又可以用时间T和用户思考时间 TS 来计算：R = T / TS
下面给出一个计算思考时间的一般步骤：首先计算出系统的并发用户数
C = nL / TF = R × C
统计出系统平均的吞吐量
F= VU * R / T R × C = VU * R / T
统计出平均每个用户发出的请求数量
R= uCT / VU
根据公式计算出思考时间
TS= T / R
因素（指标）
资源利用率
这里所谓的资源是对于系统中的一个抽象的概念，它包括很多方面
- reqeust 对 cpu 的消耗：单个reqeust对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。
- 内存负载： 系统对系统内存、vm虚拟内存、swap交换区的使用情况。
- iO负载消耗 (这里的IO负载是指硬盘IO ，并不是网络IO): 系统在运行中常常会涉及到大量的磁盘读写操作。磁盘有两个重要的参数: Seek time、 Rotational latency。正常的I/O计数为：1000/(Seek time+Rotational latency)*0.75 在此范围内属正常。当达到85％的I/O计数以上时则基本认为已经存在I/O瓶劲。理论情况下，磁盘的随机读计数为125、顺序读计数为225。对于数据文件而言是随机读写，日志文件是顺序读写。
外部接口
- 一个系统会将系统内的功能封装成接口(RESTFUL、SOAP)的形式向外部提供，这些外部接口和内部的代码处理逻辑是强关联的。比如使用到支付包，在一个支付reqeust中需要发起对支付接口的请求完成整个业务流程。
PV
- PV（page view）即页面浏览量，通常是衡量一个网络新闻频道或网站甚至一条网络新闻的主要指标。网页浏览数（page view）是评价网站流量最常用的指标之一，简称为PV。搜索引擎会根据网站的PV来判断网站的好与坏，是影响网站排名的重要因素之一。
- 一般看新闻也就集中在早上、中午、晚上。假设早上7:30 - 8:30网站有会很大访问量大概3500左右。
QPS、TPS
每秒钟request/事务数量，一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。
事务可以从客户端角度进行定义。如：
- 一个登录的POST请求可定义为一个事务。
- 一个文件上传下载的动作也可定义为一个事务。
- 一组连续的请求操作也可定义一个事务。
事务也可从服务器端定义，如：
- 执行一个数据库事务。
- 执行一段存储过程。
- 执行一个服务器请求等。
理解了事务，再理解TPS，TPS需要结合性能测试场景来说明：
- 单体
- 本次测试只测登录这一功能，便于分析和寻找瓶颈。
- 也可做并发测试。
- TPS = 总事务数 / 总时间(秒)。
- 混合
- 多种模块一起进行测试，更符合真实场景，便于对服务器的整体处理能力进行评估。
- TPS=单个事务的TPS总和。
大多数情况下，我们使用加权协函数平均方法来计算客户机的得分，利用客户机的这些信息使用加权协函数平均方法来计算服务器端的整体TPS得分。
RPS
每秒请求数，这里还有两个我们通常认为和RPS相等的名词，arrival rate、TPS。
IO
基准场景
基准场景是指单线程或者少量线程（一般在 5 个线程以下）对单接口进行测试，然后将测试结果作为基准数据，在系统调优或者评估的过程中，通过运行相同的业务接口比较测试结果，为系统的优化以及后续测试流程提供决策数据。
验证测试脚本及测试参数的正确性，同时也可以验证脚本数据是否能够支持重复性测试等；
通过少量线程访问系统获取结果数据，作为对比参考基准；
根据测试结果，初步判断可能成为系统瓶颈的场景，并决定是否进行后续的测试；
基准场景的结果被一部分公司作为上线的基线指标，不达到要求是不允许上线的，这样的场景也经常被固化成自动化的脚本定时触发和巡检。
单接口负载能力
- 单接口负载场景就是通过模拟多线程对单接口进行负载测试。选定线程数后持续循环运行一定时间，比如分别运行 100 线程、200 线程、300线程等，一般相同线程数运行 10～15 min，然后获取事务响应时间、TPS、报错率，监测测试系统的各服务器资源使用情况（CPU、内存、磁盘、网络等），把具体数据记录之后再开始跑下一个线程数。每一组线程数级别会有对应的 TPS，直到你找到 TPS 的拐点。