admin/xyzw_web_helper

Fork 0

Files

kirin 90094ccd5a 1.0

2025-10-17 20:56:50 +08:00

7.9 KiB

Raw Blame History

性能优化：发车超时统一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分钟

性能提升

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

🔧 代码修改

修改的文件

src/stores/batchTaskStore.js

修改内容

1️⃣ 查询车辆（第1180行）

// 修改前
const response = await tokenStore.sendMessageAsync(tokenId, 'car_getrolecar', {}, 10000)

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

2️⃣ 批量刷新（第1297行）

// 修改前
await tokenStore.sendMessageAsync(tokenId, 'car_refresh', { carId: carId }, 5000)

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

3️⃣ 批量收获（第1363行）

// 修改前
await tokenStore.sendMessageAsync(tokenId, 'car_claim', { carId: carId }, 5000)

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

4️⃣ 批量发送（第1463行）

// 修改前
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行修改中）

⚠️ 注意事项

可能的风险

超时风险：
- 网络较慢时，1000ms 可能不足以完成请求
- 服务器响应慢时，可能出现超时错误
- 高并发时，服务器压力大可能导致超时
失败处理：
- 如果频繁超时，自动重试机制会生效
- 部分任务失败会触发整体任务重试
适用场景：
- ✅ 网络状况良好
- ✅ 服务器响应快速
- ✅ 并发数适中（≤10）
- ❌ 网络不稳定
- ❌ 服务器负载高
- ❌ 超高并发（>20）

监控建议

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

成功率：
- 发车任务成功率是否下降
- 是否出现频繁的超时错误
重试频率：
- 自动重试是否频繁触发
- 重试后成功率如何

日志信息：

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

🧪 测试建议

测试场景1：正常网络环境

运行批量自动化，选择3-5个token
启用"发车"任务
观察：
- ✅ 发车任务是否快速完成（3-8秒）
- ✅ 是否有超时错误
- ✅ 最终发车数是否准确（4/4）

测试场景2：高并发环境

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

测试场景3：网络较慢环境

在网络不佳时运行批量自动化
观察：
- ⚠️ 超时错误频率
- 🔄 重试机制是否有效
- 💡 是否需要恢复更长的超时时间

📈 性能数据记录

建议记录的指标

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

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

🔄 回滚方案

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

方案A：仅恢复查询和验证（推荐）

// 查询车辆和最终验证
car_getrolecar: 1000ms → 5000ms

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

方案B：全部恢复（保守）

car_getrolecar: 1000ms → 10000ms
car_refresh: 1000ms → 5000ms
car_claim: 1000ms → 5000ms
car_send: 1000ms → 5000ms

方案C：折中配置（平衡）

// 所有操作统一为3000ms
car_getrolecar: 1000ms → 3000ms
car_refresh: 1000ms → 3000ms
car_claim: 1000ms → 3000ms
car_send: 1000ms → 3000ms

💡 未来优化方向

自适应超时：
- 根据历史响应时间动态调整超时
- 网络慢时自动延长，网络快时自动缩短
并发优化：
- 根据超时频率动态调整并发数
- 超时率高时自动降低并发
错误重试优化：
- 超时错误使用更短的重试间隔
- 其他错误使用标准重试间隔
配置UI化：
- 允许用户在设置中自定义超时时间
- 提供"快速/标准/保守"预设模式

🔗 相关文档

📝 版本历史

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）测试
✅ 观察成功率和超时频率
✅ 根据实际情况决定是否需要调整
⚠️ 如遇频繁超时，请参考回滚方案

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

7.9 KiB Raw Blame History Unescape Escape