项目性能优化前置知识

1. 性能优化问题分析

1.1 什么时候进行项目的性能优化？

性能优化通常是在系统出现性能瓶颈或潜在的性能问题时进行的。以下是一些常见的情境：

• 系统响应慢或延迟增加：如果系统的响应时间逐渐变长，或者用户体验明显下降，通常意味着需要优化性能。例如，页面加载时间过长、数据库查询响应时间变慢、API 请求超时等。
• 资源消耗过大：如果应用或系统消耗了过多的计算资源（CPU、内存、硬盘IO、网络带宽等），尤其是在高并发或大数据处理场景下，可能会影响到系统的稳定性和扩展性，需要进行优化。
• **高并发或高负载场景：**如果你的应用预计会有高并发请求或处理大量的数据流，或者在流量激增时系统无法承受高负载，就需要提前进行性能优化，保证系统在高负载下的稳定性和响应能力。
• 系统瓶颈：系统的某一部分（例如，数据库、缓存、磁盘IO等）出现瓶颈，限制了整体性能。如果出现了某些资源的过度使用或“单点瓶颈”，那么优化该部分会显著提高整体性能。
• 开发过程中发现性能问题：在开发过程中，定期进行性能测试，及时发现潜在的性能问题，如内存泄漏、CPU过高等，及时优化，避免问题积累影响最终产品。

1.2 项目性能优化主要涉及到哪几个方面？

Web项目的性能优化是一个多维度的工作，涵盖了前端、后端、网络、架构等多个方面。优化的目标是提高响应速度、降低资源消耗、减少延迟，并保证系统的可扩展性和稳定性。

前端性能优化：

• 资源压缩与合并：压缩 css、JavaScript 文件减少文件的体积。进行图片压缩和文件合并。

• 资源缓存**：使用 浏览器缓存**，设置合适的缓存策略（如 Cache-Control、ETag）来缓存静态资源，避免每次请求都重新加载相同的资源。

• 异步加载和非阻塞资源：将 JavaScript 文件加载方式改为 异步（async） 或 延迟加载（defer），避免阻塞 HTML 渲染，提升页面加载速度。

• 减少 HTTP 请求：尽量减少 HTTP 请求次数。可以通过合并文件、使用图像雪碧图（CSS Sprites）和字体图标等方式减少请求数。

后端性能优化(针对Java)：

在进行后段性能优化会碰到一些名词如：

• RT（Response Time）: 响应时间，表示后端处理请求所需的时间。
• TPS（Transactions Per Second）: 每秒事务处理量，表示系统在单位时间内能够处理的请求数。
• QPS（Queries Per Second）：每秒查询率，表示服务器每秒能够处理的请求数量。
• Throughput（吞吐量）: 系统在单位时间内可以处理的请求总量。
• Footprint（资源占用）: 指系统在运行中消耗的资源，例如内存、CPU 等。
• Latency（延迟）: 请求从发送到接收响应的总延迟时间，包括网络、处理等所有因素。

网络优化：

• 内容分发网络（CDN）：使用 CDN 来分发静态资源（如图片、CSS、JavaScript 等），减少服务器压力，并通过靠近用户的边缘节点来加速加载速度。
• GZIP 压缩：启用 GZIP 压缩来压缩传输的文本资源（如 HTML、CSS、JavaScript），减少网络传输的体积，从而加速数据加载。
• 减少重定向和域名解析：减少不必要的重定向（如 301、302 重定向），避免因为多次重定向导致请求延迟，减少跨域请求的次数，尤其是跨多个域名时，涉及的 DNS 查询会增加延迟。
• 加大网络的带宽。

架构优化：

• 使用微服务架构：如果应用非常复杂且规模较大，可以考虑将系统拆分为多个微服务，分布式部署，避免单点瓶颈，提高系统的可扩展性和响应能力。

• 负载均衡**：使用负载均衡技术（如 Nginx、OpenResty**、HAProxy）将请求均衡地分配到多个服务器，避免某一台服务器过载，提高系统的可用性和扩展性。

2. 压力测

2.1 什么是压力测试？

压力测试（Stress testing）是一种针对特定系统或组件进行的测试，目的是通过施加超出正常条件的压力来验证系统的稳定性。这种测试可以帮助发现系统在极端条件下的表现和潜在问题。

2.1 为什么需要压力测试？

压力测试是验证系统在负载极端变化或超出负载情况下的能力，当需要准确了解系统性能上限时，就需要进行压力的测试。

2.3 压力测试的目的

观察系统各项性能指标是否出现异常变化，发现系统的性能瓶颈，进行性能优化。

判断系统是否会在特定情况下崩溃，测试系统整体的稳定性，评估其性能上限。

2.4 压力测试的性能指标

• 响应时间 (Response Time)： 用户请求被系统处理并返回的时间，用于衡量系统处理速度。

• 吞吐量 (Throughput)： 单位时间内系统处理的请求数量，衡量系统的承载能力。

• 并发用户数： 系统能同时处理的用户数，直接体现系统的并发能力。

• 错误率：失败请求占比，在测试时添加响应断言，验证不通过记为错误；若不添加，响应码为非200即为错误。

• 资源使用率： 系统在运行过程中使用资源（CPU、内存、网络等）的比例。

以上主要的四种性能指标【响应时间、并发用户数、吞吐量、资源使用率】它们之间存在一定的相关 性，共同反映出性能的不同方面。

image-20241120113656060

从上图可以看出，主要涉及响应时间 (RT)、吞吐量 (Throughput) 和 资源利用率 (Utilization) 三个核心指标。

轻负载区 (Light Load)：

• 在并发用户数量较低时，系统资源充足，性能表现良好：
  • 响应时间 (RT)： 近似保持恒定，较低。
  • 吞吐量 (Throughput)： 随用户增加线性上升。
  • 资源利用率 (Utilization)： 增加并逐渐趋近于接近饱和的水平。

此时系统处于高效状态，能够很好地处理新增负载。

重负载区 (Heavy Load)：

• 系统达到资源饱和点（图中1处，Resources Saturated）后，表现出现变化：
  • 响应时间 (RT)： 开始显著增加，变得不可预测。
  • 吞吐量 (Throughput)： 达到峰值，随后在资源耗尽时出现下降（图中2处，Throughput Falling）。
  • 资源利用率 (Utilization)： 接近上限并保持稳定。

在此阶段，用户体验开始受到影响，但吞吐量在短时间内仍然能维持高水平。

崩塌区 (Buckle Zone)：

• 系统无法处理额外负载（图中3处，End Users Effected）：
  • 响应时间 (RT)： 呈指数级急剧上升，系统无法及时响应用户请求。
  • 吞吐量 (Throughput)： 快速下降。
  • 资源利用率 (Utilization)： 虽然接近100%，但由于资源争用过高，实际处理能力反而下降。

此时，系统处于过载状态，用户体验大幅下降，可能导致系统崩溃或拒绝服务。