高度な設定 - タイミング
「タイミング」は、再リクエスト周期、タイムアウト、およびAlive Notice設定を含む区間制御セグメントのタイミング動作を制御する高度な構成で、システムパフォーマンスおよびユーザー体験を最適化します。
概要
区間制御セグメントの高度なタイミング設定は、4つの主要なタイミング側面を管理します：
- 再リクエスト周期: 待合室の訪問者が進入権限を確認する頻度を制御
- Alive Notice 再リクエスト周期: ユーザーが保護された区間内にいる間、システムが「まだアクティブ状態」信号を送信する頻度を制御
- Alive Notice 期間満了: ユーザーが保護された区間内で維持できる最大期間を設定
- タイムアウト: 活動または完了信号が受信されない場合、自動的にリソースを解放
これらの設定は、システムが状態確認を処理し、多段階区間全体にわたってアクティブユーザー状態を維持する時点と頻度を構成して、サーバーパフォーマンスとユーザー体験のバランスを取るのに役立ちます。
タイミングオプションが一緒に動作する方法:
- 再リクエスト周期: ユーザーが待合室にいる間のみアクティブ
- Alive Notice周期: ユーザーがアクティブ状態の間、定期的にタイムアウトカウントダウンを初期化
- Alive Notice 期間満了: Alive Notice送信の最大期間を設定（デフォルト300秒）
- タイムアウト: タイムアウト期間中Alive Noticeが到着しない場合のみトリガー（デフォルト20秒）
関係: Alive Notice周期 < タイムアウト < Alive Notice 期間満了
再リクエスト周期
機能: 待機中の訪問者が進入可能性を確認するために送信するリクエスト間の動的タイミングを制御します。システムは各訪問者の待機順番に基づいてこの周期をインテリジェントに調整します。
コワーキングスペース予約待機列を考えてみてください：列の前の方にいる人々はフロントデスクを頻繁に確認します（「今デスクが使用可能ですか？」）、一方、後ろの方にいる人々はあまり頻繁に確認しません。NetFUNNELは同じロジックを適用します - 進入に近い訪問者は1-2秒ごとに確認し、後ろの方にいる訪問者は8-10秒ごとに確認します。これは予約システムを圧倒しないようにしながら、前の方の人々がデスクが使用可能になったときに見逃さないように保証します。
動作方法:
- 周期的状態確認: 訪問者の待合室ロジックが進入権限を確認するためにNetFUNNELサーバーに繰り返し連絡
- サーバー応答: 各リクエストはPASS（進入進行）またはWAIT（継続待機）を受信
- TTL (Time To Live): WAIT応答には、次の確認前に正確にどれくらい待つ必要があるかをクライアントに知らせるTTL値が含まれる
- 動的計算: TTLは各訪問者の待機順番に基づいて計算される
範囲を構成する理由、固定値ではない:
異なる訪問者は待機列を通じて移動しながら変化する異なる確認頻度が必要です。単一の固定周期ではなく範囲（例：1-10秒）を構成します。
- 前の方に近い訪問者: より短いTTL値を受信 → より頻繁に確認 → リソースが使用可能になるとより迅速な進入
- 後ろの方の訪問者: より長いTTL値を受信 → あまり頻繁に確認しない → 不要なサーバーリクエストの減少
- 進行しながら: TTL値が自動的に減少し、待機中全体にわたって優先順位に適した確認頻度を保証
これはサーバー負荷（不要なリクエストの減少）とユーザー体験（使用可能なときに即座に進入）のバランスを取ります。
視覚的な例（範囲: 1-10秒）:
待機順番 TTL値 確認頻度
─────────────────────────────────────────────────
前の方 → 1-2秒 → 非常に頻繁
中-上 → 3-5秒 → 普通
中-下 → 6-8秒 → あまり頻繁でない
後ろの方 → 9-10秒 → 最も頻繁でない
訪問者1 （待機列の前の方）
↓ 進入に近づくほどより頻繁に確認
↓
訪問者100 （待機列の中間）
↓ 進行しながらTTLが段階的に減少
↓
訪問者500 （待機列の後ろの方）
このグラデーションは、前の方の訪問者がリソースが使用可能になると迅速な進入を受けられるように保証しながら、後ろの方の訪問者が不要なリクエストでサーバーを圧倒しないようにします。
デフォルト: 最小1秒、最大10秒
構成可能な範囲: 最小値と最大値の両方が1-60秒
構成方法:
- セグメントの高度な設定に移動
- 最小値を設定（1秒推奨）
- 最大値を設定（10秒推奨）
- システムが待機順番に基づいてこの範囲内で各訪問者の周期を自動的に調整
推奨事項: デフォルト値（1-10秒）を使用してください。これらはNetFUNNELサーバー仕様に最適化されています。変更することは一般的に必要ありません - デフォルトのバランスはすでにシステム容量を考慮しています。パフォーマンスモニタリングで特定の要件がある場合にのみ調整してください。
Alive Notice 再リクエスト周期
機能: ユーザーが保護された区間内でアクティブ状態の間、NetFUNNELエージェントがサーバーにAlive Notice（opcode 5003）信号を送信する頻度を制御します。この信号はサーバーに「まだここにいてリソースを使用中です」と知らせ、タイムアウトによる自動キー返却を防止します。
必要な理由: 区間制御では、ユーザーは多段階区間全体（例：コンサート選択、時間帯選択）にわたってリソースを占有します。活動が検出されない場合、キー返却タイムアウトが自動的にリソースを解放しますが、ユーザーは複数のページをナビゲートする間アクティブ状態を維持する必要があります。
動作方法:
- 自動周期的送信: ユーザーが保護された区間に進入すると、NetFUNNELエージェントが構成された周期でAlive Noticeリクエスト送信を自動的に開始
- サーバー応答: 各Alive Noticeがサーバーのキー返却タイムアウトタイマーを初期化
- 連続ループ: ユーザーが区間内に残っている間（Alive Notice 期間満了まで）、エージェントがこれらの信号送信を継続
- リソース保護: Alive Noticeが継続して到着する限り、サーバーはユーザーのリソース占有を維持し、アクティブユーザーとして維持
デフォルト: 5秒
構成可能な範囲: 1-60秒
この周期が重要な理由:
- 短すぎる（例：1-2秒）: 多くのユーザーがアクティブ状態のときに過度なサーバーリクエスト、潜在的にサーバーを圧倒
- 長すぎる（例：10秒以上）: 周期がキー返却タイムアウト閾値を超えると、サーバーがユーザーが離れたと考え、次のAlive Noticeが到着する前に自動的にリソースを解放する可能性がある
- 重要な制約: Alive Notice 再リクエスト周期はタイムアウト最小値よりも短くなければ、早期リソース解放を防止
推奨事項: デフォルト値（5秒）を使用してください。これはタイムアウトベースの解放を防止するのに十分に頻繁に確認しながら、サーバー負荷を管理可能に維持します。パフォーマンスモニタリングに基づいて特定の要件がある場合にのみ調整してください。
視覚的な例:
各Alive Noticeがサーバーのタイムアウトカウントダウンを0に初期化します。これは、ユーザーがアクティブにページをナビゲートしている間（5秒ごとに）タイムアウトがトリガーされないことを意味します。ユーザーがAlive Notice送信を停止するときのみ（例：ブラウザを閉じる）タイムアウトカウントダウンが完了します。
Alive Notice 期間満了
機能: システムがAlive Notice送信を停止する前に、ユーザーが保護された区間内でアクティブ状態で維持できる最大総期間を設定します。これは、自動解放される前にユーザーがリソースを占有できる上限です。
必要な理由: Alive Notice 期間満了制限なしでは、停止した、または意図的に区間に無期限に留まるユーザーがリソースを永遠に占有し、他の待機中のユーザーの進入を防止する可能性があります。Alive Notice 期間満了は、ユーザーが完了ポイントに到達しなくても、リソーススロットが最終的に解放されることを保証します。
動作方法:
- グローバルタイマー: 満了タイマーは、ユーザーが最初に保護された区間に進入するときに開始
- 連続追跡: このタイマーは区間内のすべてのページにわたって持続（ページ間移動時に初期化されない）
- Alive Notice送信制限: 満了タイマーに時間が残っている限り、エージェントがAlive Notice送信を継続
- 自動停止: 満了期間に到達すると、エージェントがAlive Notice送信を停止
- リソース解放: Alive Noticeが停止すると、標準のタイムアウトメカニズムが構成されたタイムアウト期間後にリソースを解放
例えば、Alive Notice 期間満了が300秒（5分）に設定され、タイムアウトが20秒の場合：
- ユーザーが区間進入 → 満了タイマー開始（300秒カウントダウン）
- エージェントが最大300秒間、5秒ごとにAlive Notice送信
- 300秒にエージェントがAlive Notice送信停止
- 20秒後（合計320秒）、タイムアウトがリソースを解放
視覚的な例:
- Alive Notice 期間満了: エージェントがAlive Noticeを送信する最大時間（例：300秒）。到達すると、エージェントがすべてのAlive Notice送信を停止します。
- タイムアウト: 最後の活動後、サーバーが自動解放前に待機する時間（例：20秒）。これは最後のAlive Noticeが受信された後にカウントダウンを開始します。
上記の例では: 300秒（Alive Notice 期間満了） + 20秒（タイムアウト） = 解放前の合計320秒リソース占有。
デフォルト: 300秒（5分）
構成可能な範囲: 60-3600秒
この期間が重要な理由:
正しく設定:
- 目標: 区間全体を通じた平均ユーザージャーニー時間 + 安全バッファ（一般的に20-30秒）
- 例の計算: 平均チェックアウトが120秒かかる → Alive Notice 期間満了を150-180秒に設定
- 短すぎる: 正常ユーザーがプロセス途中でブロックされ、早期に位置を失い、不必要に他の人をブロックする可能性がある
- 長すぎる: 実際に放棄した、またはエラーに遭遇したユーザーが無期限にリソースを占有し、ボトルネックを作成
ガイドライン:
- 実際の平均区間ジャーニー時間を測定
- 遅いユーザーのために20-30秒を安全バッファとして追加
- チェックアウト/登録の場合: 一般的に2-5分（120-300秒）
- より長いプロセスの場合: 実際のユーザー行動に基づいて調整
- 重要: Alive Notice 期間満了は常に最も長い予想合法使用例よりも長くなければならない
推奨事項: 実際のユーザージャーニー時間をモニタリングし、Alive Notice 期間満了を平均時間 + 30秒に設定してください。保守的に開始し、メトリックに基づいて調整してください。
タイムアウト
機能: 訪問者がサービスセッションを適切に完了しない場合、訪問者の進入スロットを自動的に解放して、リソースが待機中の他の人に継続して使用可能であることを保証します。
訪問者がサービスに進入すると、NetFUNNELはリソース使用を追跡します。訪問者が完了した後（購入完了、コンテンツ閲覧、またはサービス相互作用）、NetFUNNELは次の待機中の訪問者のためにスロットを解放するために完了通知を期待します。
時にはこれが発生しません：訪問者がブラウザを閉じる、他の場所に移動する、エラーに遭遇する可能性があります。タイムアウトなしでは、スロットが無期限に占有され、すべての待機中の訪問者をブロックします。
キー返却タイムアウト（「タイムアウト」と呼ばれる）は、最後の活動（Alive Noticeまたはキー返却リクエスト）後、サーバーが自動的にリソースを解放する前に待機する最大期間です。これは、放棄された、または停止したユーザーによってリソーススロットが無期限に保持されることを防止します。
このように考えてみてください：予約されたデスクにいて、システムが5秒ごとに周期的確認を受けています：「まだここにいますか？はい。」そして突然、これらの確認が到着しなくなります - 緊急の電話を受けてチェックアウトなしで離れた、セッションがクラッシュした、ブラウザを閉じた可能性があります。システムが気づきます：「20秒間確認を受けていません。離れた可能性があります。」確認がない20秒後、システムが自動的にデスク予約を解放し、次の待機中の人が使用できるようにマークします。これが安全メカニズムです：誰かが適切にチェックアウト（nfStopSection）せずに消えても、デスクが永遠に「予約された」状態で維持され、他の人の作業をブロックしないようにします。
動作方法:
- タイムアウトカウントダウン: 進入が許可されると開始（0秒）
- Alive Noticeがタイムアウトを初期化: 受信された各Alive Noticeがタイムアウトカウントダウンを0に初期化
- 完了検出:
- コードベース統合（CBI）: サービスがnfStopSection()を呼び出すときに完了が信号される
- 正常フロー: 適切な完了が受信されると、スロットが正常に解放される
- タイムアウトシナリオ: タイムアウト期間中Alive Noticeが到着しない場合（デフォルト6-20秒）、NetFUNNELが自動的にスロットを解放
タイムアウトがAlive Noticeと相互作用する方法:
Alive Noticeが到着を停止するときタイムアウトがトリガー:
デフォルト: 6-20秒範囲（一般的にデフォルト20秒）
構成可能な範囲: 最小値と最大値の両方が6-60秒
範囲である理由:
NetFUNNELは完了率 - 進入のために発行されたキーに対する返却/収集されたキーの比率 - に基づいてタイムアウトを動的に調整します。100%完了率はすべてのキーが適切に返却されていることを意味し、低い比率はキーが返却されていないことを示します（タイムアウトベースの自動解放が必要）。
- 低い完了率（キーが適切に返却されていない） → タイムアウトが最小値（6秒）の方に移動し、停止したリソースをより迅速に解放するのに役立つ
- 高い完了率（キーが適切に返却されている、100%に近い） → タイムアウトが最大値（20秒）の方に移動し、訪問者が完了する十分な時間を提供
6-20秒である理由:
デフォルト範囲は、サービス整合性とリソースロック防止のバランスを取ります：
- サービス作業: API応答（ミリ秒）、ページロード（一般的に1-2秒）
- 20秒: 訪問者が作業を完了する十分な時間を提供
- 低すぎる（例：1-2秒）: サービスが完了する前に早期解放を引き起こす可能性がある
Alive Notice 再リクエスト周期はタイムアウト最小値よりも短くなければ、早期リソース解放を防止します。
例えば、タイムアウト最小値が6秒の場合、Alive Notice周期は5秒以下でなければなりません。そうでない場合、次のAlive Noticeが到着する前にタイムアウトがトリガーされ、合法的なアクティブユーザーがリソースを失う可能性があります。
ベストプラクティス
1段階: Alive Notice 期間満了に集中
重要な設定のみを調整してください。
以下の3つはデフォルト値を使用できます：
- 再リクエスト周期（1-10秒）: 待合室待機列確認 - NetFUNNELサーバーパフォーマンスに最適化
- Alive Notice 再リクエスト周期（5秒）: アクティブ状態確認頻度 - サーバー負荷と応答性のバランス
- タイムアウト（6-20秒範囲）: 自動返却時間 - デフォルトで最後のAlive Notice後の最大タイムアウト後にキーが自動的に返却される
しかし、Alive Notice 期間満了は慎重な考慮が必要です。
重要な理由は何ですか？
過度な進入を防止する上限です。
進入が許可された後、ユーザーはサービスジャーニー全体にわたってリソースを占有し、この時間中、他のユーザーは進入できません。Alive Notice 期間満了が経過しない限り、該当スロットは「占有された」状態で維持されます。
⚠️ 短すぎる → 正常ユーザーが強制的に追い出される
例: Alive Notice 期間満了が100秒に設定されているが、実際の平均ジャーニー時間が150秒の場合：
- Alive Noticeがプロセス途中で停止し、サーバーが「このユーザーが離れた」と考える
- アクティブユーザーがリソースを奪われ、サーバーが次のユーザーが進入するように許可
- → 過度な進入発生 → サーバー過負荷 → システム失敗
⚠️ 長すぎる → リソース解放遅延
- 実際に放棄した、または離れたユーザーが継続してAlive Notice信号を送信
- リソースが不必要に長期間占有される
- → 待機列ボトルネック → 悪いUX
構成方法
Alive Notice 期間満了 = 平均ジャーニー時間 + 安全バッファ（20-30秒）
具体的な例：
- 区間の平均ジャーニー時間が150秒の場合 → Alive Notice 期間満了を160-180秒に設定
- 区間の平均ジャーニー時間が120秒の場合 → Alive Notice 期間満了を150-180秒に設定
2段階: タイムアウトも考慮
タイムアウトは、Alive Notice信号もキー返却信号も送信しないユーザーをどれくらい待つかを定義します。
複雑な理由は何ですか？
ユーザーが正常に完了する場合でも、サーバーは知りません。
ユーザーが「予約完了」をクリックするとき：
- UI処理
- ネットワーク通信
- サーバー応答
- nfStopSection()呼び出し
この段階中、サーバーは「サービスがまだ完了していません」と仮定する必要があります。
構成方法
「完了」ボタンクリック → nfStopSection()呼び出しまでの時間
API処理遅延およびブラウザレンダリング時間を考慮した安全バッファを含めてください。
例: 平均3秒かかる場合 → タイムアウトを5-6秒に設定
⚠️ 短すぎる？ → 適切な返却前にリソース解放
ユーザーが完了ボタンをクリックしたが、タイムアウトが2秒で返却が3秒かかる場合：
- サーバーが返却リクエストが到着する前にリソースを解放
- → サーバーがリソース使用を減少させ、より多くのユーザーが進入するように許可 → 重複リソース占有 → 過度な進入
⚠️ 長すぎる？ → 放棄されたユーザーに対するリソース解放遅延
- ユーザーが実際にブラウザを閉じた、または接続が切断されたが、サーバーは10秒以上後にしか知ることができない
- → リソース解放遅延 → ボトルネック
💡 推奨事項: タイムアウトは最適パフォーマンスのために「正常返却フローよりもわずかに長く」する必要があります。
3段階: 必要な場合にのみ他の値を調整してからテスト
これらの設定は一般的にデフォルト値を維持できますが、必要に応じて調整できます：
- 再リクエスト周期: 待機列が過度に反応的である場合は減少、サーバー負荷が高い場合は増加
- Alive Notice 再リクエスト周期: 一般的にデフォルト値を維持。タイムアウト最小値よりも短くする必要がある
- Alive Notice 期間満了: 調整が必要 - まず実際のジャーニー時間を測定
- タイムアウト: 完了信号が欠落する場合は増加、リソースが長すぎる保持される場合は減少
重要事項:
- 調整後、実際のトラフィックでテストして予想動作を確認
- 安全のためにモニタリングメトリックに基づいて段階的に調整
構成チェックリスト
区間制御タイミングでデプロイする前に：
- 多段階区間を通じた平均ユーザージャーニー時間を測定
- Alive Notice 期間満了 = 平均時間 + 20-30秒に設定
- Alive Notice 再リクエスト周期 < タイムアウト最小値を確認
- タイムアウトシナリオをテスト（ブラウザを閉じる、ネットワーク接続切断）
- 早期リソース解放または停止したリソースをモニタリング