1. 性能指标
- PV（Page View）：页面浏览量，即网站或页面被访问的次数。每次用户加载或刷新页面，都会计为一次 PV。
- UV（Unique Visitor）：独立访客数，指在一定时间内访问网站的不同用户数量。通过识别用户的唯一标识（如 IP 地址、Cookie 等）来统计。
- 吞吐量：指系统在单位时间内处理的请求数量或数据量。通常用于衡量系统的处理能力。
- QPS（Queries Per Second）：每秒查询量，表示系统每秒能够处理的查询请求数量。
- TPS（Transactions Per Second）：每秒事务量，一个事务可能包含多个查询或操作，TPS 衡量系统每秒能够完成的事务数量。
- RT（Response Time）：响应时间，指从发送请求到收到响应所经过的时间。通常以毫秒为单位。
- 并发量：指系统同时处理的请求或用户数量。
- DAU（Daily Active User）：日活跃用户数，在一天内至少使用过一次产品的用户数量。
- MAU（Monthly Active User）：月活跃用户数，在一个月内至少使用过一次产品的用户数量。
2. 预估峰值 QPS 参考方案
2.1. 历史数据分析
- 收集系统过去一段时间（例如几个月或一年）的 QPS 数据。
- 分析数据的趋势，包括季节性、周期性和长期增长或下降的模式。
2.2. 业务增长预测
- 考虑业务的发展计划，如新的市场推广活动、产品发布或用户增长目标。
- 根据业务增长的预期，估计对系统访问量的影响。
2.3. 节假日和特殊事件
- 研究在过去的节假日或特殊事件（如促销活动、重大新闻发布等）期间的 QPS 变化。
- 基于类似的未来事件，预测可能的峰值增加量。
2.4. 用户行为分析
- 了解用户的使用习惯，例如一天中不同时间段的访问高峰。
- 考虑不同用户群体的行为差异对 QPS 的影响。
2.5. 市场调研和竞品分析
- 研究同行业类似系统的 QPS 情况。
- 参考竞争对手在类似业务场景下的处理能力和流量水平。
2.6. 综合评估
- 将以上各个方面的分析结果进行综合。
- 可以采用加权平均或基于最保守估计的方法来确定最终的峰值 QPS 预估值。
2.7. 预留一定的余量
- 为了应对不可预见的情况，在预估的峰值 QPS 基础上，增加一定比例（例如 20% – 50%）的余量，得到最终峰值QPS。
2.8. 案例
例如，假设通过历史数据分析发现系统在去年促销活动期间的峰值 QPS 为 1000，预计今年业务增长 30%，同时考虑到新的市场推广活动可能带来额外 20% 的流量增加。综合这些因素，预估今年促销活动期间的峰值 QPS 为：1000 × 1.3 × 1.2 = 1560为了保险起见，再预留 30% 的余量，最终预估峰值 QPS 为 1560 × 1.3 = 2028 。
2.9. 其他方案
方案一原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间
例子：每天300w PV ，每个PV衍生请求10个，计算出峰值QPS （如果给出了时间段那就替换下面的86400）
( 3000000 * 10 * 0.8 ) / (86400 * 0.2 ) = 1388 (QPS)
例子：如果压测单机得到的单机极限的QPS是58，需要几台机器来支持？
1388 / (58 * 0.8) = 29
单机的极限qps为58，但通常不允许跑满，所以可以用58*0.8作为一台机器可以抗住的qps来参与计算
方案二原理：计算出平均qps乘以一个峰值因子（例如3~5倍）就可以估出一个峰值qps
例如：活动落地页1小时内的总访问量预估是30w pv，该落地页的衍生连接请求数为15
1、先计算出平均QPS
(30w * 15) /(60 * 60) = 1250
2、然后乘以峰值因子
峰值因子要根据实际的业务评估，通过以往的一些营销活动的 pv 等数据进行预估。
一般情况，峰值QPS大概是均值QPS的3-5倍（这就是峰值因子），
日均QPS1250 * 5 = 峰值QPS为6250
注意：“秒杀业务”比较难评估业务访问量，上述两种方案都无法全部满足，不在我们讨论范围内
3. 压力测试
# 安装ab工具
yum install httpd-tools -y
# 总共30000个请求，同一时刻并发10000个
ab -n 30000 -c 10000 http://192.168.71.207:8080/
# 该测试命令的含义：
# 对 http://192.168.71.207:8080/ 这个网站，进行一次性能测试，
# 该测试会产生 10000 个并发请求，直到总计发出 30000 个请求。