Kõrge jõudlusega REST server Delphi: päringupiirangud, lõimepuhver ja korrektne ülekoormuse käitumine (koodinäide)

Miks „suurjõudlusega“ REST puhul Delphi-s sageli paralleelsus läbi kukub

Üks suurjõudlusega REST Server Delphi on praktikas harva piiratud pelgalt ühe päringu CPU-ajaga, pigem piirab see kontrollimatu paralleelsus: liiga palju samaaegseid päringuid, liiga palju samaaegseid andmebaasi päringuid või blokeeriv I/O (fail, võrk, andmebaas). Tulemuseks ei ole „veidi aeglasem“, vaid ahelreaktsioon: rohkem niite, pikemad järjekorrad, Connection-Pooli kollaps, kasvavad latentsid, kliendipoolsed timeoutid ja lõpuks server, mis küll „elab“, kuid ei anna enam stabiilseid vastuseid.

Vastumürk ei ole üksik nipp, vaid teadlik ülekoormuse käitumine: kui server jõuab oma piirini, peab ta varakult ja deterministlikult päringud tagasi lükkama (tüüpiliselt HTTP 429 või 503), selle asemel et lasta päringutel lõputusse järjekorda kuhjuda. Selleks on mõeldud järgmine koodilõik: kergekaaluline Concurrency-Gate (semafor) koos timeoutidega, mida saab integreerida olemasolevatesse REST-endpunktidesse – sõltumata sellest, kas kasutate Indy, WebBroker, Horse või oma HTTP-kihti.

Arhitektuuriline idee: Concurrency-Gate enne ressursimahukat osa

Põhiidee on lihtne: enne ressursimahukat osa (andmebaasi ligipääs, keerukad raportid, suured JSON-vastused) reserveeritakse token semaforist. Kui tokenit pole vaba, antakse kohe kontrollitud vastus. Oluline on: see lukk peab usaldusväärselt vabastama (try/finally), ja see peab olema paigutatud sellesse koodirada, mis tõepoolest on kallis — mitte ainult päringu käsitleja algusesse, kus sellele järgneb veel parser/router/autentimine.

Selle lähenemisega ei „optimeerita“ koormust ära, vaid suunatakse see: server vastab korraga vähematele päringutele, kuid stabiilsemate latentsitega. Kohandatud ärirakendustes on see enamasti väärtuslikum kui juhuslikud parimad ajad sünteetilistes benchmarkides.

Koodilõik: päringupiiraja timeouti, 429/503 ja telemeetria-hookidega

Järgnevas Delphi-koodis on Concurrency-Gate implementeeritud klassina TRestRequestGate. See põhineb TSemaphore-l (pärineb System.SyncObjs-st; semafor on loendur piiratud samaaegsete ligipääsude jaoks). Gate-kutse tagastab kas „lease“-objekti (RAII-laadne: vabastus destruktori sees) või otsustab kohe ülekoormuse vastuse kasuks. Lisaks on olemas hookid logimiseks/monitooringuks, et töös oleks nähtav, miks päringud tagasi lükati.

unit RESTRequestGate;

interface

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

type
  // Minimaalne kontekst logimiseks/tracing'uks; vajadusel saab lisada näiteks kasutaja või Route.
  TRESTGateContext = record
    RequestId: string;
    Route: string;
    RemoteIp: string;
  end;

  TRESTOverloadDecision = (odAccepted, odRejectedBusy, odRejectedTimeout);

  // Hook operatsioonitelemeetria jaoks (nt faili, syslogi, Prometheus-eksporteri vms)
  TRESTGateEvent = reference to procedure(const Ctx: TRESTGateContext;
                                         Decision: TRESTOverloadDecision;
                                         WaitedMs: Integer;
                                         InFlight: Integer);

  // Lease-objekt: token vabastatakse destruktoris.
  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;

    // TimeoutMs = 0: ooteaeg puudub — vastus kohe 429/503
    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;

  // Esiteks loendur alla, seejärel semafori vabastus.
  TInterlocked.Decrement(FInFlightCounter^);
  FSemaphore.Release;
end;

{ TRESTRequestGate }

