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

Ta opcja nie jest obsługiwana, a jej ustawienie nie ma żadnego efektu. Właściwość jest zachowana wyłącznie w celu zapewnienia zgodności, dzięki czemu istniejące formularze i kod, które jej używają, nadal się wczytują.

 

Typ: Boolean.

Domyślnie: False.

Dlaczego nie jest obsługiwana: nakładkowe operacje we/wy serwera opierają się na pakiecie uzupełnienia dla każdego wywołania, nawet gdy wywołanie kończy się powodzeniem od razu.

 

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ń oraz tryb dyspozycji HighPerf z rozszerzonym wstępnie wysłanym oknem odbioru.

 

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;
  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;