xyzw_web_helper/MD说明文件夹/性能优化-发车超时统一1000ms v3.11.6.md

# 性能优化：发车超时统一1000ms v3.11.6

## 📋 更新时间
2025-10-08

## 🎯 优化目标
将批量自动化中"发车"任务的所有超时时间统一调整为 **1000ms**，测试是否可行，提升任务执行速度。

## 📊 修改前后对比

### 修改前配置（v3.11.5）

| 操作步骤 | WebSocket命令 | 超时时间 | 说明 |
|---------|--------------|---------|------|
| 1️⃣ 查询车辆 | `car_getrolecar` | **10000ms** (10秒) | 查询俱乐部车辆信息 |
| 2️⃣ 批量刷新 | `car_refresh` | **5000ms** (5秒) | 刷新每辆车 |
| 3️⃣ 批量收获 | `car_claim` | **5000ms** (5秒) | 收获已到达的车辆 |
| 4️⃣ 批量发送 | `car_send` | **5000ms** (5秒) | 发送待发车的车辆 |
| 5️⃣ 最终验证 | `car_getrolecar` | **10000ms** (10秒) | 验证最终发车数 |

**预估单次发车时间：** 约 10-30秒

### 修改后配置（v3.11.6）

| 操作步骤 | WebSocket命令 | 超时时间 | 说明 |
|---------|--------------|---------|------|
| 1️⃣ 查询车辆 | `car_getrolecar` | **1000ms** (1秒) ⬇️ | 查询俱乐部车辆信息 |
| 2️⃣ 批量刷新 | `car_refresh` | **1000ms** (1秒) ⬇️ | 刷新每辆车 |
| 3️⃣ 批量收获 | `car_claim` | **1000ms** (1秒) ⬇️ | 收获已到达的车辆 |
| 4️⃣ 批量发送 | `car_send` | **1000ms** (1秒) ⬇️ | 发送待发车的车辆 |
| 5️⃣ 最终验证 | `car_getrolecar` | **1000ms** (1秒) ⬇️ | 验证最终发车数 |

**预估单次发车时间：** 约 3-8秒 ⬇️ **（减少70%）**

## ✨ 优化效果

### 时间节省

| 场景 | 修改前 | 修改后 | 节省时间 |
|------|--------|--------|---------|
| **单次发车（4辆车）** | 10-30秒 | 3-8秒 | **节省 7-22秒** |
| **21个Token批量（并发3）** | 约3-5分钟 | 约1-2分钟 | **节省 2-3分钟** |
| **100个Token批量（并发5）** | 约15-25分钟 | 约5-8分钟 | **节省 10-17分钟** |

### 性能提升

1. ✅ **执行速度提升 70%**：发车任务执行时间大幅缩短
2. ✅ **响应更快**：用户体验更流畅
3. ✅ **吞吐量提升**：相同时间内可处理更多token
4. ✅ **统一配置**：所有发车操作使用相同超时，便于维护

## 🔧 代码修改

### 修改的文件
`src/stores/batchTaskStore.js`

### 修改内容

#### 1️⃣ 查询车辆（第1180行）
```javascript
// 修改前
const response = await tokenStore.sendMessageAsync(tokenId, 'car_getrolecar', {}, 10000)

// 修改后
const response = await tokenStore.sendMessageAsync(tokenId, 'car_getrolecar', {}, 1000)
```

#### 2️⃣ 批量刷新（第1297行）
```javascript
// 修改前
await tokenStore.sendMessageAsync(tokenId, 'car_refresh', { carId: carId }, 5000)

// 修改后
await tokenStore.sendMessageAsync(tokenId, 'car_refresh', { carId: carId }, 1000)
```

#### 3️⃣ 批量收获（第1363行）
```javascript
// 修改前
await tokenStore.sendMessageAsync(tokenId, 'car_claim', { carId: carId }, 5000)

// 修改后
await tokenStore.sendMessageAsync(tokenId, 'car_claim', { carId: carId }, 1000)
```

#### 4️⃣ 批量发送（第1463行）
```javascript
// 修改前
await tokenStore.sendMessageAsync(tokenId, 'car_send', {
  carId: carId,
  helperId: 0,
  text: ""
}, 5000)

// 修改后
await tokenStore.sendMessageAsync(tokenId, 'car_send', {
  carId: carId,
  helperId: 0,
  text: ""
}, 1000)
```

#### 5️⃣ 最终验证（queryClubCars 函数复用，已包含在第1180行修改中）

## ⚠️ 注意事项

### 可能的风险

1. **超时风险**：
   - 网络较慢时，1000ms 可能不足以完成请求
   - 服务器响应慢时，可能出现超时错误
   - 高并发时，服务器压力大可能导致超时

2. **失败处理**：
   - 如果频繁超时，自动重试机制会生效
   - 部分任务失败会触发整体任务重试