constructor TRESTRequestGate.Create(AMaxInFlight: Integer);
begin
  inherited Create;
  if AMaxInFlight <= 0 then
    raise EArgumentException.Create('AMaxInFlight peab olema > 0');

  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
        // wrTimeout juhul, kui TimeoutMs > 0: oodati sihipäraselt, kuid ajaliselt piiratud.
        Decision := odRejectedTimeout;
        Result := False;
        if Assigned(FOnEvent) then
          FOnEvent(Ctx, Decision, WaitedMs, InFlight);
      end;
  else
    begin
      // wrAbandoned/veaolukorrad: konservatiivselt tagasilükata
      Decision := odRejectedBusy;
      Result := False;
      if Assigned(FOnEvent) then
        FOnEvent(Ctx, Decision, WaitedMs, InFlight);
    end;
  end;
end;

end.

Eesmärk: stabiilsus koormuse all, mitte „kõik korraga“

Koos MaxInFlight määrate, mitu päringut tohib samal ajal „kuluka osa“ juurde pääseda. See on teadlikult mitte „CPU-tuumade arv“, vaid opereerimisparameeter. Andmebaasikoormusega endpointide puhul on sageli mõistlik seada MaxInFlight seoses DB-ühenduste basseiniga (näiteks Pool = 20, MaxInFlight = 12 kuni 16), et mitte iga päring ei blokeeriks ühendust ja järgnevates lõimedes ei tekiks järjekorda.

Piirtingimused ja komistuskivid

• Try/Finally on kohustuslik: Lease tuleb garanteeritult vabastada. Kui endpointis tekivad erandid, muutub lüüs „lekitavaks“ ja server jääb püsivalt olekusse „busy“.
• Valige mõistlik Timeout: TimeoutMs=0 on kõva piir (otse tagasi lükata). Lühike timeout (tüüpiliselt 50–150 ms) silub tippe, ilma et tekiks päris järjekordi.
• Lüüs mitte liiga vara: Autentimine (nt Bearer/JWT) või reitimine võib olla sobiv koht; semafor peaks tabama enne tõeliselt kulukat sektsiooni. Vastupidisel juhul — kui autentimine muutub kalliks (nt välise identiteedisüsteemi vastu) — tuleb ka seda piirata.
• 429 vs 503: HTTP 429 („Too Many Requests“) sobib, kui kliendid peaksid sihipäraselt retryima. 503 („Service Unavailable“) sobib, kui teenus ajutiselt üldse ei suuda päringuid mõistlikult vastu võtta. Mõlema puhul on soovitatav lisada Retry-After-header.

Integreerimine REST-handlerisse: Indy/WebBroker/Horse pragmaatiliselt

Koodinäide on teadlikult raamistikuneutraalne. Teil on vaja vaid üht kohta, kus päringud „läbivad“. Tüüpiline on globaalne singleton või lüüs iga route-rühma kohta (näiteks „/reports“ väiksem, „/health“ ilma lüüsita). Näidispõhine sidumine võib välja näha nii:

• Kontekst täita (RequestId, Route, RemoteIp)
• TryAcquire lühikese timeoutiga
• Tagasilükkamisel kohe vastus kirjutada (429/503) ja lõpetada
• Lease kehtib scope’i sees kuni ressursimahuka osa lõpuni

Horse (middleware) puhul asub lüüs tavaliselt lähedal route-rühmale. WebBrokeris töötate vastava action-handleri sees. Indy puhul sõltub see sellest, kas teil on iga päringu jaoks eraldi thread; lüüs toimib ikkagi, kui kulukad sektsioonid on selgelt piiratud.

High Performance REST Server Delphi: ülekoormuse vastused, mis kliente ei „mürgita“

