あらすじ

そこで、Magentoでのcron構成の理解を確認したいと思いました。管理コンソールの下System > Configuration > Advanced > System > Cron：

＃ごとにスケジュールを生成

この設定が何であるか私にはわかりません。

＃先にスケジュール

私はこれがcronよりも＃分早くスケジュールされると想定しています。cronスケジューラがcronタブで5分ごとに実行されるように構成されている場合、この数も5に構成する必要がありますか、それともMagentoはすでにスケジュールされたジョブを再スケジュールしませんか？

＃内で実行しないと見逃される

これは、cronの実行がスケジュールされていて、＃分以内に実行されない場合、「欠落」と設定されているかのように見えます。

＃ごとの履歴クリーンアップ

これはcron_Scheduleテーブル全体で実行され、実行された/実行されなかった＃分後に、実行されなかったスケジュールと実行されたスケジュールをすべてクリアする必要があると思いますか？

成功履歴ライフタイム＃

以前の構成に関して、これで＃分後にすべての成功したスケジュールがクリアされると思いますか？

障害履歴の寿命＃

これは＃分後にすべての見逃したスケジュールをクリアすると思いますか？そして、history cleanup every #, success history and failure history設定はすべて完全にあいまいです。

Magentoのcronサービスについて混乱しているのは、システムcronによって呼び出される一方で、 Magento全体で共通のイベント/オブザーバーモデルの上位レベルで抽象化されていることです。

これを理解すれば、設定はより理にかなっています。それらが正確に何をしているのかを確認したい場合、その使用法はでかなり明確ですapp/code/core/Mage/Cron/Model/Observer.php。これはdefault、crontabスコープ内のイベントに対してトリガーされ、すべてのスケジュールされたジョブをディスパッチするオブザーバーです。

• スケジュールの生成間隔：Magentoが将来のジョブをスケジュールする分間隔。すべての実行中に自動的にジョブをスケジュールすることはありません。
• 事前スケジュール：ジョブをスケジュールできる（cron_scheduleデータベースキューに追加される）将来の分。
• 次の時間内に実行しないと見逃される：ステータスがに設定される前にジョブを実行できる予定時刻を過ぎた分missed。これは、キューがの現在の実行Mage_Cron_Model_Observer::dispatch()（スケジュールされた時刻は現在または以前です）。
• 履歴クリーンアップ間隔：Magentoがcron_scheduleデータベースキューに対してクリーンアップを実行する間隔（分）。保持に関する以下の設定を参照します。
• 成功履歴のライフタイムと失敗履歴のライフタイム：これらのステータスに達した後、レコードをキューに残す分数。これは、過去のジョブの結果を表示したいcron_schedule.messages場合に役立ちます。これは、結果の出力がに配置されている可能性があるためerrorです。これは、ステータスの場合に特に役立ちます。