Google OR-Tools切割库存问题求解响应缓慢优化求助

一、OR-Tools求解器层面优化 #

• 选对求解器：切割库存属于整数/混合整数规划问题，优先用CP-SAT求解器（cp_model.CpSolver()），它在大规模整数规划场景下比GLOP等传统求解器更快，支持并行计算。
• 调整求解器参数：
  • 开启并行：设置solver.parameters.num_search_workers = 8（根据GCP实例CPU核心数调整，不超过核心数上限）。
  • 限制求解时长：若无需绝对最优解，设置solver.parameters.max_time_in_seconds = 30，指定时间内返回最优可行解。
  • 关闭冗余日志：设置solver.parameters.log_search_progress = False，减少IO开销。
• 简化模型：
  • 合并重复需求：将相同规格的child_rolls需求数量累加，减少变量与约束总数。
  • 过滤无效切割模式：提前排除child_roll总长度超过parent_roll长度的模式，减少无效计算。

二、GCP部署环境优化 #

• 升级实例配置：若当前用Cloud Functions，升级到e2-medium及以上规格；若用Cloud Run，将CPU分配设为1核以上，内存调整至2GB+，确保求解器有足够资源。
• 启用实例预热：Cloud Run设置min-instances = 1，Cloud Functions配置预热策略，避免冷启动额外延迟。
• 优化API运行模式：Flask/FastAPI部署时，用uvicorn的--workers参数启动多进程，利用多核CPU并行处理请求。

三、代码逻辑优化 #

• 预生成切割模式：离线计算所有有效切割模式，存储到GCP Cloud Memorystore（Redis）或内存中，请求时直接读取，避免实时生成的开销。
• 用向量化处理数据：用NumPy替代原生Python列表处理child_rolls和parent_rolls数据，提升批量计算速度。
• 优化数据序列化：API请求用Protocol Buffers二进制格式替代JSON，或用ujson库替代标准json库，减少解析耗时。

四、缓存策略优化 #

• 缓存重复请求结果：将相同child_rolls和parent_rolls输入的求解结果缓存到Redis或Cloud Firestore，后续相同请求直接返回缓存值。
• 缓存预计算模式：将预生成的有效切割模式持久化缓存，避免每次请求重复计算。

内容的提问来源于stack exchange，提问作者Hkachhia