日本語

開発者ツール · Crontab ジェネレーター

cron ジョブを毎分実行する: ポーリングが間違っている場合と何を使用するか

· なぜそれが重要なのか

クロン ポーリング パフォーマンス

1 つの 5 フィールドのワイルドカード式の横にある 60 分刻み
オリジナル ToolAcre ベクトル イラスト

毎分ジョブは作成が簡単ですが、コストがかかります。この記事では、コスト、コストが正当化されるケース、およびデーモンやイベント トリガーに代わるより長い間隔について説明します。

毎分構文は、1 日の完全な 24 時間に 1,440 カレンダー候補を作成します

`* * * * *` は、0 から 59 までの分ごと、時間ごと、カレンダーの日付ごとに展開されます。 1 日 24 時間、壁時計の分ラベルと一致する 1,440 が生成されます。 ToolAcre のプリセットとテストは文法を確立しますが、そのプレビューではインターフェイスを読みやすくするために次の 5 つの候補のみが表示されます。

カウントは、成功したアクションではなく機会を表します。フォワード ゾーン移行中に存在しないローカル分は、このプレビューによって省略でき、ブラウザーはタスクを実行しません。この式を使用してリズムを推論し、コマンドとスケジューラが存在する実際の実行時の効果を測定します。

式だけから実行時コストを計算することはできません

式には、プロセスの起動時間、接続数、ログ量、リソース使用量は含まれません。 1 行の小切手と大量の輸入では、同じ 5 つ星を獲得できますが、比類のないコストがかかります。ワークブックのオーバーヘッドのリストはもっともらしいかもしれませんが、ToolAcre はスケジュール テキストからオーバーヘッドを定量化できません。

したがって、パフォーマンス分析はジェネレーターの外部で開始されます。つまり、継続時間、CPU、I/O、および実際のアクションのダウンストリーム呼び出しを観察します。代表的な実行を測定した後でのみ、候補頻度を慎重に乗算してください。パーサーは、何分の値が一致するかを知ることができます。各試合のコストを知ることはできません。

適合性は外部アクションとレイテンシー要件に依存します

毎分ポーリングが正当化されるかどうかは、待ち時間の要件とアクションの設計によって異なります。 ToolAcre は、コマンドが冪等であるかどうか、イベント ソースが存在するかどうか、ユーザーが許容できる遅延はどれくらいかどうかを知りません。スケジュールに本質的に良いか悪いかのラベルを付けるべきではありません。

要件を最大許容間隔に変換し、それを観察されたコストおよび障害処理と比較します。 5 分の遅延で十分な場合、`*/5 * * * *` は 1 分の候補を 1 時間あたり 12 に減らします。 1 分のレイテンシのみで機能する場合は、リズムを維持し、実行上の懸念事項に明示的に対処します。

分単位のオフセットは固定の時間単位の作業を分散しますが、ランダム化はしません

`7 * * * *` などの固定オフセットは、毎時 7 分を選択します。これにより、そのジョブを 0 分に固定された作業から分離できますが、それはランダムではなく決定的です。正確な終了分が重要でない場合、複数のオフセットを使用すると、既知のジョブを時間全体に分散できます。

ToolAcre は毎時 7 分を説明し、対応する日付をプレビューします。ホスト上の他のスケジュールは検査しないため、選択されたオフセットが静かであることを証明することはできません。負荷が分散されたと主張する前に在庫を作成し、オフセットの理由を文書に保存します。

ワーカーとサービス タイマーはこのリポジトリ外の代替手段です

一部のシステムでは、長時間実行されるワーカー、イベント配信、およびサービス マネージャー タイマーがポーリングを置き換えることができます。 Crontab ジェネレーターによって実装されるものはなく、その構成は `* * * * *` から推測できません。リポジトリには、キュー クライアントやスーパーバイザの統合はありません。

ターゲット アーキテクチャの証拠から代替案を選択します。作業者は、ライフサイクルと回復の要件を導入しながら、繰り返し起動を削除することができます。イベント パスは、配信セマンティクスを追加しながら空のチェックを減らすことができます。ジェネレーターは残りの定期タスクには引き続き役立ちますが、それらのトレードオフを判断することはできません。

実践例: 候補の頻度を減らし、プレビューを比較する

パネル内の 3 つの式 (毎分、`*/5 * * * *`、`7 * * * *`) を比較します。 1 つ目は 1 分進み、2 つ目は 0、5、10 およびその後の倍数を選択し、3 つ目は 1 時間あたり 1 分の位置を選択します。説明では、ポーラーを実行せずに各変更を公開します。

これらの候補リストを使用して、遅延について具体的に議論します。 5 分の候補の直後にリクエストが到着した場合、次の機会はほぼ 5 分以内にあります。この単純な境界がスケジュールの証拠になります。処理時間、キューの遅延、成功は、ブラウザーが提供できない追加の測定値のままです。

これでカバーされないもの — cron では表現できない分未満のスケジューリング

このパーサーは分で始まるため、5 フィールド cron は秒を表現できません。 6 フィールド入力は、より高い周波数として処理されるのではなく、拒否されます。 1 分未満の作業をエミュレートするためのシェル ループの作成は、ToolAcre の外部でのコマンド動作であり、ランタイム固有のテストを行わない場合はここでは推奨されません。

要件が 1 分未満の場合は、その解決策用に設計および文書化されたスケジューラーまたはワーカーを選択します。サポートされていない秒値を最初のフィールドに強制的に入力しないでください。正確な 5 フィールドのエラーは、高速に見える式が黙って誤読されるのを防ぐ便利な方言ガードです。

要点: ニーズを満たす最も粗い間隔を選択すると、ジェネレーターによって */5 または */15 式が 5 つ星ほど簡単になります

測定されたニーズを満たす最も粗いリズムを選択しますが、その決定は式の妥当性とは切り離してください。 ToolAcre は、分単位、5 分単位、およびオフセット スケジュールを構文的に同様に正確に作成できます。どちらがシステムに属するかを決定するのは、運用上の証拠のみです。

ジェネレーターを使用して機会を列挙し、ターゲットからのコスト、レイテンシ、信頼性の測定値を添付します。この組み合わせた記録は、あらゆる場合に毎分の cron が高価であると宣言したり、頻度の低い式によって非効率な作業が自動的に修正されると想定したりするよりも正直です。