Laravel:処理時間のかかるQueueで発生した3倍のデータ処理
- 2019.08.07
- php備忘録
- CSV一括更新, ECシステム, Laravel, MySQL, PHP, QueueWorker, スクリプト備忘録, リトライ, 自作システム, 自動化, 非同期処理
Laravel:処理時間のかかるQueueで起こった問題
商品情報を出品データに置き換えるパーツを作成して実行時間を測ろうと最大数で実行開始!
約5500件程度の楽天出品用CSVの作成に2時間かかり頭を悩ませてました。
「う~ん、何が原因なんだ…」と作成したデータを確認したところ、なんとレコード数が15057件!
何故5500件が15000件になるんだ??
3倍のデータ処理の謎
調べた結果、処理時間に時間が掛かるためQueueWorkerさんが気を利かせてリトライしてくれていたようです。
それでも気になるのは3回Queueが投げられたなら何故単純に3倍になってないんだという所。
まずは本当にリトライが原因なのか確かめるため、最大試行回数を設定してみます。
1 2 3 4 5 6 |
class hogehoge implements ShouldQueue { use Dispatchable, Queueable,InteractsWithQueue, SerializesModels; //最大試行回数 public $tries = 1; } |
無事に5000件だけ作成されました。
原因はやはりリトライか!
処理時間も短縮1/2に
それでもまだ1時間…なげーな。
単品更新とまとめ更新と同じスクリプト使えるようにパーツ分けした結果、店舗のURLリストのforeach が複数回行われてるので、見直す所はココかなぁ。
後はインデックスの付け方か。
SEOワードの最適化も商品毎に処理させてるのでワード数が増えると比例して処理時間もかかるんですよね。
まぁAPIで実行すれば粛々と更新作業をしてくれるので実行時間よりも確実性を求めた方が良いのかもしれません。
まとめ
今回はQueueのリトライによるレコード数増加と言う事態に遭遇してしまいました。
ただ、この更新パーツを完了させればシステムとしてはほぼ完成。
後は実地テストによるバグだしが待ってます。
あっ、マニュアルも書かなきゃだ。
やることあるなぁ~
頑張ろう!
-
前の記事
送料無料ライン統一。楽天市場崩壊の序章か 2019.08.06
-
次の記事
Laravel:大量データ処理の速度と利便性がトレードオフ 2019.08.08
コメントを残す