High Performance REST Server in Delphi: Concurrency-Gate, 429/503 und sauberes Overload-Verhalten (Source-Schnipsel)

„Unser REST-Endpunkt ist doch schnell – warum wird der Service morgens trotzdem unbenutzbar?“ Diese Frage taucht in gewachsenen Delphi-Landschaften regelmäßig auf. Im Profiling wirkt alles okay: JSON ist flott, die SQL-Query ist nicht dramatisch, CPU ist im Normalbetrieb niedrig. Und doch kippt der Dienst in einem realen Lastmuster: Latenzen steigen, danach folgen Timeouts, schließlich ein Domino aus Retries, DB-Pool-Stau und hängenden Worker-Threads. Ein High Performance REST Server Delphi entsteht deshalb selten durch Mikro-Optimierung, sondern durch kontrollierte Parallelität und ein definiertes Overload-Verhalten.

Konstruierte, aber praxisnahe Situation: Ein internes Portal feuert morgens um 08:00 Uhr nach Schichtstart 300 gleichzeitige Requests auf /api/orders/open. Parallel läuft ein Reporting-Endpoint, der eine große Aggregation erstellt. Der Reverse Proxy (z. B. nginx) hält Keep-Alive-Verbindungen, der Server nimmt alles an, BDE-Ablösung mit nativer Anbindung versucht Connections zu ziehen. Das System ist nicht „down“ (Port offen), aber faktisch nicht mehr steuerbar: Requests warten in unsichtbaren Queues (DB-Connection-Pool, Locks, TCP), Clients retryen, und der Dienst wird durch seine eigene Überlast „zermahlen“.

Der Ansatz in diesem Source-Schnipsel: ein bewusstes Concurrency-Gate (Semaphore = Zähler für begrenzte Parallelität) direkt vor dem teuren Abschnitt. Wenn kein Slot frei ist, wird früh, konsistent und billig abgewiesen (429 oder 503), inklusive Retry-After. Das ist nicht „mehr Performance“ im Benchmark-Sinn, sondern berechenbare Latenz, kontrollierter Durchsatz und ein Server, der unter Last nicht kollabiert.

Szenarioanalyse: Wo REST-Server in Delphi unter Last wirklich kippen

In individuellen Unternehmenssoftware-Landschaften trifft ein REST-Server selten auf „saubere“, gleichmäßige Last. Stattdessen dominieren Peaks und Abhängigkeiten. Drei Kanten sind in Delphi-Projekten besonders typisch:

• Threading ohne Budget: Je nach Stack (WebBroker/Indy/Horse/HTTP.sys) ist das Default-Verhalten oft „mehr gleichzeitige Requests = mehr Threads/Tasks“. Das skaliert nur bis zu einem Punkt; danach steigen Kontextwechsel, Lock-Contention und Heap-Pressure schneller als der Durchsatz.
• DB-Pool als Engpass: Der Engpass ist nicht die CPU, sondern die begrenzte Zahl gleichzeitiger Datenbankverbindungen und die Zeit, die Transaktionen offen bleiben. Wenn 100 Requests jeweils „nur kurz“ eine Connection brauchen, aber in Summe länger halten, reicht ein kleiner Peak, um alles zu blockieren.
• Retry-Stürme: Gateways, Cronjobs oder Clients retryen aggressiv. Ohne definierte 429/503-Strategie und Retry-After kommt zusätzliche Last genau in der Phase, in der der Dienst am wenigsten verträgt.

HTTP 429 ist als Standardstatus für Überlast ausdrücklich definiert (RFC 6585: rfc6585). Auch Retry-After ist klar spezifiziert (RFC 9110: rfc9110). Das ist wichtig für Betrieb und Client-Implementierungen: Sie bauen nicht „irgendein Verhalten“, sondern nutzen etablierte Semantik, die auch Proxies und Libraries verstehen.

High Performance REST Server Delphi: Concurrency-Gate vor dem „teuren Teil“

Ein Gate ist dann wirksam, wenn es dort sitzt, wo knappe Ressourcen gebunden werden: DB-Zugriff, externe HTTP-Calls, Report-Generierung, große JSON-Serialisierung oder kryptografisch teure Schritte. Es sollte nicht pauschal alles blockieren, sondern gezielt den Kostenpunkt begrenzen.

Source-Schnipsel: Gate mit Timeout, Ereignis-Hook und sicherer Freigabe

