# 小程序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  
**分析基于代码版本：** 当前代码库版本