Strojenie wysokiej wydajności HTTP.SYS

· Funkcje

Począwszy od sgcWebSockets 2026.5.0 komponent TsgcWSServer_HTTPAPI udostępnia nową opublikowaną właściwość FineTune typu TsgcServerHTTPAPI_FineTune. Grupuje ona wszystkie niskopoziomowe pokrętła trybu jądra, które wpływają na sposób, w jaki Windows HTTP Server API (http.sys) kolejkuje, wysyła i kończy żądania. Do tej pory te pokrętła albo nie istniały na komponencie, albo były zakodowane na sztywno — teraz są opublikowane, zachowywane wraz z formularzem i regulowane w czasie projektowania.

Właściwość FineTune to kontener TPersistent z czterema podwłaściwościami: QueueLength, SkipIOCPOnSuccess, OperatingMode oraz HighPerfAcceptsPerWorker. Każda domyślnie przyjmuje wartość zachowującą istniejące zachowanie, więc aktualizacja do 2026.5.0 nie wymaga żadnych zmian w kodzie; każdą modyfikację włączasz indywidualnie, gdy wymaga tego konkretne obciążenie.

Właściwości FineTune

QueueLength : ULONG (domyślnie 1000)

Co robi. Opakowuje ustawienie jądra HttpServerQueueLengthProperty. Kontroluje, ile oczekujących żądań http.sys przechowuje w swojej kolejce trybu jądra, zanim serwer je zdejmie. Gdy kolejka jest pełna, jądro odpowiada na nowe połączenia bezpośrednio kodem 503 Service Unavailable, nie docierając do trybu użytkownika.

Co poprawia. Przy obciążeniach burst — tysiące urządzeń IoT ponownie łączących się po przerwie sieciowej, wdrożenia floty, skoki ruchu na otwarciu rynku — zwiększenie QueueLength zapobiega odrzucaniu klientów przez jądro, zanim twój proces je zobaczy, unikając kaskadowych ponowień klientów. Domyślne 1000 odpowiada domyślnej wartości jądra Windows i jest zachowawcze dla nowoczesnych obciążeń; prawidłowy zakres sięga do 65535.

SkipIOCPOnSuccess : Boolean (domyślnie False)

Co robi. Po ustawieniu na True włącza flagi FILE_SKIP_COMPLETION_PORT_ON_SUCCESS oraz FILE_SKIP_SET_EVENT_ON_HANDLE na uchwycie kolejki żądań przez SetFileCompletionNotificationModes. Jądro pomija wtedy wysłanie pakietu zakończenia do IOCP, gdy nakładana operacja I/O kończy się synchronicznie.

Co poprawia. Eliminuje przeskok między jądrem a trybem użytkownika na gorącej ścieżce żądania, gdy wywołanie zwraca synchronicznie NO_ERROR — worker wysyła zakończenie w linii w wątku wywołującym, zamiast czekać na pakiet IOCP. To wzorzec używany w referencyjnym przykładzie Microsoftu „HTTP Server High Performance". Domyślne False jest celowe: włączenie tej flagi wymaga obsługi inline-completion po stronie wywołującego. Właściwość ma być sparowana z OperatingMode = ompHighPerf w obciążeniach, gdzie wzrost przepustowości uzasadnia dodatkową ścieżkę kodu.

OperatingMode : TsgcHTTPAPIOperatingMode (domyślnie ompClassic)

Co robi. Wybiera jedną z dwóch architektur akceptacji/wysyłania:

Co poprawia. ompHighPerf opłaca się, gdy serwer widzi albo głębokie potoki pojedynczego strumienia (uploady/pobrania dużych ramek), albo wielu równoczesnych klientów (od setek do tysięcy). Wstępnie opublikowane okno odbioru absorbuje skoki bez alokacji per-połączenie, a wysyłka w linii usuwa wąskie gardło przekazania od akceptora. Pozostaw domyślne ompClassic dla API o niskim ruchu i środowisk deweloperskich — przy lekkim obciążeniu koszt utrzymywania 128 wstępnie opublikowanych kontekstów przewyższa oszczędności. Tryb można zmienić wyłącznie w czasie konstrukcji; mieszanie trybów w obrębie pojedynczego cyklu życia procesu nie jest obsługiwane.

HighPerfAcceptsPerWorker : Integer (domyślnie 4)

Co robi. Kontroluje, ile asynchronicznych odbiorów każdy worker IOCP wstępnie publikuje, gdy OperatingMode = ompHighPerf. Wartość jest ignorowana w trybie ompClassic. Łączna liczba współbieżnych aktywnych odbiorów utrzymywanych przez serwer to ThreadPoolSize × HighPerfAcceptsPerWorker.

Co 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. Zwiększ je dla wdrożeń o wysokiej współbieżności (floty IoT, dystrybucja danych rynkowych, brokery fan-out); kompromisem jest pamięć — każdy wstępnie opublikowany odbiór trzyma zarezerwowany bufor żądania (~16 KB) aż do zakończenia. Domyślne 4 to zachowawczy środek zweryfikowany względem przykładu MSDN „HP".

Przykład użycia

Poniższy fragment konfiguruje serwer HTTP.sys dla backendu IoT o wysokiej współbieżności: duża kolejka jądra absorbująca burze ponownych połączeń, wysyłka HighPerf z poszerzonym wstępnie opublikowanym oknem odbioru oraz włączona wysyłka 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;
  // absorbuj skoki ponownych połączeń 10 000 urządzeń przed 503 na poziomie jądra
  oServer.FineTune.QueueLength := 10000;
  // przełącz z pojedynczego akceptora na wstępnie opublikowanych workerów IOCP
  oServer.FineTune.OperatingMode := ompHighPerf;
  // poszerz okno wstępnie opublikowanego odbioru per worker (32 wątki * 8 = 256)
  oServer.FineTune.HighPerfAcceptsPerWorker := 8;
  // wysyłaj inline przy synchronicznych zakończeniach z sukcesem; pomijaj round-trip IOCP
  oServer.FineTune.SkipIOCPOnSuccess := True;
  oServer.Active := True;
end;

Dla typowego wewnętrznego API lub API o niskim ruchu pozostaw każdą właściwość FineTune na domyślnej wartości:

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