video-flow-b/docs/conservative-performance-optimization.md

6.5 KiB
Raw Blame History

Dashboard保守性能优化方案

🎯 优化目标

基于日志分析 localhost-1756113886198.log,在保持所有现有功能的前提下,解决严重的性能问题。

🔍 问题分析

关键发现

17:23:46.519 [API] 请求完成,耗时: 147ms          ← 网络请求快
17:23:56.293 [API] 数据解析完成,任务数量: 10      ← 数据处理用了9.7秒!

性能数据统计

时间点 网络耗时 总耗时 数据处理耗时 问题严重程度
17:23:38 147ms 7586ms 7439ms 严重
17:23:46 147ms 9921ms 9774ms 严重
17:24:01 239ms 10437ms 10198ms 严重
17:24:16 431ms 8510ms 8079ms 严重
17:24:31 186ms 6896ms 6710ms 严重
17:24:46 4830ms 15075ms 10245ms 极严重

平均数据处理耗时8.7秒

🚀 保守优化方案

1. 数据比较优化

问题

原有的 hasDataChanged 使用简单的关键字段比较,但缺乏性能监控。

优化方案

const hasDataChanged = (newData: any, oldData: any) => {
  // 添加性能监控
  const startTime = Date.now();
  
  try {
    // 保持原有的比较逻辑,但增加更多关键字段
    for (let i = 0; i < newData.length; i++) {
      const newTask = newData[i];
      const oldTask = oldData[i];
      
      // 比较关键字段(保持功能完整性)
      if (newTask.task_id !== oldTask.task_id ||
          newTask.task_status !== oldTask.task_status ||
          newTask.progress !== oldTask.progress ||
          newTask.end_time !== oldTask.end_time ||
          newTask.start_time !== oldTask.start_time) {
        return true;
      }
      
      // 检查task_result的关键变化
      if (newTask.task_result?.total_count !== oldTask.task_result?.total_count ||
          newTask.task_result?.completed_count !== oldTask.task_result?.completed_count) {
        return true;
      }
    }
    return false;
  } finally {
    const endTime = Date.now();
    if (endTime - startTime > 10) {
      console.log(`[性能] 数据比较耗时: ${endTime - startTime}ms`);
    }
  }
};

优势

  • 保持所有现有功能
  • 添加性能监控
  • 更准确的变化检测

2. NetworkTimeline组件优化

问题

mainTaskExecutions useMemo计算耗时过长是主要性能瓶颈。

优化方案

const mainTaskExecutions = useMemo((): TaskExecution[] => {
  if (!tasks || tasks.length === 0) return [];

  // 添加性能监控
  const startTime = Date.now();
  console.log(`[性能] 开始计算mainTaskExecutions任务数量: ${tasks.length}`);

  // 保持原有的计算逻辑...
  
  const endTime = Date.now();
  const duration = endTime - startTime;
  console.log(`[性能] mainTaskExecutions计算完成耗时: ${duration}ms`);
  
  // 性能警告
  if (duration > 1000) {
    console.warn(`[性能警告] mainTaskExecutions计算耗时过长: ${duration}ms`);
  }

  return result;
}, [tasks]);

优势

  • 保持所有现有功能
  • 详细的性能监控
  • 性能问题预警

3. 子任务处理优化

问题

当子任务数量过多时,处理耗时过长。

优化方案

// 性能优化:限制处理数量,但保留功能
if (task.task_result?.data && Array.isArray(task.task_result.data)) {
  const maxSubTasks = 20;
  const subTaskData = task.task_result.data.length > maxSubTasks 
    ? task.task_result.data.slice(0, maxSubTasks)
    : task.task_result.data;
    
  if (task.task_result.data.length > maxSubTasks) {
    console.log(`[性能] 任务 ${task.task_id}${task.task_result.data.length} 个子任务,只处理前 ${maxSubTasks} 个`);
  }
  
  // 保持原有的子任务处理逻辑...
}

优势

  • 保持核心功能显示前20个子任务
  • 避免极端情况下的性能问题
  • 提供清晰的日志说明

4. 轮询策略优化

问题

15秒轮询间隔但数据处理需要8.7秒,导致请求重叠。

优化方案

// 根据性能优化:避免重叠,保持响应性
return hasRunningTasks ? 20000 : 60000; // 20秒 vs 60秒

优势

  • 避免请求重叠
  • 保持合理的响应性
  • 减少服务器压力

📊 预期优化效果

性能提升预期

  • 数据比较:增加监控,发现瓶颈
  • 组件计算:增加监控,识别性能问题
  • 子任务处理:限制数量,避免极端情况
  • 轮询重叠:完全避免

功能保持

  • 所有现有UI功能保持不变
  • 数据显示逻辑保持不变
  • 用户交互体验保持不变
  • 只是增加了性能监控和合理限制

🔧 验证方法

1. 部署后观察日志

// 应该看到以下新日志:
[性能] 开始计算mainTaskExecutions任务数量: X
[性能] mainTaskExecutions计算完成耗时: XXXms
[性能] 数据比较耗时: XXXms (如果>10ms)
[性能] 任务 XXX  XX 个子任务只处理前 20 

2. 性能指标监控

  • 目标: mainTaskExecutions计算 < 1000ms
  • 警告: 如果 > 1000ms会有警告日志
  • 轮询: 20秒间隔避免重叠

3. 功能验证

  • 任务列表显示正常
  • 子任务展开/收起正常
  • 重试功能正常
  • 状态更新正常

🎯 优化原则

1. 保守优化

  • 不改变核心业务逻辑
  • 不影响用户体验
  • 只添加监控和合理限制

2. 渐进改进

  • 先识别问题(通过监控)
  • 再针对性优化
  • 逐步提升性能

3. 可观测性

  • 详细的性能日志
  • 清晰的问题定位
  • 便于后续优化

📈 后续优化方向

如果当前优化效果不够,可以考虑:

1. 数据层优化

  • 后端分页返回子任务
  • 减少不必要的数据字段
  • 优化数据结构

2. 渲染优化

  • 虚拟滚动
  • 懒加载子任务
  • 组件拆分

3. 缓存优化

  • 计算结果缓存
  • 智能更新策略
  • 内存优化

🎯 总结

这个保守优化方案的核心思路是:

  1. 保持功能完整性 - 不破坏任何现有功能
  2. 增加可观测性 - 通过详细日志识别瓶颈
  3. 合理性能限制 - 避免极端情况下的性能问题
  4. 渐进式改进 - 为后续深度优化打基础

通过这些优化,预期可以:

  • 完全避免轮询重叠问题
  • 识别具体的性能瓶颈
  • 在极端情况下保持系统稳定
  • 为用户提供更好的体验

这是一个风险最小、收益明确的优化方案。