sgcWebSockets 2026.5.0 から、TsgcWSServer_HTTPAPI コンポーネントに新しい published プロパティ FineTune（型は TsgcServerHTTPAPI_FineTune）が公開されました。Windows HTTP Server API（http.sys）がリクエストをキューイング、ディスパッチ、完了する動作に影響するすべての低レベルカーネルモードの設定をグループ化しています。これまでこれらの設定はコンポーネント上に存在しないか、ハードコードされていましたが、今後は公開され、フォームとともに永続化され、デザイン時に調整可能となります。
FineTune プロパティは TPersistent のコンテナで、QueueLength、SkipIOCPOnSuccess、OperatingMode、HighPerfAcceptsPerWorker の 4 つのサブプロパティを持ちます。いずれも既存の動作を維持する値がデフォルトとなっているため、2026.5.0 へのアップグレードにコード変更は一切不要です。特定のワークロードで必要に応じて、個別に各調整を適用できます。
FineTune プロパティ
QueueLength : ULONG（デフォルト 1000）
機能。 HttpServerQueueLengthProperty カーネル設定をラップします。サーバーがデキューする前に、http.sys がカーネルモードキューに保持する保留中のリクエスト数を制御します。キューが満杯になると、カーネルはユーザーモードに到達することなく、新規接続に 503 Service Unavailable を直接返します。
改善ポイント。 バースト的なワークロード（ネットワークの瞬断後に再接続する数千の IoT デバイス、フリート展開、市場開始時のトラフィックスパイクなど）では、QueueLength を上げることで、プロセスがクライアントを認識する前にカーネルがクライアントを拒否することを防ぎ、クライアントの連鎖的なリトライを回避します。デフォルトの 1000 は Windows カーネルのデフォルトと一致し、最新のワークロードでは控えめな値です。有効範囲は最大 65535 です。
SkipIOCPOnSuccess : Boolean（デフォルト False）
機能。 True に設定すると、SetFileCompletionNotificationModes を介してリクエストキューハンドルに FILE_SKIP_COMPLETION_PORT_ON_SUCCESS および FILE_SKIP_SET_EVENT_ON_HANDLE フラグを有効化します。これにより、オーバーラップド I/O 操作が同期的に完了したときに、カーネルは IOCP への完了パケットの送信をスキップします。
改善ポイント。 呼び出しが同期的に NO_ERROR を返した場合、ホットなリクエストパスでのカーネルからユーザーモードへのホップを排除します。ワーカーは IOCP パケットを待つ代わりに、呼び出し元スレッド上でインラインに完了をディスパッチします。これは Microsoft のリファレンス「HTTP Server High Performance」サンプルが使用するパターンです。デフォルトの False は意図的なものです。フラグを有効にするには呼び出し側でインライン完了の処理が必要となります。このプロパティは、スループットの向上が追加のコードパスを正当化できるワークロードで OperatingMode = ompHighPerf と組み合わせて使用することを想定しています。
OperatingMode : TsgcHTTPAPIOperatingMode（デフォルト ompClassic）
機能。 2 つの accept/dispatch アーキテクチャのいずれかを選択します。
ompClassic— 単一の acceptor スレッドがHttpReceiveHttpRequestを同期的に呼び出し、PostQueuedCompletionStatusを介して各リクエストを IOCP ワーカープールに手動でディスパッチします。これは従来の動作です。ompHighPerf— Microsoft のリファレンス「HTTP Server High Performance」パターンを実装します。acceptor スレッドは完全に削除されます。起動時にサーバーはキューにバインドされた IOCP 上にThreadPoolSize × HighPerfAcceptsPerWorker個の非同期 receive を事前投入します（デフォルト 32 × 4 = 128 個の同時アウトスタンディング receive）。各ワーカーは完了をインラインで処理し、別の非同期 receive を再投入することで、シャットダウンまでスライディングウィンドウを維持します。
改善ポイント。 ompHighPerf は、サーバーが深い単一ストリームのパイプライン（大きなフレームのアップロード／ダウンロード）または多数の同時クライアント（数百〜数千）を扱う場合に効果を発揮します。事前投入された receive ウィンドウは接続ごとの割り当てなしにバーストを吸収し、インラインディスパッチが acceptor のハンドオフのボトルネックを排除します。低トラフィックの API や開発環境ではデフォルトの ompClassic のままにしてください。軽量なワークロードでは、128 個の事前投入コンテキストを維持するオーバーヘッドが節約以上のコストとなります。モードは構築時のみ変更可能で、単一プロセスのライフタイム内でのモードの混在はサポートされません。
HighPerfAcceptsPerWorker : Integer（デフォルト 4）
機能。 OperatingMode = ompHighPerf のときに各 IOCP ワーカーが事前投入する非同期 receive の数を制御します。ompClassic モードでは値は無視されます。サーバーが維持する同時アウトスタンディング receive の総数は ThreadPoolSize × HighPerfAcceptsPerWorker に等しくなります。
改善ポイント。 ワーカーごとのウィンドウを深くすることで、サーバーはホットパス上で新しいコンテキストを割り当てずに、より大きな着信リクエストのバーストを吸収できます。高同時実行デプロイメント（IoT フリート、マーケットデータ配信、ファンアウトブローカーなど）では値を上げてください。トレードオフはメモリで、事前投入された各 receive は完了するまで予約されたリクエストバッファ（約 16 KB）を保持します。デフォルトの 4 は MSDN「HP」サンプルに対して検証された控えめな中間値です。
使用例
以下のスニペットでは、高同時実行の IoT バックエンド向けに HTTP.sys サーバーを設定します。再接続の嵐を吸収するための大きなカーネルキュー、事前投入 receive ウィンドウを広げた 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;