Der Code ist framework-neutral (WebBroker, Horse, Indy oder eigene HTTP-Schicht). Er nutzt TSemaphore aus System.SyncObjs und liefert ein Lease-Objekt (RAII-ähnlich), das im Destructor freigibt. Das ist absichtlich „unspektakulär“: im Betrieb zählt deterministische Freigabe, messbare Wartezeit, klare Entscheidung.

unit RestRequestGate;

interface

uses
  System.SysUtils,
  System.SyncObjs,
  System.Diagnostics;

type
  TRestGateContext = record
    RequestId: string;
    Route: string;
    RemoteIp: string;
  end;

  TRestOverloadDecision = (odAccepted, odRejectedBusy, odRejectedTimeout);

  TRestGateEvent = reference to procedure(const Ctx: TRestGateContext;
                                         Decision: TRestOverloadDecision;
                                         WaitedMs: Integer;
                                         InFlight: Integer);

  TRestGateLease = class
  private
    FSemaphore: TSemaphore;
    FInFlightCounter: PInteger;
    FReleased: Boolean;
  public
    constructor Create(ASem: TSemaphore; ACounter: PInteger);
    destructor Destroy; override;
    procedure Release;
  end;

  TRestRequestGate = class
  private
    FSem: TSemaphore;
    FMaxInFlight: Integer;
    FInFlight: Integer;
    FOnEvent: TRestGateEvent;
  public
    constructor Create(AMaxInFlight: Integer);
    destructor Destroy; override;

    function TryAcquire(const Ctx: TRestGateContext; TimeoutMs: Cardinal;
                        out Lease: TRestGateLease;
                        out WaitedMs: Integer;
                        out Decision: TRestOverloadDecision): Boolean;

    property OnEvent: TRestGateEvent read FOnEvent write FOnEvent;
    property MaxInFlight: Integer read FMaxInFlight;
    function InFlight: Integer;
  end;

implementation

uses
  System.Math;

{ TRestGateLease }

constructor TRestGateLease.Create(ASem: TSemaphore; ACounter: PInteger);
begin
  inherited Create;
  FSemaphore := ASem;
  FInFlightCounter := ACounter;
  FReleased := False;
end;

destructor TRestGateLease.Destroy;
begin
  Release;
  inherited;
end;

procedure TRestGateLease.Release;
begin
  if FReleased then
    Exit;
  FReleased := True;

  TInterlocked.Decrement(FInFlightCounter^);
  FSemaphore.Release;
end;

{ TRestRequestGate }

constructor TRestRequestGate.Create(AMaxInFlight: Integer);
begin
  inherited Create;
  if AMaxInFlight <= 0 then
    raise EArgumentException.Create('AMaxInFlight muss > 0 sein');

  FMaxInFlight := AMaxInFlight;
  FInFlight := 0;

  // InitialCount = MaxCount = AMaxInFlight
  FSem := TSemaphore.Create(nil, AMaxInFlight, AMaxInFlight, '');
end;

destructor TRestRequestGate.Destroy;
begin
  FSem.Free;
  inherited;
end;

function TRestRequestGate.InFlight: Integer;
begin
  Result := TInterlocked.CompareExchange(FInFlight, 0, 0);
end;

function TRestRequestGate.TryAcquire(const Ctx: TRestGateContext; TimeoutMs: Cardinal;
  out Lease: TRestGateLease; out WaitedMs: Integer; out Decision: TRestOverloadDecision): Boolean;
var
  Sw: TStopwatch;
  WaitRes: TWaitResult;
  CurrentInFlight: Integer;
begin
  Lease := nil;
  WaitedMs := 0;
  Decision := odRejectedBusy;

  Sw := TStopwatch.StartNew;
  if TimeoutMs = 0 then
    WaitRes := FSem.WaitFor(0)
  else
    WaitRes := FSem.WaitFor(TimeoutMs);

  WaitedMs := Integer(Min(Sw.ElapsedMilliseconds, High(Integer)));

  case WaitRes of
    wrSignaled:
      begin
        CurrentInFlight := TInterlocked.Increment(FInFlight);
        Lease := TRestGateLease.Create(FSem, @FInFlight);
        Decision := odAccepted;
        Result := True;

        if Assigned(FOnEvent) then
          FOnEvent(Ctx, Decision, WaitedMs, CurrentInFlight);
      end;

    wrTimeout:
      begin
        Decision := odRejectedTimeout;
        Result := False;
        if Assigned(FOnEvent) then
          FOnEvent(Ctx, Decision, WaitedMs, InFlight);
      end;
  else
    begin
      Decision := odRejectedBusy;
      Result := False;
      if Assigned(FOnEvent) then
        FOnEvent(Ctx, Decision, WaitedMs, InFlight);
    end;
  end;