Ülekoormuse vastused on rohkem kui staatusekoodid. Kui kliendid 429/503 korral agressiivselt kohe uuesti saadavad, tekib retry-torm. Heterogeenses süsteemimaastikus (Mobile Apps, C# Services, legacy-kliendid) aitab järjepidev käitumine:

• Retry-After: näiteks 1–3 sekundit, sõltuvalt endpointist. See annab selge takti.
• Lühike body: Väike JSON nagu {"error":"server_busy","requestId":"..."} piisab. Suured error-objektid kulutavad taas CPU-d ja ribalaiust.
• Health-endpoint ilma piiranguta: Monitooring peab ka koormuse all andma infot (vajadusel „degraded“-flag).

Kui käitabite rakenduse ees reverse-proxy’t nagu nginx, seadke seal timeoutid ja puhverdus vastavusse. Proxy võib koormust vähendada (TLS-terminatsioon, Keep-Alive), kuid võib ka koormust edasi lükata (nt suurte request-bodyde pufferimine). Töös on oluline piiride järjepidevus: Proxy-Timeout > App-Timeout; vastasel juhul näevad kliendid „Gateway Timeout“, kuigi rakendus oleks päringu korrektselt tagasi lükanud.

Lõimimine, DB-poolid ja Keep-Alive: kus praktikas läheb nihu

Das Gate löst das „zu viele gleichzeitig“-Problem, aber es verhindert nicht automatisch, dass ein einzelner Request übermäßig viele Ressourcen bindet. Drei typische Kipp-Punkte aus Delphi-Projekten entstehen genau an den Schnittstellen zwischen Threading, Datenbank und HTTP-Verbindungen:

• Ein Request blockiert mehrere knappe Ressourcen: Erst eine DB-Verbindung, dann ein externer HTTP-Call, dann ein Dateizugriff. Wenn das alles im selben Request-Thread passiert, multipliziert sich die Blockadezeit. Das Gate begrenzt dann zwar die Parallelität, aber die Durchsatzleistung sinkt drastisch. Hier lohnt es sich, die Abhängigkeiten zu entkoppeln (z.B. externe Calls asynchron, Vorberechnung per Job-Queue).
• BDE-asendamine koos natiivse liidestusega — Pooling und Transaktionen: BDE-Ablosung mit nativer Anbindung kann Connections poolen, aber eine „lange“ Transaktion (z.B. weil JSON-Erstellung oder Business-Checks zwischen StartTransaction und Commit liegen) hält die Verbindung unnötig. Eine saubere Praxis ist, die Transaktion so eng wie möglich um die eigentlichen Statements zu legen und außerhalb der Transaktion zu serialisieren oder zu validieren, wenn es fachlich geht.
• HTTP Keep-Alive als versteckter Speicherfresser: Keep-Alive reduziert Handshakes, kann aber bei vielen Leerlauf-Clients zu vielen offenen Sockets führen. Gerade bei Windows- ja Linux-teenused sieht man dann nicht „CPU hoch“, sondern „Handles/FDs voll“ oder RAM durch Puffer. Hier helfen klare Idle-Timeouts im Server und am Reverse Proxy sowie ein Limit pro Client-IP, wenn es die Umgebung erlaubt.

Die Konsequenz: MaxInFlight ist kein statischer Wert. Er hängt von Ihrer langsamsten, knappsten Ressource ab (DB, externe Systeme, Storage) und davon, wie gut ein Request diese Ressourcen „zusammenhält“.

Performance-Hebel neben dem Gate: JSON, DB und I/O nicht vermischen

Das Gate stabilisiert, aber es ersetzt keine saubere Endpoint-Ökonomie. Drei Bremsen in Delphi REST-Servern tauchen wiederholt auf:

• JSON-Building mit unnötigen Zwischenstrings: Häufig entsteht Last durch viele temporäre Unicode-Strings. Wo möglich, streaming-orientiert bauen (Writer/Stream) statt riesige Zwischenobjekte, besonders bei Listen-Endpunkten.
• Datenbankzugriff „pro Item“: N+1-Queries und per-Row Lookups sind der Klassiker. Besser: gezielte Joins, Batch-Queries, serverseitige Aggregation. Bei sehr großen Ergebnissen lohnt sich zusätzlich Pagination mit stabiler Sortierung (damit Seiten nicht „springen“).
• Blockierende I/O im Request-Thread: Dateizugriffe oder externe HTTP-Calls sollten entweder strikt begrenzt oder in eine asynchrone Pipeline verlagert werden. Sonst blockieren Sie teure Threads für „Warten“.

Für gewachsene digitale Unternehmenslösungen ist das oft der Knackpunkt: Ein Endpoint wurde „mal schnell“ ergänzt und funktioniert, bis reale Last und Datenvolumina kommen. Dann zeigt sich, ob Architekturgrenzen sauber gezogen wurden (Datenzugriffsschicht, Caching, Bulk-Strategien, klare Timeouts).

Debugging und Betrieb: Was Sie messen sollten

Der Hook OnEvent ist bewusst simpel. In der Praxis sollten Sie mindestens folgende Werte erfassen:

• InFlight (aktuelle Parallelität am Gate)
• WaitedMs (wie viel „Queueing“ Sie zulassen)
• Decision (accepted/busy/timeout)
• Route/RemoteIp (ligikaudne põhjuseanalüüs, ilma andmekaitset eiramata)

Sellega saate signaali, kas piirangud on liiga ranged (liiga palju 429) või liiga leebed (suured WaitedMs, kasvav latentsus). Ja näete, kas üksikud rajad domineerivad. Für Windows- und Linux-teenused on see igapäevatöös otsustava tähtsusega: ilma telemeetriata muutub jõudlusprobleem kiiresti arvestamiseks võrgu, andmebaasi, proksi ja rakenduse vahel.

Ebatavaline, kuid äärmiselt kasulik: „WaitedMs“ varajase hoiatusindikaatorina

Paljud meeskonnad vaatavad ainult response-time‘i ja CPU-d. WaitedMs on sageli parem indikaator, sest see näitab, et päringud ootavad juba enne tegelikku töötlemist. Kui WaitedMs kasvab, samal ajal kui CPU jääb mõõdukaks, ei ole napp ressurss tavaliselt CPU, vaid mingi puhver (DB-ühendused), lukustus äriloogikas või väline allavoolu-teenus. See säästab aega põhjuseotsingul, sest suunate uurimise sihipärasemalt „pool/lock/I/O“ suunas, mitte „kompilaatori optimeerimise“ suunas.

Variantid: väravad iga raja jaoks, prioriteedid ja „Fast Lane“

Üks värav kõigi jaoks on lihtne, kuid mitte alati ideaalne. Mõistlikud variandid:

• Värav iga rada/rühma kohta: „/reports“ range, „/api/orders“ mõõdukas, „/health“ avatud. Nii väldite, et kallid aruandepäringud tõrjuksid põhiprotsesse.
• Fast Lane administraatoritele/monitooringule: eraldi värav väikse paralleelsusega, et haldustoimingud oleksid ka koormuse all võimalikud.
• Eelarvepõhised piirangud: kui vastuse suurused suurtes piirides varieeruvad, aitab lisaks baitide eelarve (nt maksimaalselt X MB korraga genereerimisel). See on keerukam, kuid suurte allalaadimiste puhul reaalsem.

Tähtis: prioriseerimine muutub kiiresti poliitiliseks („minu endpoint on tähtsam“). Tehniliselt jääb lahendus stabiilseks, kui prioriteedid on seotud protsessidega (nt tellimuse registreerimine enne aruandlust), mitte rollide või osakondadega.

Kokkuvõte: kas värav tasub end ära — ja kus see lähenemine läbi kukub?

Samaaegsuse värav on pragmaatiline komponent kõrge jõudlusega REST serveri jaoks Delphi-s, sest see muudab ülekoormuse kontrollitavaks ja hoiab teie süsteeme tippkoormuse ajal stabiilsena. See tasub end eriti ära, kui teil on andmebaasipõhised endpointid, ees on reverse proxy või kui mitu klienti (Legacy, portaalid, teenused) tekitavad koormuse lainetena.

Piirid on selged: kui päringu tegelik töö on liiga kallis (ebatõhusad päringud, suured JSON-objektid, blokeerivad välissüsteemid), peidab värav vaid sümptomeid. Siis tuleb parandada andmejuurdepääsu, vahemälustrateegiaid, timeoute ja vajadusel asünkroonset töötlemist (queue/job-süsteem). Operatiivses kasutuses on värav tihti turvarihm, mis eristab „veidi aeglast“ ja „täielikult kasutamiskõlbmatut“.

Kui soovite ülekoormuskäitumise viia olemasolevasse Delphi REST-API und REST-Server sisse või kui soovite piiranguid andmebaasi- ja proksi-timeoutidega täpselt tasakaalustada: arutage projekti või moderniseerimisettevõtmist koos Net-Base.

Ametikontekstis mängivad tähtsat rolli ka thread-pool Delphi ja Http 429 Too Many Requests, kui integratsioonid, andmevood ja edasiarendus peavad sujuvalt koos töötama.

Arutage projekti või moderniseerimisettevõtmist koos Net-Base-ga.