HTTPAPI | FineTune

TsgcWSServer_HTTPAPI exposes a published property named FineTune of type TsgcServerHTTPAPI_FineTune. It groups the low-level kernel-mode knobs that influence how the Windows HTTP Server API (http.sys) queues, dispatches and completes requests.

 

QueueLength

Wraps the HttpServerQueueLengthProperty kernel setting. It controls the maximum number of pending requests http.sys will hold in its kernel-mode queue before the server has dequeued them. When the queue is full, the kernel responds to new connections with 503 Service Unavailable directly, without ever reaching user mode.

 

Type: ULONG.

Default: 1000 (the Windows kernel default).

Range: up to 65535 requests.

What it improves: raising this value prevents the kernel from rejecting legitimate traffic on bursty workloads - IoT fleets reconnecting after a network blip, market-data broadcast clients reconnecting after a provider reset, or scheduled job workers that all connect on a shared cron tick.

 

SkipIOCPOnSuccess

When set to True, the server calls SetFileCompletionNotificationModes on the request queue handle with the flags FILE_SKIP_COMPLETION_PORT_ON_SUCCESS and FILE_SKIP_SET_EVENT_ON_HANDLE. Overlapped I/O operations on the request queue that complete synchronously no longer post an extra completion packet to the I/O completion port.

 

Type: Boolean.

Default: False (no flag is set, preserving current behavior).

What it improves: eliminates a kernel-to-user-mode hop on the hot request path when the call returns NO_ERROR synchronously - the worker dispatches the completion inline on the calling thread instead of waiting for an IOCP packet. This is the pattern used by Microsoft's reference HTTP Server High Performance sample. The flag is intended to be paired with OperatingMode = ompHighPerf.

 

The API is resolved at runtime via GetProcAddress from kernel32. On Windows XP and earlier (Delphi 7 runtime target) the entry point does not exist - the wrapper returns False and the server runs without the flag set.

 

OperatingMode

Selects one of two accept/dispatch architectures.

 

Type: TsgcHTTPAPIOperatingMode = (ompClassic, ompHighPerf).

Default: ompClassic.

 

 

What it improves: ompHighPerf pays off when the server sees either deep single-stream pipelines (large-frame uploads/downloads) or many concurrent clients (hundreds to thousands). The pre-posted receive window absorbs bursts without per-connection allocation, and the inline dispatch removes the acceptor hand-off bottleneck. Leave the default ompClassic for low-traffic APIs and development environments - on light workloads the overhead of maintaining 128 pre-posted contexts costs more than it saves. The mode can only be changed before the server is activated.

 

HighPerfAcceptsPerWorker

Controls how many async receives each IOCP worker pre-posts when OperatingMode = ompHighPerf. The value is ignored in ompClassic mode. The total number of concurrent outstanding receives the server maintains equals ThreadPoolSize x HighPerfAcceptsPerWorker.

 

Type: Integer.

Default: 4.

What it improves: a deeper per-worker window lets the server absorb larger bursts of incoming requests without allocating new contexts on the hot path. Raise it for high-concurrency deployments (IoT fleets, market-data distribution, fan-out brokers); the tradeoff is memory - each pre-posted receive holds a request buffer (~16 KB) reserved until it completes. The default 4 is a conservative middle ground validated against the MSDN HP sample.

 

Example

The following snippet configures an HTTP.sys server for a high-concurrency IoT backend: a large kernel queue to absorb reconnect storms, HighPerf dispatch with a widened pre-posted receive window, and inline-completion dispatch enabled.

 

 

For a typical internal or low-traffic API, leave every FineTune property at its default: