10 KiB
10 KiB
小程序API请求压力分析报告
一、用户进入小程序到刷帖子的完整请求流程
场景1：用户首次打开小程序（未登录/已登录但首次打开）
阶段1：应用启动（App.vue）
- onLaunch()
- ❌ 无HTTP请求（仅读取本地存储token）
阶段2：首页加载（pages/index/index.vue）
-
onLoad() - 3个请求
RefreshToken- 刷新Token（如果有token）GetStreamerCategories- 获取主播榜单分类列表GetAppConfig- 获取App配置信息
-
getCategories()成功后自动触发 4.
GetHomeRankings- 获取首页主播榜单（前9名） -
onShow() - 3个请求（与onLoad并行或稍后执行） 5.
GetBanners- 获取轮播图 6.GetLiveStreamers- 获取直播中主播列表 7.GetUserInfo- 获取用户信息（如果已登录）
首页总请求数：7个请求
阶段3：切换到社区页面刷帖子（pages/community/community-page.vue）
-
onLoad() - 1个请求 8.
GetPosts- 获取帖子列表（第1页，10条） -
onShow() - 可能的额外请求
- 如果
shouldRefresh=true（登录后），会再次调用GetPosts（通常不触发）
- 如果
社区页首次加载：1个请求
场景2：用户已登录且不是首次打开（token有效）
首页加载时：
RefreshToken可能会成功或失败，但仍会发送请求- 其他请求不变
二、请求统计汇总
从进入小程序到首次看到帖子列表
| 阶段 | 请求数量 | 说明 |
|---|---|---|
| 应用启动 | 0 | 仅本地存储读取 |
| 首页加载 | 7 | 3个onLoad + 1个自动触发 + 3个onShow |
| 社区页加载 | 1 | 获取帖子列表 |
| 总计（最少） | 8个请求 | 未登录状态 |
| 总计（已登录） | 8个请求 | 已登录状态（相同） |
三、刷帖子操作产生的请求
下拉刷新
GetPosts- 1个请求（重置PageIndex=1）
上拉加载更多
GetPosts- 1个请求（PageIndex++）
点击查看帖子详情
GetPostDetail- 1个请求（获取帖子详情）GetPostComments- 1个请求（获取评论列表，每页10条）
查看一个帖子详情：2个请求
四、不同场景的请求压力分析
场景A：用户只浏览首页（不进入社区）
- 请求数：7个
- RefreshToken
- GetStreamerCategories
- GetAppConfig
- GetHomeRankings
- GetBanners
- GetLiveStreamers
- GetUserInfo（已登录时）
场景B：用户从首页进入社区并刷帖子（完整流程）
-
首次加载：8个请求 1-7. 首页的7个请求 8. GetPosts（社区页）
-
下拉刷新：+1个请求 9. GetPosts
-
上拉加载（假设加载3次）：+3个请求 10. GetPosts（第2页） 11. GetPosts（第3页） 12. GetPosts（第4页）
总请求数：12个请求（如果用户只浏览列表不点详情）
场景C：用户浏览并点击查看帖子详情
- 浏览3个帖子详情：+6个请求 13-14. 帖子1详情 + 评论 15-16. 帖子2详情 + 评论 17-18. 帖子3详情 + 评论
总请求数：18个请求
五、服务器压力估算
假设条件
- 1000个用户同时进入小程序
- 所有用户都从首页进入社区并刷帖子
- 平均每个用户下拉刷新1次、上拉加载2次、查看2个帖子详情
计算过程
每个用户的基础请求：
- 首页加载：7个请求
- 社区页加载：1个请求
- 下拉刷新：1个请求
- 上拉加载2次：2个请求
- 查看2个帖子详情：4个请求（2×2）
单用户总请求：15个请求
1000用户并发：
- 总请求数：1000 × 15 = 15,000个请求
- 如果这些请求在60秒内完成，QPS = 15,000 / 60 = 250 QPS
六、API接口压力分布
| API接口 | 单用户请求次数 | 1000用户请求次数 | 占比 |
|---|---|---|---|
| GetPosts | 4 | 4,000 | 26.7% |
| GetPostDetail | 2 | 2,000 | 13.3% |
| GetPostComments | 2 | 2,000 | 13.3% |
| GetBanners | 1 | 1,000 | 6.7% |
| GetLiveStreamers | 1 | 1,000 | 6.7% |
| GetHomeRankings | 1 | 1,000 | 6.7% |
| GetStreamerCategories | 1 | 1,000 | 6.7% |
| GetUserInfo | 1 | 1,000 | 6.7% |
| RefreshToken | 1 | 1,000 | 6.7% |
| GetAppConfig | 1 | 1,000 | 6.7% |
压力最大的接口：GetPosts（帖子列表）
七、优化建议
1. 缓存策略
- GetAppConfig：配置信息变更频率低，可缓存24小时
- GetStreamerCategories：分类列表变更频率低，可缓存1小时
- GetBanners：轮播图可缓存30分钟
2. 请求合并
- 首页的某些请求可以合并为一个接口，减少请求数
3. 分页优化
- GetPosts接口增加缓存，相同页码的请求可短时间缓存（5-10秒）
4. 懒加载
- 用户未点击进入社区页时，可以不预加载帖子数据
5. 预加载策略
- 帖子详情页的评论可以延迟加载，先加载帖子详情
八、关键数据总结
最小请求数（用户仅进入首页）
7个请求
典型请求数（用户进入社区并浏览）
12-15个请求（包含下拉刷新、上拉加载、查看详情）
峰值请求数（重度用户）
20+个请求（多次刷新、加载、查看多个详情）
服务器压力（1000并发用户）
- 峰值QPS：250+
- 主要压力：GetPosts接口（占26.7%）
- 建议：重点优化帖子列表查询性能
九、注意事项
- Token刷新：RefreshToken可能在后台静默执行，不影响用户体验但会产生请求
- 重复请求：onShow可能会重复触发某些请求，需要注意去重
- 网络失败重试：网络失败时的重试机制会增加请求数
- 图片加载：帖子列表中的图片加载不计入API请求，但会增加服务器带宽压力
十、服务器压力与并发数分析
10.1 服务器配置
- 业务服务器：4核8G × 1台
- 数据库服务器：4核8G × 1台
- 数据库连接池：最大100个连接
10.2 单请求性能分析
高复杂度接口：
- GetPosts：150-300ms（7-8个数据库查询）
- GetPostDetail：100-200ms（5-6个数据库查询）
- GetPostComments：80-150ms（2-3个数据库查询）
中等复杂度接口：
- GetHomeRankings：50-100ms
- GetLiveStreamers：50-100ms
低复杂度接口（可缓存）：
- GetBanners：20-50ms（未缓存）/ 5-10ms（缓存）
- GetStreamerCategories：20-50ms（未缓存）/ 5-10ms（缓存）
- GetAppConfig：20-50ms（未缓存）/ 5-10ms（缓存）
- GetUserInfo：30-60ms
- RefreshToken：20-40ms
10.3 服务器性能指标
业务服务器（4核8G）：
- 安全运行QPS：4000-6000 请求/秒（50%负载）
- 理论峰值QPS：8000-12000 请求/秒
数据库服务器（4核8G）：
- 安全运行QPS：1000-2000 查询/秒（50%负载）
- 连接池限制：100个连接
- 理论峰值QPS：1500-2000 查询/秒
10.4 并发数计算
单用户请求分析：
- 首页加载：7个请求（平均200ms）
- 社区页加载：1个请求（平均200ms）
- 下拉刷新：1个请求（平均200ms）
- 上拉加载2次：2个请求（平均200ms）
- 查看2个详情：4个请求（平均300ms）
- 单用户总请求：15个请求
- 单用户平均响应时间：约250ms/请求
基于业务服务器计算：
最大并发用户数 = (业务服务器QPS × 单用户平均响应时间) / 单用户请求数
= (4000 × 0.25) / 15
≈ 66-100 个并发用户（保守估计）
基于数据库服务器计算：
数据库连接池：100个连接
单连接处理能力：10-20 查询/秒
数据库总QPS：100 × 15 = 1500 查询/秒
单用户数据库查询数：约30-50个（15个API × 平均2-3个查询/API）
最大并发用户数 = 1500 / (40 / 0.25) ≈ 9-10 个（过于保守）
实际考虑查询优化和缓存后：约100-200个并发用户
10.5 压力测试结果预估
说明：QPS = Queries Per Second（每秒请求数），数据库QPS = 每秒数据库查询数
计算方式：
- 假设每个并发用户完成15个请求（首页7个 + 社区页1个 + 刷新1个 + 加载2个 + 详情4个）
- 单用户平均响应时间：250ms/请求
- 单用户完成所有请求时间：约3-4秒（考虑请求并行）
- QPS = (并发用户数 × 单用户请求数) / 单用户完成时间
| 并发用户数 | QPS（每秒） | 数据库QPS（每秒） | CPU使用率 | 内存使用率 | 状态 |
|---|---|---|---|---|---|
| 100 | 375-500 | 937-1250 | 10-20% | 20-30% | ✅ 轻松 |
| 150 | 562-750 | 1405-1875 | 20-30% | 30-40% | ✅ 良好 |
| 200 | 750-1000 | 1875-2500 | 30-40% | 40-50% | ⚠️ 适中 |
| 300 | 1125-1500 | 2812-3750 | 50-70% | 60-70% | ⚠️ 压力大 |
| 400 | 1500-2000 | 3750-5000 | 70-90% | 70-80% | ❌ 接近极限 |
| 500 | 1875-2500 | 4687-6250 | 90-100% | 80-90% | ❌ 可能过载 |
注：上述QPS为峰值QPS，实际运行中由于用户操作时间分散，平均QPS会低于峰值
10.6 最大并发数结论
保守估算（推荐）：100-150个并发用户
- 保证稳定运行
- 响应时间可接受（<300ms）
- 资源使用率合理（<50%）
理论峰值：300-400个并发用户
- 需要优化（缓存、索引）
- 可能响应时间延长（500ms+）
- 资源使用率较高（70-90%）
当前架构瓶颈：
- 数据库连接池：100个连接（主要瓶颈）
- 数据库CPU：4核处理能力
- GetPosts接口复杂度：多表查询
10.7 优化建议
短期优化（提升50-100%）：
- 启用Redis缓存（GetAppConfig、GetBanners、GetStreamerCategories）
- 优化数据库索引（T_Posts、T_PostImages、T_Likes等）
- 增加数据库连接池大小到150-200
中期优化（提升2-3倍）：
- 增加1-2台业务服务器（负载均衡）
- 数据库读写分离
- GetPosts接口查询优化（视图或存储过程）
详细分析请参考： 服务器压力与并发数分析.md
文档生成时间： 2025-01-XX
分析基于代码版本： 当前代码库版本