HTTPAPI | FineTune

TsgcWSServer_HTTPAPI udostępnia opublikowaną właściwość FineTune typu TsgcServerHTTPAPI_FineTune. Grupuje niskopoziomowe przełączniki trybu jądra wpływające na sposób, w jaki Windows HTTP Server API (http.sys) kolejkuje, wysyła i uzupełnia żądania.

QueueLength

Opakowuje ustawienie jądra HttpServerQueueLengthProperty. Kontroluje maksymalną liczbę oczekujących żądań, które http.sys przechowuje w kolejce trybu jądra, zanim serwer je odczyta. Gdy kolejka jest pełna, jądro odpowiada na nowe połączenia kodem 503 Service Unavailable bezpośrednio, bez sięgania do trybu użytkownika.

Typ: ULONG.

Domyślnie: 1000 (wartość domyślna jądra Windows).

Zakres: do 65535 żądań.

Co to poprawia: zwiększenie tej wartości zapobiega odrzucaniu przez jądro systemu legalnego ruchu przy skokami obciążeń — dotyczy to przykładowo flot IoT nawiązujących ponowne połączenia po zaniku sieci, klientów rozgłaszania danych rynkowych po resecie dostawcy lub harmonogramowanych pracowników zadań, którzy wszyscy łączą się przy wspólnym ticku crona.

SkipIOCPOnSuccess

Gdy wartość jest ustawiona na True, serwer wywołuje SetFileCompletionNotificationModes na uchwycie kolejki żądań z flagami FILE_SKIP_COMPLETION_PORT_ON_SUCCESS i FILE_SKIP_SET_EVENT_ON_HANDLE. Nakładkowe operacje we/wy na kolejce żądań, które kończą się synchronicznie, nie publikują już dodatkowego pakietu uzupełnienia do portu uzupełnienia we/wy.

Typ: Boolean.

Domyślnie: False (żadna flaga nie jest ustawiona, co zachowuje bieżące zachowanie).

Co poprawia: eliminuje przełączenie z trybu jądra do trybu użytkownika na krytycznej ścieżce żądania, gdy wywołanie synchronicznie zwraca NO_ERROR — worker przetwarza zakończenie bezpośrednio na wątku wywołującym, zamiast oczekiwać na pakiet IOCP. Jest to wzorzec stosowany w referencyjnej próbce Microsoft HTTP Server High Performance. Flaga jest przeznaczona do użycia łącznie z OperatingMode = ompHighPerf.

API jest rozwiązywane w czasie wykonywania za pomocą GetProcAddress z kernel32. W systemie Windows XP i wcześniejszych (cel wykonawczy Delphi 7) punkt wejścia nie istnieje — opakowanie zwraca False, a serwer działa bez ustawionej flagi.

OperatingMode

Wybiera jedną z dwóch architektur akceptacji i wysyłki.

Type: TsgcHTTPAPIOperatingMode = (ompClassic, ompHighPerf).

Domyślnie: ompClassic.

• ompClassic — pojedynczy wątek akceptujący wywołuje HttpReceiveHttpRequest synchronicznie i ręcznie przekazuje każde żądanie do puli wątków roboczych IOCP za pomocą PostQueuedCompletionStatus. Jest to historyczne zachowanie.
• ompHighPerf — implementuje wzorzec wysokiej wydajności serwera HTTP firmy Microsoft. Wątek akceptujący jest usunięty. Podczas uruchamiania serwer z wyprzedzeniem wystawia ThreadPoolSize x HighPerfAcceptsPerWorker asynchronicznych odbiorów w kolejce IOCP (domyślnie 32 x 4 = 128 jednoczesnych oczekujących odbiorów). Każdy wątek roboczy obsługuje ukończenie operacji i wystawia kolejny asynchroniczny odbiór, utrzymując przesuwne okno do momentu zamknięcia serwera.

Co poprawia: Tryb ompHighPerf opłaca się, gdy serwer obsługuje głębokie potoki dla pojedynczego strumienia (duże przesyłanie/pobieranie ramek) lub wielu równoczesnych klientów (setki do tysięcy). Wstępnie zarejestrowane okno odbierania pochłania skoki ruchu bez alokacji na połączenie, a wbudowane rozsyłanie eliminuje wąskie gardło przekazywania przez akceptor. Dla lekkich API i środowisk programistycznych należy pozostawić domyślny tryb ompClassic: przy małym obciążeniu koszty utrzymania 128 wstępnie zarejestrowanych kontekstów przewyższają korzyści. Tryb można zmienić tylko przed aktywacją serwera.

HighPerfAcceptsPerWorker

Określa, ile asynchronicznych odbiorów każdy wątek roboczy IOCP wstępnie rejestruje, gdy OperatingMode = ompHighPerf. Wartość jest ignorowana w trybie ompClassic. Łączna liczba jednoczesnych oczekujących odbiorów utrzymywana przez serwer jest równa ThreadPoolSize x HighPerfAcceptsPerWorker.

Type: Integer.

Domyślnie: 4.

Co to poprawia: głębsze okno per-worker pozwala serwerowi absorbować większe skoki przychodzących żądań bez alokowania nowych kontekstów na gorącej ścieżce. Należy je zwiększyć w przypadku wdrożeń o wysokiej współbieżności (floty IoT, dystrybucja danych rynkowych, brokery fan-out); kompromisem jest pamięć — każde wstępnie wystawione odbieranie przechowuje bufor żądań (~16 KB) zarezerwowany do momentu jego zakończenia. Domyślna wartość 4 to konserwatywny punkt środkowy zwalidowany względem przykładu MSDN HP.

Przykład

Poniższy fragment konfiguruje serwer HTTP.sys dla backendu IoT o wysokiej współbieżności: duża kolejka jądra do absorbowania burz ponownych połączeń, tryb dyspozycji HighPerf z rozszerzonym wstępnie wysłanym oknem odbioru oraz włączone zakończenie inline-completion.

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;

W przypadku typowego wewnętrznego API lub API o małym ruchu należy pozostawić wszystkie właściwości FineTune przy wartościach domyślnych:

oServer := TsgcWSServer_HTTPAPI.Create(nil);
oServer.Host := 'localhost';
oServer.Port := 8080;
// FineTune defaults: QueueLength=1000, SkipIOCPOnSuccess=False,
//                    OperatingMode=ompClassic, HighPerfAcceptsPerWorker=4
oServer.Active := True;