Yukino
Yukino
建议用新一点的版本😂 OhMyWorker 版本太老旧了 =。= 换成 4.x 或者 5.x 吧
稳定复现吗？还是部分任务会有这个问题？ 顺便找找 worker 的 WARN、ERROR 日志，有没有状态上报失败的异常信息
timeout的具体原因需要进一步分析，是 client 请求 server timeout 了，还是 server 内部执行超时了（比如数据库抖动导致 rt 过长）。 可以去捞下日志进一步分析
感谢反馈，后续版本修复。 dongdonglip ***@***.***>于2025年3月21日 周五15:05写道： > 5.1.1 版本中，client段设置超时时间有bug,如下图，下面将client整个调用超时时间设置为了连接超时时间，这里的callTimeOut > 实际是解析 DNS、连接、写入请求正文、服务器处理和读取响应正文。如果调用需要重定向或重试，所以经常导致client 端，调用openapi 接口超时 > > image.png (view on web) > > > image.png (view on web) > > > image.png (view...
自动分裂 subApp 确实是之前我考虑过的，某个 app 超过上限处理能力以后的处理方式。 不过目前看很少有场景会超过这个限制，就算有业务自己做逻辑拆分其实也不困难。 因此这个事情优先级不算很高。 性能这块，目前的重点还是在榨干本身的单机调度能力上，现在单 app 内的并行化处理啥的都没做，单机性能其实还有很大空间。再结合现在 CPU 的算力，这块天花板其实会相当高。
近期 PowerJob 的2个重点方向： 1. 可观测性：系统自身全面的监控、报警能力 2. 性能优化：目前的调度派发其实无法完全榨干一台高配机器，导致单 app 下的调度能力看起来存在瓶颈
临时解决方案：自行修改 server 的 `WEB_LOG` 日志等级，可以 off 掉 后续确实我们得优化下 OpenAPI 的日志输出，assert 类接口需要屏蔽下
serever 侧捞日志看看？是不是触发了什么失败重试机制。仅靠当前信息无法准确定位和排查。
关于为什么期望能自定义线程池，可以能举几个具体的场景吗？ 是什么地方有瓶颈还是啥