HTTPAPI | FineTune

TsgcWSServer_HTTPAPI는 TsgcServerHTTPAPI_FineTune 유형의 FineTune이라는 이름의 published 속성을 노출합니다. 이는 Windows HTTP Server API(http.sys)가 요청을 대기열에 넣고, 디스패치하고, 완료하는 방식에 영향을 미치는 저수준 커널 모드 설정을 그룹화합니다.

 

QueueLength

HttpServerQueueLengthProperty 커널 설정을 래핑합니다. 서버가 큐에서 빼기 전에 http.sys가 커널 모드 큐에 보유할 대기 중인 요청의 최대 수를 제어합니다. 큐가 가득 차면 커널은 사용자 모드에 도달하지 않고 새 연결에 503 Service Unavailable로 직접 응답합니다.

 

Type: ULONG.

기본값: 1000(Windows 커널 기본값).

Range: 최대 65535개의 요청까지입니다.

개선하는 점: 이 값을 높이면 버스트 워크로드에서 커널이 정당한 트래픽을 거부하는 것을 방지합니다. 네트워크 끊김 후 다시 연결되는 IoT 플릿, 공급자 재설정 후 다시 연결되는 시장 데이터 브로드캐스트 클라이언트, 또는 공유 cron 틱에서 모두 연결되는 예약된 작업 워커 등입니다.

 

SkipIOCPOnSuccess

True로 설정되면 서버는 FILE_SKIP_COMPLETION_PORT_ON_SUCCESS 및 FILE_SKIP_SET_EVENT_ON_HANDLE 플래그로 요청 큐 핸들에서 SetFileCompletionNotificationModes를 호출합니다. 동기적으로 완료되는 요청 큐의 중첩 I/O 작업은 더 이상 I/O 완료 포트에 추가 완료 패킷을 게시하지 않습니다.

 

Type: Boolean.

Default: False(플래그가 설정되지 않아 현재 동작이 유지됨).

개선되는 점: 호출이 동기적으로 NO_ERROR를 반환할 때 핫 요청 경로에서 커널-사용자 모드 홉을 제거합니다. 워커는 IOCP 패킷을 기다리는 대신 호출 스레드에서 인라인으로 완료를 디스패치합니다. 이것은 Microsoft의 참조 HTTP Server High Performance 샘플에서 사용되는 패턴입니다. 이 플래그는 OperatingMode = ompHighPerf와 함께 사용하도록 의도되었습니다.

 

API는 런타임에 kernel32의 GetProcAddress를 통해 확인됩니다. Windows XP 및 이전 버전(Delphi 7 런타임 대상)에서는 진입점이 존재하지 않으므로, 래퍼는 False를 반환하고 서버는 플래그가 설정되지 않은 채로 실행됩니다.

 

OperatingMode

두 가지 accept/dispatch 아키텍처 중 하나를 선택합니다.

 

Type: TsgcHTTPAPIOperatingMode = (ompClassic, ompHighPerf).

기본값: ompClassic.

 

• ompClassic - 단일 acceptor 스레드가 HttpReceiveHttpRequest를 동기적으로 호출하고 PostQueuedCompletionStatus를 통해 각 요청을 IOCP 워커 풀로 직접 디스패치합니다. 이것이 기존 동작입니다.
• ompHighPerf - Microsoft의 참조 HTTP Server High Performance 패턴을 구현합니다. acceptor 스레드가 제거됩니다. 시작 시 서버는 큐에 바인딩된 IOCP에 ThreadPoolSize x HighPerfAcceptsPerWorker개의 비동기 수신을 사전 게시합니다(기본값 32 x 4 = 128개의 동시 미해결 수신). 각 작업자는 완료를 인라인으로 처리하고 또 다른 비동기 수신을 다시 게시하여 종료될 때까지 슬라이딩 윈도우를 유지합니다.

 

개선 사항: ompHighPerf는 서버가 깊은 단일 스트림 파이프라인(대형 프레임 업로드/다운로드) 또는 많은 동시 클라이언트(수백에서 수천)를 처리할 때 효과를 발휘합니다. 사전 게시 수신 창은 연결당 할당 없이 버스트를 흡수하고, 인라인 디스패치는 acceptor 핸드오프 병목 현상을 제거합니다. 저트래픽 API와 개발 환경에서는 기본값 ompClassic을 유지하십시오 — 가벼운 워크로드에서는 128개의 사전 게시 컨텍스트를 유지하는 오버헤드가 절약되는 것보다 더 많은 비용이 듭니다. 모드는 서버가 활성화되기 전에만 변경할 수 있습니다.

 

HighPerfAcceptsPerWorker

OperatingMode = ompHighPerf일 때 각 IOCP 작업자가 미리 게시하는 비동기 수신 수를 제어합니다. 이 값은 ompClassic 모드에서 무시됩니다. 서버가 유지하는 동시 미해결 수신의 총 수는 ThreadPoolSize x HighPerfAcceptsPerWorker와 같습니다.

 

Type: Integer.

기본값: 4.

개선되는 점: 워커당 더 깊은 윈도우를 사용하면 서버가 핫 경로에서 새 컨텍스트를 할당하지 않고도 더 큰 수신 요청 버스트를 흡수할 수 있습니다. 고동시성 배포(IoT 플릿, 시장 데이터 배포, 팬아웃 브로커)에서는 이 값을 높이십시오. 트레이드오프는 메모리입니다. 사전 게시된 각 수신은 완료될 때까지 예약된 요청 버퍼(약 16 KB)를 보유합니다. 기본값 4는 MSDN HP 샘플에 대해 검증된 보수적인 중간값입니다.

 

예제

다음 스니펫은 고동시성 IoT 백엔드를 위한 HTTP.sys 서버를 구성합니다: 재연결 폭주를 흡수하기 위한 큰 커널 큐, 넓혀진 사전 게시 수신 창이 있는 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;