end;

end.

Zweck: Begrenzung der gleichzeitig laufenden „teuren“ Requests. Dadurch vermeiden Sie, dass Lastspitzen den Dienst in lange Warteschlangen treiben, die am Ende nur Timeouts produzieren.

Randbedingungen: Das Gate muss in dem Pfad liegen, der die knappe Ressource bindet. Ein Gate „ganz vorn“ ist oft zu grob. Für teure Authentifizierung oder Rate-Limits pro Clientklasse kann ein zweites Gate sinnvoll sein.

Stolperfallen: Gate-Leaks sind fatal. Darum gibt TRestGateLease im Destructor frei. Trotzdem: Lease nicht in globale Strukturen hängen, keine zyklischen Referenzen, und bei Exceptions sicherstellen, dass das Lease-Objekt den Scope wirklich verlässt.

Integration: 429/503, Retry-After, und warum „kurzes Warten“ oft besser ist als gar nicht warten

Die Integration in einen Handler läuft bewusst in vier Schritten:

1. Context füllen (RequestId/Route/RemoteIp).
2. TryAcquire mit kurzem Timeout (z. B. 50–150 ms) aufrufen.
3. Bei Ablehnung sofort Response schreiben: 429 oder 503, plus Retry-After.
4. Lease bis nach dem teuren Teil im Scope halten.

Das kleine Timeout ist kein „Warteschlangenbau“, sondern Peak-Glättung: Sie geben Requests eine Chance, einen Slot zu bekommen, ohne das System mit langen Blockierungen zu fluten. Ein Gate mit TimeoutMs=0 ist dafür die härtere Variante: maximal deterministisch, aber potenziell mit mehr Ablehnungen bei jitternder Last.

Randfall aus dem Betrieb: Keep-Alive, langsame Clients und „hängende“ Slots

Ein Gate schützt InFlight-Arbeit – nicht automatisch den Datenabfluss. Wenn Clients langsam lesen (z. B. Mobilfunk/VPN oder ein Reverse Proxy mit kleinem Buffer), kann ein Request zwar fachlich fertig sein, aber der Response-Write blockiert. In diesem Moment ist der Slot faktisch weiter belegt: Ihre Worker hängen am Socket, nicht an der DB. Das wirkt dann wie „Gate ist zu klein“, ist aber ein I/O-Problem.

Konsequenzen, die sich in Delphi-Stacks (je nach HTTP-Implementierung) bewährt haben:

• Response-Timeouts explizit setzen (Write/Send), nicht nur Read-Timeouts.
• Große Payloads streamen (Chunked/Streaming), aber mit Backpressure im Blick: Streaming kann die Slot-Belegung verlängern.
• Große Exporte aus dem REST-Request entkoppeln (Job + Download-URL), wenn sie regelmäßig „lange Sockets“ verursachen.

Ungewöhnlich, aber wirkungsvoll: „Fast Lane“ für kurze Routen statt ein globales Gate

Ein häufiger Randfall in gewachsenen REST-APIs: Sie haben sehr unterschiedliche Kosten pro Route. /api/health ist billig, /api/report/monthly ist teuer, /api/orders/open liegt irgendwo dazwischen. Ein globales Gate behandelt alles gleich und kann die falschen Dinge schützen.

Eine saubere Variante ist eine zweistufige Begrenzung:

• Globales Gate für „alles Teure“ (z. B. DB-gebundene Arbeit).
• Zusatz-Gate pro Route oder Route-Gruppe für einzelne Problemkinder (Reports, Exporte, Imports), damit diese nicht alle Slots blockieren.

Das ist kein akademischer Luxus: In Betriebssituationen verhindert es, dass ein einzelner „Monster-Endpoint“ den Rest der Business-Software aus dem Tritt bringt. Gerade bei Legacy-Clients, die nicht schnell angepasst werden können, ist diese Priorisierung oft der Unterschied zwischen „Peak ist unangenehm“ und „Peak ist ein Incident“.

