TsgcWSServer_HTTPAPI は TsgcServerHTTPAPI_FineTune 型の FineTune という名前の published プロパティを公開します。このプロパティは、Windows HTTP Server API (http.sys) がリクエストをキュー、ディスパッチ、完了する方法に影響するカーネルモードの低レベル設定をグループ化します。
HttpServerQueueLengthProperty カーネル設定をラップします。サーバーがデキューする前に http.sys がカーネルモードキューに保持する保留中のリクエストの最大数を制御します。キューがいっぱいになると、カーネルはユーザーモードに到達することなく、新しい接続に直接 503 Service Unavailable で応答します。
Type: ULONG。
Default: 1000（Windowsカーネルのデフォルト）。
Range: 最大 65535 リクエスト。
改善される点: この値を大きくすると、バースト性のあるワークロードでカーネルが正当なトラフィックを拒否するのを防ぐことができます。ネットワーク障害後に再接続する IoT フリート、プロバイダーのリセット後に再接続するマーケットデータブロードキャストクライアント、あるいは共有のcronティックで一斉に接続するスケジュールジョブワーカーなどに有効です。
Trueに設定すると、サーバーはリクエストキューハンドルに対して、フラグFILE_SKIP_COMPLETION_PORT_ON_SUCCESSとFILE_SKIP_SET_EVENT_ON_HANDLEを指定してSetFileCompletionNotificationModesを呼び出します。同期的に完了するリクエストキュー上のオーバーラップI/O操作は、I/O完了ポートに追加の完了パケットを投稿しなくなります。
Type: Boolean。
デフォルト: False（フラグが設定されておらず、現在の動作が維持されます）。
改善される点： 呼び出しが NO_ERROR を同期的に返す場合、ホットリクエストパスでのカーネルからユーザーモードへのホップを排除します。ワーカーは IOCP パケットを待たずに、呼び出し元スレッドで完了をインラインでディスパッチします。これは Microsoft のリファレンス HTTP サーバー高パフォーマンスサンプルで使用されているパターンです。このフラグは OperatingMode = ompHighPerf と組み合わせて使用することを目的としています。
API は kernel32 から GetProcAddress を通じて実行時に解決されます。Windows XP 以前（Delphi 7 ランタイムターゲット）ではエントリポイントが存在しないため、ラッパーは False を返し、サーバーはフラグを設定せずに実行されます。
2つのaccept/dispatchアーキテクチャのいずれかを選択します。
Type: TsgcHTTPAPIOperatingMode = (ompClassic, ompHighPerf)。
デフォルト値： ompClassic。
HttpReceiveHttpRequest を同期的に呼び出し、PostQueuedCompletionStatus を介して各リクエストを IOCP ワーカープールに手動でディスパッチします。これは従来の動作です。ThreadPoolSize x HighPerfAcceptsPerWorker の非同期受信を事前にポストします (デフォルト 32 x 4 = 128 の同時未処理受信)。各ワーカーはインラインで完了を処理し、別の非同期受信を再ポストして、シャットダウンまでスライディングウィンドウを維持します。
改善される点： ompHighPerf は、サーバーが深いシングルストリームパイプライン（大きなフレームのアップロード/ダウンロード）または多数の同時クライアント（数百から数千）を処理する場合に効果を発揮します。事前ポスト受信ウィンドウは接続ごとのアロケーションなしにバーストを吸収し、インラインディスパッチはアクセプターのハンドオフボトルネックを除去します。低トラフィック API や開発環境にはデフォルトの ompClassic を使用してください。軽負荷ではトラフィックの少ないワークロードで 128 の事前ポストコンテキストを維持するオーバーヘッドは節約より大きくなります。このモードはサーバーが有効化される前にのみ変更できます。
OperatingMode = ompHighPerf の場合に各IOCPワーカーが事前にポストする非同期受信数を制御します。ompClassic モードでは値は無視されます。サーバーが維持する同時未処理受信の合計数は ThreadPoolSize x HighPerfAcceptsPerWorker です。
Type: 整数。
デフォルト: 4。
改善される点： ワーカーごとのウィンドウを深く設定することで、サーバーはホットパスで新しいコンテキストを割り当てることなく、大量の着信リクエストのバーストを吸収できます。高並列デプロイメント（IoT フリート、市場データ配信、ファンアウトブローカー）では値を大きくしてください。トレードオフはメモリです。事前にポストされた各受信には、完了するまで予約されるリクエストバッファ（約 16 KB）が保持されます。デフォルトの 4 は MSDN HP サンプルに基づいて検証された保守的な中間値です。
以下のスニペットは、高並行性 IoT バックエンド向けに HTTP.sys サーバーを設定しています。再接続ストームを吸収するための大きなカーネルキュー、拡張された事前ポスト受信ウィンドウを持つ HighPerf ディスパッチ、およびインライン補完ディスパッチが有効になっています。
uses
sgcWebSocket_Server_HTTPAPI,
sgcWebSocket_HTTPAPI_Server; // TsgcHTTPAPIOperatingMode
var
oServer: TsgcWSServer_HTTPAPI;
begin
oServer := TsgcWSServer_HTTPAPI.Create(nil);
oServer.Host := '0.0.0.0';
oServer.Port := 8080;
// absorb 10,000-device reconnect bursts before kernel-level 503
oServer.FineTune.QueueLength := 10000;
// switch from single-acceptor to pre-posted IOCP workers
oServer.FineTune.OperatingMode := ompHighPerf;
// widen the per-worker pre-posted receive window (32 threads * 8 = 256)
oServer.FineTune.HighPerfAcceptsPerWorker := 8;
// dispatch inline on sync-success completions; skip the IOCP round-trip
oServer.FineTune.SkipIOCPOnSuccess := True;
oServer.Active := True;
end;
典型的な内部または低トラフィック API の場合、すべての FineTune プロパティをデフォルトのままにします:
oServer := TsgcWSServer_HTTPAPI.Create(nil);
oServer.Host := 'localhost';
oServer.Port := 8080;
// FineTune defaults: QueueLength=1000, SkipIOCPOnSuccess=False,
// OperatingMode=ompClassic, HighPerfAcceptsPerWorker=4
oServer.Active := True;