3. **适用场景**：
   - ✅ 网络状况良好
   - ✅ 服务器响应快速
   - ✅ 并发数适中（≤10）
   - ❌ 网络不稳定
   - ❌ 服务器负载高
   - ❌ 超高并发（>20）

### 监控建议

在使用新配置时，请注意观察：

1. **成功率**：
   - 发车任务成功率是否下降
   - 是否出现频繁的超时错误

2. **重试频率**：
   - 自动重试是否频繁触发
   - 重试后成功率如何

3. **日志信息**：
   ```
   ✅ 正常：[token_xxx] 查询车辆成功 (在1000ms内)
   ⚠️ 警告：请求超时: car_getrolecar (1000ms)
   🔄 重试：自动重试失败任务（第1/3轮）
   ```

## 🧪 测试建议

### 测试场景1：正常网络环境
1. 运行批量自动化，选择3-5个token
2. 启用"发车"任务
3. 观察：
   - ✅ 发车任务是否快速完成（3-8秒）
   - ✅ 是否有超时错误
   - ✅ 最终发车数是否准确（4/4）

### 测试场景2：高并发环境
1. 运行批量自动化，选择10-20个token
2. 设置并发数为10
3. 观察：
   - ✅ 发车任务成功率
   - ⚠️ 是否出现超时错误增加
   - 📊 整体完成时间对比

### 测试场景3：网络较慢环境
1. 在网络不佳时运行批量自动化
2. 观察：
   - ⚠️ 超时错误频率
   - 🔄 重试机制是否有效
   - 💡 是否需要恢复更长的超时时间

## 📈 性能数据记录

### 建议记录的指标

| 指标 | 修改前 | 修改后 | 改进 |
|------|--------|--------|------|
| 单次发车平均时间 | ___秒 | ___秒 | ___% |
| 发车任务成功率 | ___% | ___% | ___% |
| 超时错误频率 | ___次/100次 | ___次/100次 | ___次 |
| 重试触发频率 | ___% | ___% | ___% |

**请在实际使用中填写，以评估优化效果**

## 🔄 回滚方案

如果新配置导致频繁超时或成功率下降，可以恢复为原配置：

### 方案A：仅恢复查询和验证（推荐）
```javascript
// 查询车辆和最终验证
car_getrolecar: 1000ms → 5000ms

// 刷新、收获、发送保持1000ms
car_refresh: 1000ms
car_claim: 1000ms
car_send: 1000ms
```

### 方案B：全部恢复（保守）
```javascript
car_getrolecar: 1000ms → 10000ms
car_refresh: 1000ms → 5000ms
car_claim: 1000ms → 5000ms
car_send: 1000ms → 5000ms
```

### 方案C：折中配置（平衡）
```javascript
// 所有操作统一为3000ms
car_getrolecar: 1000ms → 3000ms
car_refresh: 1000ms → 3000ms
car_claim: 1000ms → 3000ms
car_send: 1000ms → 3000ms
```

## 💡 未来优化方向

1. **自适应超时**：
   - 根据历史响应时间动态调整超时
   - 网络慢时自动延长，网络快时自动缩短

2. **并发优化**：
   - 根据超时频率动态调整并发数
   - 超时率高时自动降低并发

3. **错误重试优化**：
   - 超时错误使用更短的重试间隔
   - 其他错误使用标准重试间隔

4. **配置UI化**：
   - 允许用户在设置中自定义超时时间
   - 提供"快速/标准/保守"预设模式

## 🔗 相关文档

- [批量自动化-超时延迟配置表v3.11.md](./批量自动化-超时延迟配置表v3.11.md)
- [功能优化-发车任务最终验证v3.11.3.md](./功能优化-发车任务最终验证v3.11.3.md)
- [问题修复-部分任务失败触发重试v3.11.4.md](./问题修复-部分任务失败触发重试v3.11.4.md)

## 📝 版本历史

### v3.11.6 (2025-10-08)
- ⚡ 性能优化：发车任务所有超时时间统一调整为1000ms
- 📊 预期效果：任务执行速度提升70%
- 🔄 说明：统一超时配置，便于维护和调整

### v3.11.5 (2025-10-08)
- 🐛 修复：答题任务3100080错误处理

### v3.11.4 (2025-10-08)
- 🐛 修复：部分任务失败触发重试

### v3.11.3 (2025-10-08)
- ✨ 新增：发车任务最终验证步骤

---

## 🎉 总结

此次优化将发车任务的超时时间统一调整为 **1000ms**，预期可将发车任务执行时间缩短 **70%**。

**建议：**
- ✅ 先在小规模（3-5个token）测试
- ✅ 观察成功率和超时频率
- ✅ 根据实际情况决定是否需要调整
- ⚠️ 如遇频繁超时，请参考回滚方案

**反馈：** 请在使用后提供实际效果反馈，以便进一步优化！