worker が詰まる原因はメルマガだった話

はじめに

事の発端は、「worker による定期タスクが完了しない」 というお問い合わせでした。

cron から定期的に実行されている worker の処理において、ステータスを「公開」に変更する処理など、一部のタスクの実行が滞っている状況が確認されていました。

調査

調査を進めたところ、メルマガ送信処理が影響しており、当該環境では、約1,000件のメルマガ送信に 2時間ほどの処理時間を要していました。

メルマガ送信処理は 1件ずつビューをビルドしますが、この際にビルドされていたのは「複数のモデルを対象に期間指定で新着情報を検索し、メルマガの本文を生成するビュー」でした。

複数回の検索処理とオブジェクトループを行う構成となっており、1回のビルドあたりの処理負荷が高い状態でした。

そのため、1通あたりの処理時間は約6〜9秒となっており、この処理が長時間継続することでメモリ使用量が増大し、結果として他の worker による定期タスクが完了しない状況を引き起こしていました。

対応

このような処理負荷が高い状況に対し、サーバースペックの増強も選択肢として考えられましたが、メルマガ用のビューに <mt:cacheblock> を適用し、共通部分の再ビルドを抑制する対応を実施しました。

結果

対応の結果、

• 改善前：送信完了まで 約2時間
• 改善後：送信完了まで 約1分

と、処理時間を短縮することができました。

あわせて、メルマガ送信中に発生していたメモリ使用量の増大も解消され、worker による定期タスクも問題なく完了するようになりました。

まとめ

• worker の定期タスクが完了しない原因が、別処理（メルマガ送信）にあるケースがある
• サーバースペックを上げる前に、ビューの改善を検討する価値がある
• 共通部分に対して <mt:cacheblock> を活用することで、ビルド処理を大幅に高速化できる
• 個人情報を含む部分はキャッシュ対象に含めないよう注意が必要

テンプレートタグを活用することで処理負荷を軽減し、比較的手軽に改善できるケースもあります。
同様の状況でお困りの際には、本事例をご参考いただけますと幸いです。

カテゴリー：トラブルシューティング | サポート

投稿者：Matsuoka