334 lines
10 KiB
Markdown
334 lines
10 KiB
Markdown
# 小程序API请求压力分析报告
|
||
|
||
## 一、用户进入小程序到刷帖子的完整请求流程
|
||
|
||
### 场景1：用户首次打开小程序（未登录/已登录但首次打开）
|
||
|
||
#### 阶段1：应用启动（App.vue）
|
||
- **onLaunch()**
|
||
- ❌ 无HTTP请求（仅读取本地存储token）
|
||
|
||
#### 阶段2：首页加载（pages/index/index.vue）
|
||
- **onLoad()** - 3个请求
|
||
1. `RefreshToken` - 刷新Token（如果有token）
|
||
2. `GetStreamerCategories` - 获取主播榜单分类列表
|
||
3. `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个**
|
||
1. RefreshToken
|
||
2. GetStreamerCategories
|
||
3. GetAppConfig
|
||
4. GetHomeRankings
|
||
5. GetBanners
|
||
6. GetLiveStreamers
|
||
7. 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%）**
|
||
- **建议：重点优化帖子列表查询性能**
|
||
|
||
---
|
||
|
||
## 九、注意事项
|
||
|
||
1. **Token刷新**：RefreshToken可能在后台静默执行，不影响用户体验但会产生请求
|
||
2. **重复请求**：onShow可能会重复触发某些请求，需要注意去重
|
||
3. **网络失败重试**：网络失败时的重试机制会增加请求数
|
||
4. **图片加载**：帖子列表中的图片加载不计入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%）
|
||
|
||
**当前架构瓶颈：**
|
||
1. **数据库连接池**：100个连接（主要瓶颈）
|
||
2. **数据库CPU**：4核处理能力
|
||
3. **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
|
||
**分析基于代码版本：** 当前代码库版本
|
||
|