例如你在某家电商公司，你可能会遇到这种场景
| 运营和产品神秘兮兮的跑过来问： |
| 我们晚上要做搞个促销，服务器能抗住么？如果扛不住，需要加多少台机器？ |
| 你作为技术一脸懵逼。 |
其实，这些都是系统容量预估的问题，容量预估是架构师必备的技能之一。
而所谓，容量预估其实说白了就是：
根据预估的、整个集群在未来一段时间内、将要承受的最大流量，来估算出整个集群需要具备的容量，以此作为是否需要扩容的依据。
这需要你掌握常见的集群性能指标以及估算方法
| 一般统计时间为一天，所以如果没有特殊说明、我们平时常说的pv与uv都是指日pv与日uv |
| |
| PV全称：Page View |
| 页面访问量，即页面浏览量或点击量。 |
| 同一个用户访问了4次页面，就代表4个PV，但只能计为一次UV |
| 强调：你访问一个页面，该页面加载过程中向后台发送了10个请求，那也只能记录为1pv，即pv计算的是页面访问量，而不是包含的请求数 |
| |
| UV全称：Unique Visitor |
| 独立访客，统计1天内访问某站点的用户数。一个用户多次访问只计为1次 |
| |
| 对于未来的PV与UV技术人员是不知道的，因为你们公司可能正在策划一场 |
| 营销活动，只有运营、产品相关同学才能大概知晓本场活动大概会吸引多少 |
| 用户在什么时间段内进来，这需要你们充分沟通之后才能大概确定。当然 |
| 了有没有可能活动是失败了，一个用户都没有来，当然有可能了。 |
| |
| 平时你作为运维想得到日常已经发生了的pv与uv可以通过nginx的access.log预估。 |
| 1.根据访问IP统计UV |
| awk '{print $1}' access.log|sort | uniq -c |wc -l |
| |
| 2.统计访问URL统计PV |
| awk '{print $7}' access.log|wc -l |
| QPS（Queries Per Second）指的是每秒钟的处理完成的请求量。 |
| 强调两个关键点 |
| 1、在计算QPS时，是以请求被成功处理（服务端已经生成了响应并发送出去）为依据，无论这个请求最终是否被客户端接收到 |
| 即如果一个请求尚未处理完成，就不会被计算在QPS之内。只有当请求被服务器成功处理并且已经发出响应，才会被计入QPS。 |
| 2、QPS统计的是一段时间内被处理的请求数，公式为：完成处理的总请求数/时间段(单位为s) |
| |
| 例如：服务器访问日志里10s内成功响应了100次请求（例如请求的返回状态码都是200） |
| qps=100/10 得到qps为10，表示每秒可以处理完成10个请求 |
| |
| 计算案例：我们预估一个网站每天有10w活跃用户，称之为10w日活，每人平均访问4个页面，每个页面平均衍生4个接口请求 |
| 10w*4*4 = 160w个请求 |
| 一般人睡觉8个小时 so 一天 24-8=16h |
| 160W个请求 / (16h * 60 * 60) = 27qps |
| |
| 强调上面是预估的量，肯定不是准确的量啊，没有人可以预测准确的未来。 |
| 每秒处理完的事务数目。它主要用于衡量系统的处理能力。 |
| 在一个系统中，事务通常被定义为一系列的操作，这些操作作为一个整体，要么全部成功，要么全部失败。 |
| 每个事务可能包含多个请求和响应。 |
| 例如，在电商系统中，一个事务可能包括查找商品，添加到购物车，和完成支付等步骤。 |
| 因此，TPS的高低体现了系统在单位时间内处理事务的能力 |
| 举个例子： |
| 一秒内完成购买了某个商品的动作，但是该动作内包含了一次查找商品请求、一次添加购物扯请求，一次支付请求 |
| 那计为1个“TPS”，但是记为3个“QPS”。 |
| 响应时长通常是指一个请求（注意指的是单个请求）从客户端发送请求到服务器返回响应的总时间， |
| 包括 |
| 1、网络传输时间 |
| 2、服务器处理时间 |
| 3、以及客户端接收时间等。 |
| 在计算平均响应时间时，通常会将多次请求的响应时间求平均值。 |
| 每次请求的响应时间是从发送请求到接收到响应的整个过程所花费的时间。 |
| 因此，平均响应时间是多次请求的总响应时间除以请求数量，以反映系统的整体响应效率。 |
| 页面的加载完成时间：这是用户在打开一个网页时，从发送请求到页面所有内容完全显示出来所需的时间。 |
| 这个时间的长短会直接影响到用户的体验。 |
| 页面加载时间受到许多因素的影响，包括网络速度，服务器响应时间，以及页面内容的大小等。 |
| 一个页面要想加载出来，或包含很多个请求，你可以打开浏览器随便访问一个网页然后F12看看就知道了 |
| 一个页面涉及到很多资源请求例如 |
| 1、HTML |
| 2、CSS |
| 3、JS |
| 4、图片等 |
| |
| RT响应时长和页面加载完成时长的区别 |
| 1、前者是衡量的就是一个请求的响应速度 |
| 2、后者是一整个页面的加载速度，包含了很多请求 |
| |
| TPS与页面加载时间是截然不同的指标 |
| 1、二者衡量的是系统不同方面的性能，前者是系统处理事务的能力，后者是用户体验的直观体现。 |
| 2、TPS是以完成的事务个数为计量单位的，一个事务里包含了很多请求操作，这些请求操作 |
| 可能隶属于不同的页面 |
| 3、如果你非要将TPS与一个页面加载时间比较一下的话，我只能告诉你，一个事务通常会跨域 |
| 多个页面，你就想想你平时网购一个商品就明白了 |
关于一个页面的加载完成时间，衍生的请求数目、可以随便访问一个网页，然后用浏览器开发者工具查看
访问某一个页面，注意就是一个页面，然后F12打开谷歌浏览器调试模式，可以看到请求请求
| 在浏览器的开发者工具中， |
| |
| 1、请求数：一个页面或有很多衍生请求，注意，是在一个页面访问中产生了27次请求 |
| 2、已通过网络传输了xxx大小：指的是本次刷新页面，涉及到数据传输如HTML、CSS、JavaScript、图片、响应协议头等的总大小。 |
| 3、网页加载了xxx大小的资源：指的是浏览器渲染呈现出来的数据量，要知道浏览器渲染的一些内容可能直接来自于本地 |
| 缓存，这部分缓存不加入传输的数据量的，但必然是计入加载了的数据量 |
| 4、完成用时：指页面加载完成所花费的总时间。这包括了从发出第一个网络请求到最后一个网络请求完成的时间 |
| 以及浏览器加载渲染的时间 |
| |
| 总的来说， |
| “已传输”的数据量更侧重于网络传输过程中的数据量， |
| 而“网页加载了的数据量”则更关注整个页面加载过程中实际被处理的数据量，包括解析和渲染等过程。 |