Was Sie neben dem Gate abstimmen müssen (sonst arbeitet es gegen Sie)

Zusätzliche Stellschraube: getrennte Budgets für DB und Downstream

Ein häufiger Architekturkniff in Integrationslandschaften: Ein Endpoint macht erst DB-Lookup, dann einen Downstream-HTTP-Call (z. B. an ein Drittsystem) und schreibt anschließend zurück. Wenn Sie alles unter einem Gate begrenzen, kann die falsche Ressource gewinnen: Der Downstream hängt, aber blockiert DB-Slots – oder umgekehrt.

Praktischer Ansatz: zwei Gates mit unterschiedlichen MaxInFlight-Werten, jeweils so platziert, dass sie nur die jeweilige knappe Ressource schützen. Das ist besonders dann sinnvoll, wenn der Downstream über längere Zeit degradieren kann (z. B. sporadische 2–10 Sekunden), Sie aber die lokale DB weiterhin für andere Routen brauchbar halten wollen.

Debugging-Kniff: WaitedMs ist der bessere Frühindikator als CPU

Der Event-Hook liefert WaitedMs (Wartezeit am Gate). Das ist operativ stark: Steigt WaitedMs, während CPU und RAM noch „okay“ aussehen, ist die knappe Ressource fast immer ein Pool oder ein Lock (DB, kritische Sektionen, Downstream-Latenz, Filesystem). Damit werden Diskussionen über „Delphi ist zu langsam“ schnell konkret: Das Problem ist nicht die Sprache, sondern die Warteschlange.

Zusätzlicher Praxiswert: Loggen Sie das Gate-Event nicht für jeden Request (das kann wieder kosten), sondern als Aggregation (z. B. pro Route und Minute: accepted/rejected/avg waited). Für tiefe Debug-Sessions schalten Sie Sampling oder einen Burst-Modus zu (z. B. 1% aller Requests mit voller Detailtiefe und RequestId).

Eine redaktionelle Einschätzung: 429/503 sind kein „Fehler“, sondern eine Zusage

In prozessnahen Softwarelösungen ist ein kontrolliertes „Nein“ besser als ein zufälliges „Vielleicht“. 429/503 sind kein Makel, sondern ein Vertrag an den Client: „Ich bin überlastet, aber ich sage es dir früh und konsistent.“ Der Nutzen ist betrieblich: Sie machen Lastspitzen sichtbar und steuerbar, statt sie in Timeouts und Zombie-Threads zu verstecken.

Grenzen und Risiken: Wo der Ansatz kippt

• Symptombehandlung bei teuren Requests: Wenn ein einzelner Request 5 Sekunden extern blockiert, begrenzt das Gate nur den Schaden. Für echte Entlastung brauchen Sie Entkopplung (Job-Queue), Caching oder geänderte Schnittstellen (z. B. asynchrones Polling).
• Falsches Gating verhungert wichtige Routen: Darum sind pro Route-Gates oder eine „Fast Lane“ für Monitoring/Admin sinnvoll.
• Client-Verhalten entscheidet mit: Ohne Backoff/Jitter kann 429 einen Retry-Sturm auslösen. Retry-After hilft, ersetzt aber keine saubere Client-Policy.
• Observability ist Pflicht: Ohne Metriken (accepted/rejected, WaitedMs, InFlight) drehen Sie an Zahlen, ohne zu wissen, ob das System stabiler wurde.

Fazit: Wann sich ein Concurrency-Gate im Delphi REST-Server lohnt

Ein Concurrency-Gate ist ein pragmatischer Baustein für einen High Performance REST Server Delphi, wenn Sie Lastspitzen, DB-Pool-Engpässe oder instabile Latenzen sehen. Der Code ist klein genug, um ihn in Legacy-Services einzuziehen, aber wirksam genug, um Kaskaden zu verhindern. Die realistische Erwartung: Sie gewinnen Stabilität und Vorhersagbarkeit, nicht automatisch „mehr Requests pro Sekunde“.

Wenn Sie das Gate in eine bestehende Delphi REST-API integrieren, Proxy- und App-Timeouts konsistent machen oder Routen priorisieren möchten, lässt sich das meist in einer kurzen technischen Bestandsaufnahme sauber klären.

Für dieses Thema sind auch Thread-Pool Delphi und Http 429 Too Many Requests wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.

Projekt oder Modernisierungsvorhaben mit Net-Base besprechen.