PHP任务调度框架任务执行耗时统计与报表-php教程-PHP中文网

在laravel调度器中记录任务执行耗时，需在kernel.php的schedule()方法中用microtime(true)手动打点，从调度器触发时刻起算，而非在命令handle()中计时；队列任务则需通过trace_id串联入队、取出、执行等多节点时间戳；报表应按命令名、时段、状态聚合并计算p95、失败率等指标；swoole协程下须绑定协程上下文避免挂起时间干扰。

php任务调度框架任务执行耗时统计与报表

怎么在Laravel调度器里记录每个任务的执行耗时

默认情况下，schedule:run 命令只负责触发任务，不记录耗时。要统计，必须手动包裹执行逻辑——最稳妥的方式是在 app/Console/Kernel.php 的 schedule() 方法中，对每个任务使用匿名函数封装，并用 microtime(true) 手动打点。

常见错误是直接在命令类的 handle() 里计时，这只能捕获命令内部逻辑，漏掉框架初始化、服务容器解析、中间件等真实开销；而调度器层面的计时才反映用户感知的真实延迟。

不要依赖日志行时间戳推算，因为日志写入本身有缓冲和异步行为
避免在闭包里用 try/catch 捕获异常后吞掉错误，否则耗时统计会掩盖失败任务
若任务被 withoutOverlapping() 阻塞，耗时应从“实际开始执行”时刻起算，而非调度器检查时刻

示例（在 schedule() 中）：

$start = microtime(true);
$schedule->command('emails:send')->everyFiveMinutes()->then(function () use ($start) {
    $duration = round((microtime(true) - $start) * 1000);
    \Log::info('Task emails:send completed', ['duration_ms' => $duration]);
});

Laravel队列任务的耗时怎么准确采集

队列任务的耗时不能只看 handle() 方法执行时间，关键节点包括：入队时刻、被 worker 取出时刻、执行开始时刻、执行结束时刻。这些时间点分布在不同进程里，必须用统一上下文串联。

推荐做法是：在 dispatch 时注入唯一 trace_id，并在 Job 类的 __construct() 和 handle() 开头/结尾分别记录时间戳到 Redis 或数据库临时表。这样能排除网络延迟、序列化反序列化、worker 空闲等待等干扰。

不要用 date('U')，精度不够，必须用 microtime(true)
如果用了 retryAfter 或 tries，每次重试都应单独记录耗时，不能合并成一次
Redis 驱动下，注意 delay 参数会影响“入队到取出”的时间差，这个值本身也属于调度延迟的一部分

简单标记示例（在 Job 构造函数中）：

PHP

编写健壮的PHP代码，规避类型转换陷阱、数组怪癖及常见安全漏洞。

下载

public function __construct()
{
    $this->trace_id = Str::uuid();
    $this->enqueued_at = microtime(true);
}

如何生成可落地的任务耗时报表

原始耗时数据分散在日志或临时存储中，真正有用的报表需要聚合维度：按命令名、按小时段、按成功/失败状态、按是否重试。硬编码 SQL 或 PHP 数组遍历不可持续，应该用 Laravel 的 Telescope 或轻量级方案如自定义 Artisan 命令导出 CSV。

一个最小可行报表命令结构：

用 php artisan report:queue-duration --since=24hours 拉取最近24小时数据
聚合时区分 dispatched_at → processed_at（排队延迟）和 processed_at → finished_at（执行耗时）
输出含 P95、平均值、最大值、失败率，避免只看平均数掩盖长尾问题

注意：如果用数据库存耗时，别把所有字段都设为 TEXT，duration_ms 必须是 INT 或 DECIMAL(8,2)，否则后续排序、分组、索引都失效。

为什么 Swoole 协程环境下耗时统计容易失真

在 Swoole 的协程环境中，microtime(true) 依然可用，但问题出在「执行上下文」上：同一个 worker 进程内多个协程共享内存和时钟，如果任务中调用了 Swoole\Coroutine::sleep() 或等待 I/O，microtime 会包含挂起时间——而这部分时间本不该计入业务逻辑耗时。

更隐蔽的问题是，Swoole 的 tick() 定时器回调可能在协程未恢复前就触发，导致你误以为任务“提前完成”。所以协程任务的耗时必须用 go() 启动时的协程 ID + 事件循环钩子来绑定，而不是简单靠时间差。