當 Laravel Queue 開始落後時，我會先檢查什麼

Queue 延遲很少是單一問題造成的。更常見的情況是，它只是系統中其他壓力逐漸堆積後浮現出來的表面症狀，例如資料庫競爭、第三方服務延遲、worker 設定漂移，或某些 job 隨著時間變得越來越昂貴。

當一個高度依賴 queue 的 Laravel 服務開始跟不上時，我通常會先快速回答四個問題：

• job 是不是因為 worker 不夠而在等待？
• job 是不是因為依賴服務變慢而在等待？
• job 是不是因為失敗被淹沒在噪音中而不斷重試？
• 工作負載的型態是否已經改變，但 queue 設定卻沒有一起調整？

先看吞吐量，不要先靠直覺

在調整 worker 數量或 timeout 之前，我想先看到一張夠簡單的圖，能清楚呈現吞吐量與到達率的關係。如果 queue 每分鐘進來的工作量大於 worker 能完成的量，那擴容方向就會很明確。如果只有某一類 job 開始延遲，問題通常就更集中。

我通常會把三種訊號一起畫出來：

• 每分鐘進入 queue 的 job 數
• 每分鐘完成的 job 數
• 依 job 類型區分的平均執行時間與百分位執行時間

這個視角往往就足以區分問題到底是容量不足，還是某個回歸造成的異常。

留意隱性的序列化成本

在 Laravel 應用裡，queue 效能問題常常跟 job 主體真正開始執行前就已經發生的事情有關。過大的 payload、過度積極的 model serialization，以及昂貴的 hydration 模式，都可能把原本平常的 job 變成不必要的工作量。

最快能見效的改善，通常來自讓 job payload 更小、更明確：

php artisan queue:work redis --queue=default,notifications --sleep=1 --tries=3

這條指令本身不是解法，但它很適合拿來驗證 worker 行為是否真的符合你對正式環境的預期。

檢查 job 周邊的依賴路徑

如果某個 queued job 會打外部 API、物件儲存，或碰到已經飽和的資料庫副本，那 queue 往往只是把那個依賴問題放大。很多 backlog，其實是某個下游服務只比平常慢一點點後，在整體系統中被放大的結果。

這就是 traces 與 structured logs 真正重要的地方。我想知道到底是 job 本身很昂貴，還是大部分時間都在等 I/O。這兩種情況的修復方向完全不同。

讓失敗模式變得無法被忽視

當 queue 開始退化時，間歇性失敗往往比完全掛掉更危險，因為表面上工作似乎還在推進。我傾向把重試次數與成功所需時間當成一級訊號來追，而不只是盯著 failed job 數量。

這通常代表你要能從 dashboard 或 alert 中回答這些問題：

• 哪些 job 最常重試？
• 哪一條 queue 的 backlog 增長最快？
• 一個重試中的 job 最後要多久才會成功，或永久失敗？

系統看得清楚之後，再來調參

一旦系統夠可觀測，調整就會容易很多。有時候解法真的是增加 worker；但也可能是縮短 transaction、減少 job 裡的查詢、優化 cache 策略，或拆分 queue，避免長時間工作阻塞使用者相關任務。

重點是不把 queue 延遲當成只有 queue 自己的問題。大多數時候，那其實是應用行為的問題，只是 queue 把它清楚地暴露了出來。

我的預設原則很簡單：在調整 worker 數量之前，先量出到達率、執行時間、重試情況，以及依賴服務延遲。只要這四項能一起被看見，多數 queue 事故就會少很多神祕感。