# 性能工程 ## 目的性能工程包括负载测试、分析和优化，以交付可靠、可扩展的系统。该技能提供了用于选择正确的性能测试方法（负载、压力、浸泡、尖峰）、识别瓶颈（CPU、内存、I/O）的分析技术以及后端 API、数据库和前端应用程序的优化策略的框架。使用此技能在启动前验证系统容量，检测 CI/CD 管道中的性能回归，通过分析识别和解决瓶颈，并优化整个堆栈中的应用程序响应能力。 ## 何时使用此技能 **常见触发因素：** *“验证API可以处理预期流量” *“找到最大容量和突破点” *“确定应用程序速度缓慢的原因” *“检测内存泄漏或资源耗尽” *“优化 SEO 的核心网络生命” *“在 CI/CD 中设置性能测试” *“降低云基础设施成本” **使用案例：** * 启动前容量规划和负载验证 * 重构后性能回归测试 * 调查缓慢的响应时间或高延迟 * 检测长时间运行的服务中的内存泄漏 * 优化数据库查询性能 * 验证自动缩放配置 * 建立绩效 SLO 和预算 ## 性能测试类型 ### 负载测试验证预期流量水平下的系统行为。 **何时使用：** 启动前容量规划、重构后回归测试、验证自动扩展。 ### 压力测试查找系统容量限制和故障模式。 **何时使用：** 容量规划、了解故障行为、基础设施规模决策。 ### 浸泡测试识别内存泄漏、资源耗尽和随时间的退化。 **何时使用：** 检测内存泄漏、验证连接池清理、测试长时间运行的批处理作业。 ### 尖峰测试验证系统对突发流量峰值的响应。 **何时使用：** 验证自动扩展、测试事件驱动系统（产品发布）、确保速率限制有效。 ## 快速决策框架 **使用哪种测试类型？** 我想学什么？ ├─ 我的系统可以处理预期的流量吗？ → 负载测试 ├─ 最大容量是多少？ → 压力测试 ├─ 随着时间的推移它会保持稳定吗？ → 浸泡测试 └─ 能应对流量高峰吗？ → 尖峰测试有关详细的测试模式、负载场景和解释结果，请参阅“references/testing-types.md”。 ## 负载测试快速入门 ### k6（JavaScript） **安装：** 酿造安装 k6 # macOS sudo apt-get install k6 # Linux **基本负载测试：** 从'k6/http'导入http；从'k6'导入{检查，睡眠}；导出常量选项= { 阶段：[ { 持续时间: '30s', 目标: 20 }, { 持续时间：'1m'，目标：20 }, { 持续时间: '30s', 目标: 0 }, ], 阈值：{ http_req_duration: ['p(95)<500'], http_req_failed: ['速率<0.01'], }, }; 导出默认函数 () { const res = http.get('https://api.example.com/products'); 检查（资源，{ '状态为 200': (r) => r.status === 200, }); 睡眠（1）； } **运行：** `k6 运行 script.js` 有关压力、浸泡和峰值测试示例，请参阅“examples/k6/”。 ### 蝗虫（Python） **安装：** pip安装蝗虫 **基本负载测试：** from locust import HttpUser, 任务, 之间类网站用户（HttpUser）：等待时间 = 之间 (1, 3) 主机=“https://api.example.com” @任务(3) def view_products（自身）： self.client.get("/产品") @任务(1) def view_product_detail(self): self.client.get(“/产品/123”) **运行：** `locust -f locustfile.py --headless -u 100 -r 10 --run-time 10m` 有关 REST API 测试和数据驱动测试，请参阅“examples/locust/”。 ## 分析快速入门 ### 何时进行分析症状|分析类型|工具 ---|---|--- 高CPU (>70%) | CPU 分析 | py-spy、pprof、开发工具记忆力增长|内存分析 | memory_profiler、pprof 堆响应慢、CPU 低 | I/O 分析 |查询日志、pprof 块 ### Python 分析 **py-spy（生产安全）：** pip 安装 py-spy # 配置文件运行流程 py-spy record -o profile.svg --pid --duration 30 # 类似顶部的视图 py-spy top --pid **内存分析：** 从内存分析器导入配置文件 @个人资料 def my_function(): a = [1] * (10 ** 6) 返回一个 # 运行: python -m memory_profiler script.py ### 进行分析 **pprof（内置）：** 导入（ “网络/http” _“网络/http/pprof” ）函数主() { 去函数（）{ http.ListenAndServe("localhost:6060", nil) }() 启动应用程序() } **捕获配置文件：** # CPU 配置文件（30 秒）去工具 pprof http://localhost:6060/debug/pprof/profile?seconds=30 # 互动分析 (pprof) 顶部 (pprof) 网络 ### TypeScript/JavaScript 分析 **Chrome 开发工具（浏览器/Node.js）：** 节点.js：节点--检查app.js # 打开 chrome://inspect # 性能选项卡 → 记录 **clinic.js (Node.js):** npm install -g 诊所诊所医生——node app.js 有关详细的分析工作流程和分析，请参阅“references/profiling-guide.md”和“examples/profiling/”。 ## 优化策略 ### 缓存 **何时缓存：** * 频繁查询数据（>100 请求/分钟） * 数据新鲜度容差（>1 分钟可接受的陈旧度） **Redis 示例：** 导入redis r = redis.Redis() def get_cached_data(key, fn, ttl=300): 缓存 = r.get(key) 如果缓存：返回 json.loads(缓存) 数据 = fn() r.setex(key, ttl, json.dumps(data)) 返回数据 ### 数据库查询优化 **N+1预防：** # 不好：N+1 次查询用户 = User.query.all() 对于用户中的用户： print(user.orders) # 每个用户单独查询 # 好：渴望加载用户 = User.query.options(joinedload(User.orders)).all() **索引：** 在用户（电子邮件）上创建索引 idx_users_email； ### API 性能 **基于光标的分页：** app.get('/api/products', async (req, res) => { const { 游标, limit = 20 } = req.query; const 产品 = 等待 db.query( '从产品中选择 * id > ?按 id 限制排序？', [光标|| 0，极限] ）； res.json({ 数据：产品、 next_cursor: 产品[产品.长度 - 1]?.id, }); }); ### 前端性能（核心 Web 生命） **关键指标：** * **LCP（最大内容油漆）：** < 2.5s * **INP（与下一个绘画的交互）：** < 200ms * **CLS（累积布局偏移）：** < 0.1 **优化技术：** * 代码分割（延迟加载） * 图像优化（WebP、响应式、延迟加载） * 预加载关键资源 * 最小化渲染阻塞资源详细的优化策略请参见“references/optimization-strategies.md”和“references/frontend-performance.md”。 ## 性能 SLO ### 按服务类型推荐的 SLO 服务类型 | p95 延迟 | p99 延迟 |可用性 ---|---|---|--- 面向用户的 API | < 200 毫秒 | < 500 毫秒 | 99.9% 内部API | < 100 毫秒 | < 300 毫秒 | 99.5% 数据库查询 | < 50 毫秒 | < 100 毫秒 | 99.99% 后台作业 | < 5 秒 | < 10 秒 | 99% 实时API | < 50 毫秒 | < 100 毫秒 | 99.95% ### SLO 选择过程 1. 衡量基线绩效 2. 确定用户期望 3.设定可实现的目标（比基线好10-20%） 4.随着系统的成熟进行迭代有关详细的 SLO 框架和性能预算，请参阅“references/slo-framework.md”。 ## CI/CD 集成 ### 管道中的性能测试 **GitHub 操作示例：** 名称：性能工程于：拉请求：分支：[主要] 职位：负载测试：运行：ubuntu-latest 步骤： - 使用：actions/checkout@v4 - 名称：安装k6 运行：| 卷曲 https://github.com/grafana/k6/releases/download/v0.48.0/k6-v0.48.0-linux-amd64.tar.gz -L |焦油xvz sudo mv k6-v0.48.0-linux-amd64/k6 /usr/local/bin/ - 名称：运行负载测试运行： k6 运行测试/load/api-test.js **绩效预算：** // k6 测试阈值（如果违反则构建失败）导出常量选项= { 阈值：{ http_req_duration: ['p(95)<500'], http_req_failed: ['速率<0.01'], }, }; ## 分析工作流程 **标准流程：** 1.观察症状（CPU高、内存增长、响应慢） 2. 假设瓶颈（CPU？内存？I/O？） 3. 根据假设选择分析类型 4. 在实际负载下运行分析器 5. 分析配置文件（火焰图、调用树） 6. 识别热点（使用 80% 资源的前 20% 功能） 7.优化瓶颈 8. 重新分析以验证改进 **最佳实践：** * 实际负载下的配置文件（不是空闲系统） * 在生产中使用采样分析器（py-spy、pprof）（低开销） * 关注热路径（首先优化最大的瓶颈） * 通过前后比较验证优化 ## 工具推荐 ### 负载测试 **主要：k6**（基于 JavaScript，Grafana 支持） * 现代架构，云原生 * JavaScript DSL (ES6+) * Grafana/Prometheus 集成 * 多协议（HTTP/1.1、HTTP/2、WebSocket、gRPC） **何时使用：** 现代 API、微服务、CI/CD 集成。 **替代方案：Locust**（基于 Python） * Python 原生（用 Python 编写测试） * Web UI实时监控 * 灵活应对复杂的用户场景 **何时使用：** Python 密集型团队，复杂的用户流程。 ### 分析 **Python：** * py-spy（采样，生产安全） * cProfile（确定性、详细） * memory_profiler（内存泄漏检测） **去：** * pprof（内置，CPU/堆/goroutine/块分析） **打字稿/JavaScript：** * Chrome 开发工具（浏览器/Node.js） * Clinic.js（Node.js 性能套件）有关详细的工具比较，请参阅“references/testing-types.md”和“references/profiling-guide.md”。 ## 参考文档 **详细指南：** * `references/testing-types.md` \- 负载、压力、浸泡、尖峰测试模式 * `references/profiling-guide.md` \- 跨语言的 CPU、内存、I/O 分析 * `references/optimization-strategies.md` \- 缓存、数据库、API 优化 * `references/frontend-performance.md` \- Core Web Vitals，捆绑优化 * `references/slo-framework.md` \- 设置 SLO、性能预算 * `references/benchmarking.md` \- 基准测试最佳实践 **示例：** * `examples/k6/` \- 负载、压力、浸泡、尖峰测试 * `examples/locust/` \- 基于Python的负载测试 * `examples/profiling/` \- 分析示例（Python、Go、TypeScript） * `examples/optimization/` \- 缓存、查询、API 优化 ## 相关技能有关全面的测试策略，请参阅“测试策略”技能。对于 CI/CD 集成模式，请参阅“building-ci-pipelines”技能。对于基于负载测试的基础设施规模调整，请参阅“基础设施即代码”技能。 _性能工程 v1.1 - 增强版_ ## 🔄 工作流程 > **Kaynak：** [k6 方法论]() & [容量规划的艺术]() ### Aşama 1：规划和 SLO * **目标**：测试的目的是什么？（烟雾、负载、压力、浸泡？）。 * **SLO**：确定成功标准（例如：p95 延迟 < 200 毫秒，错误率 < 1%）。 * **环境** ：测试环境与 Prod 有多相似？（确定比例因子）。 ### 第 2 阶段：脚本编写和执行 * **用户旅程** ：模拟真实用户行为（登录 -> 浏览 -> 购买）。 * **数据驱动**：使用 CSV 中的动态数据而不是静态数据（以绕过缓存）为测试提供数据。 * **Ramp-up**：逐渐增加流量，而不是突然增加（以预热系统）。 ### 第 3 阶段：分析与优化 * **相关性**：发生错误时的 CPU/内存/数据库指标是什么？ * **瓶颈** ：瓶颈在哪里？（应用程序代码、数据库、网络或负载注入器本身？）。 * **报告**：准备一份包含技术和执行摘要的报告。 ### 检查点舞台|验证 ---|--- 1 |测试数据（数据库种子）是否足够？ 2 | Load Generator（测试机）是否成为CPU瓶颈？（假阴性风险）。 3 |第三方 API（Stripe、Twilio）是否被嘲笑？（费用和禁令风险）。

性能工程

包含技能