Υψηλής Απόδοσης REST διακομιστής σε Delphi: Όρια αιτήσεων, Thread-Pool και καθαρή συμπεριφορά σε υπερφόρτωση (Απόσπασμα πηγαίου κώδικα)

Γιατί το «Υψηλής Απόδοσης» σε REST στο Delphi συχνά αποτυγχάνει λόγω παράλληλης εκτέλεσης

Ένας διακομιστής REST υψηλής απόδοσης Delphi σπανίως περιορίζεται στην πράξη από τον απλό χρόνο CPU ανά αίτημα, αλλά από ανεξέλεγκτη παράλληλη εκτέλεση: υπερβολικά πολλά ταυτόχρονα requests, υπερβολικά πολλά ταυτόχρονα ερωτήματα στη βάση δεδομένων ή αποκλειστικό/blocking I/O (αρχείο, δίκτυο, βάση δεδομένων). Το αποτέλεσμα δεν μοιάζει με «λίγο πιο αργό», αλλά με αλυσιδωτή αντίδραση: περισσότερα νήματα (Threads), μεγαλύτερες ουρές, κατάρρευση του connection-pool, αυξανόμενες καθυστερήσεις (latencies), timeouts στην πλευρά του client και στο τέλος ένας διακομιστής που, παρότι «ζει», δεν παρέχει πλέον σταθερές απαντήσεις.

Η αντίμετρο δεν είναι ένα μεμονωμένο κόλπο, αλλά μια συνειδητή συμπεριφορά υπερφόρτωσης: Όταν ο διακομιστής φτάνει στα όριά του, πρέπει να απορρίπτει νωρίς και ντετερμινιστικά (τυπικά HTTP 429 ή 503), αντί να αφήνει τα requests να στοιβάζονται σε μια ατελείωτη ουρά. Ακριβώς γι‘ αυτόν τον σκοπό είναι αυτό το απόσπασμα πηγαίου κώδικα: ένα ελαφρύ Concurrency-Gate (Semaphore) συν Timeouts, που μπορεί να ενσωματωθεί σε υπάρχοντες REST endpoints — ανεξαρτήτως εάν χρησιμοποιείτε Indy, WebBroker, Horse ή μια δική σας HTTP-στρώση.

Ιδέα αρχιτεκτονικής: Concurrency-Gate πριν από το «ακριβό μέρος»

Η βασική ιδέα είναι απλή: Πριν από το ακριβό μέρος (πρόσβαση στη βάση δεδομένων, σύνθετες αναφορές, μεγάλες απαντήσεις JSON) δεσμεύεται ένα token από μια Semaphore. Αν δεν υπάρχει διαθέσιμο token, επιστρέφεται άμεσα μια ελεγχόμενη απάντηση. Σημαντικό: Αυτό το gate πρέπει να απελευθερώνεται αξιόπιστα (try/finally), και πρέπει να βρίσκεται στην διαδρομή του κώδικα που είναι πραγματικά δαπανηρή — όχι απλώς στην αρχή του Request-Handlers, όταν ακολουθούν ακόμα parser/router/αυθεντικοποίηση.

Με αυτόν τον τρόπο το φορτίο δεν «εξαφανίζεται», αλλά καναλιζάρεται: Ο διακομιστής απαντά σε λιγότερα requests ταυτόχρονα, με αντάλλαγμα σταθερότερες καθυστερήσεις. Σε εξατομικευμένες επιχειρησιακές εφαρμογές αυτό είναι κατά κανόνα πιο πολύτιμο από στιγμιαία ρεκόρ σε συνθετικά benchmarks.

Απόσπασμα πηγαίου κώδικα: Request-Limiter με Timeout, 429/503 και Telemetrie-Hooks

Ο παρακάτω Delphi-κώδικας υλοποιεί ένα Concurrency-Gate ως κλάση TRestRequestGate. Βασίζεται σε TSemaphore (από System.SyncObjs; μια Semaphore είναι ένας μετρητής για περιορισμένες ταυτόχρονες προσβάσεις). Η κλήση του Gate επιστρέφει είτε ένα αντικείμενο «Lease» (παρόμοιο με RAII: απελευθέρωση στο Destructor) είτε επιλέγει άμεση απάντηση υπερφόρτωσης. Επιπλέον υπάρχουν hooks για logging/monitoring, ώστε να βλέπετε στη λειτουργία γιατί αιτήματα απορρίφθηκαν.

unit RESTRequestGate;

interface

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

type
  // Ελάχιστο πλαίσιο για καταγραφή/ιχνηλάτηση; μπορεί π.χ. να επεκταθεί με πληροφορίες χρήστη/διαδρομής.
  TRESTGateContext = record
    RequestId: string;
    Route: string;
    RemoteIp: string;
  end;

  TRESTOverloadDecision = (odAccepted, odRejectedBusy, odRejectedTimeout);

  // Hook για τηλεμετρία λειτουργίας (π.χ. σε αρχείο, Syslog, Prometheus-Exporter κ.λπ.)
  TRESTGateEvent = reference to procedure(const Ctx: TRESTGateContext;
                                         Decision: TRESTOverloadDecision;
                                         WaitedMs: Integer;
                                         InFlight: Integer);

  // Lease-αντικείμενο: απελευθέρωση του token στο Destructor.
  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: κανένας χρόνος αναμονής, άμεσα 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;

  // Πρώτα μείωση του μετρητή, στη συνέχεια απελευθέρωση της semaphore.
  TInterlocked.Decrement(FInFlightCounter^);
  FSemaphore.Release;
end;

{ TRESTRequestGate }

constructor TRESTRequestGate.Create(AMaxInFlight: Integer);
begin
  inherited Create;
  if AMaxInFlight <= 0 then
    raise EArgumentException.Create('AMaxInFlight πρέπει να είναι > 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 όταν TimeoutMs > 0: στοχευμένη αναμονή, αλλά με όριο.
        Decision := odRejectedTimeout;
        Result := False;
        if Assigned(FOnEvent) then
          FOnEvent(Ctx, Decision, WaitedMs, InFlight);
      end;
  else
    begin
      // wrAbandoned/περιπτώσεις σφάλματος: απορρίπτεται συντηρητικά
      Decision := odRejectedBusy;
      Result := False;
      if Assigned(FOnEvent) then
        FOnEvent(Ctx, Decision, WaitedMs, InFlight);
    end;
  end;
end;

end.

Σκοπός: Σταθερότητα υπό φόρτο αντί για «όλα ταυτόχρονα»

Με MaxInFlight ορίζετε πόσα Requests μπορούν ταυτόχρονα να εισέλθουν στο «ακριβό μέρος». Αυτό σκόπιμα δεν είναι η «Αnzahl CPU-Kerne», αλλά μια λειτουργική παράμετρος. Σε βάσει δεδομένων απαιτητικά Endpoints έχει συχνά νόημα να θέσετε το MaxInFlight σε σχέση με το DB-Connection-Pool (για παράδειγμα Pool = 20, MaxInFlight = 12 έως 16), ώστε να μην μπλοκάρει κάθε Request μια σύνδεση και στη συνέχεια να δημιουργούνται επιπλέον Threads.

Προϋποθέσεις και παγίδες

• Try/Finally ist Pflicht: Το Lease πρέπει να απελευθερωθεί εγγυημένα. Αν έχετε Exceptions στο Endpoint, διαφορετικά το Gate «διαρρέει» και ο server παραμένει μόνιμα σε «busy».
• Timeout sinnvoll wählen: TimeoutMs=0 είναι ένα σκληρό όριο (απορρίπτεται αμέσως). Ένα σύντομο timeout (τυπικά 50 έως 150 ms) εξομαλύνει τις κορυφώσεις χωρίς να σχηματίζει πραγματικές ουρές.
• Gate nicht zu früh: Ο έλεγχος ταυτότητας (π.χ. Bearer/JWT) ή το routing μπορεί να είναι χρήσιμο· το semaphore πρέπει να ενεργοποιείται πριν από το πραγματικά ακριβό τμήμα. Αντίστροφα: αν το auth είναι ακριβό (π.χ. έναντι ενός εξωτερικού identity-system), αυτό επίσης πρέπει να περιοριστεί.
• 429 vs 503: Το HTTP 429 («Too Many Requests») ταιριάζει όταν οι Clients πρέπει να κάνουν στοχευμένο retry. Το 503 («Service Unavailable») ταιριάζει όταν η υπηρεσία προσωρινά δεν είναι γενικά σε θέση να δεχτεί αιτήσεις με νόημα. Σε κάθε περίπτωση συνιστάται ένα header Retry-After.

Ενσωμάτωση σε REST-Handler: Indy/WebBroker/Horse πρακτικά

Το snippet είναι σκόπιμα framework-neutral. Χρειάζεστε μόνο ένα σημείο όπου τα Requests «διατρέχονται». Τυπικά είναι ένα globales Singleton ή ένα Gate ανά ομάδα routes (για παράδειγμα «/reports» μικρότερο, «/health» χωρίς Gate). Ενδεικτικά η ενσωμάτωση ως υπόδειγμα:

• Συμπλήρωση context (RequestId, Route, RemoteIp)
• TryAcquire με σύντομο timeout
• Σε απόρριψη να γραφεί αμέσως η Response (429/503) και τερματισμός
• Το Lease ζει στο scope μέχρι μετά το ακριβό τμήμα

Σε Horse (Middleware) το Gate βρίσκεται κοντά σε μια ομάδα routes. Σε WebBroker μπορείτε να εργαστείτε μέσα στον αντίστοιχο Action-Handler. Στο Indy εξαρτάται αν έχετε ένα Thread ανά Request· το Gate εξακολουθεί να έχει αποτέλεσμα εφόσον τα ακριβά τμήματα οριοθετούνται καθαρά.

Υψηλής απόδοσης REST Server Delphi: Απαντήσεις υπερφόρτωσης που δεν «μολύνουν» τους Clients

Οι απαντήσεις υπερφόρτωσης είναι κάτι παραπάνω από κωδικοί κατάστασης. Αν οι Clients σε 429/503 στέλνουν επιθετικά και αμέσως ξανά, δημιουργείται ένα κύμα επαναπροσπαθειών. Σε ετερογενή τοπιογραφία συστημάτων (Mobile Apps, C# Services, Legacy-Clients) βοηθά μια συνεπής συμπεριφορά:

• Retry-After: για παράδειγμα 1 έως 3 δευτερόλεπτα, ανάλογα με το Endpoint. Αυτό είναι ένας σαφής ρυθμιστής ρυθμού.
• Σύντομο σώμα: Ένα μικρό JSON όπως {"error":"server_busy","requestId":"..."} αρκεί. Μεγάλα Error-Objects ξοδεύουν ξανά CPU και εύρος ζώνης.
• Health-Endpoint ungedrosselt: Το monitoring πρέπει να παρέχει πληροφορίες ακόμα και υπό φόρτο (ενδεχομένως με flag «degraded»).

Αν έχετε έναν reverse proxy όπως nginx μπροστά: ρυθμίστε τα timeouts και το buffering εκεί. Ένας proxy μπορεί να ανακουφίσει (TLS-Termination, Keep-Alive), αλλά και να μεταθέσει το φορτίο (π.χ. να αποθηκεύει προσωρινά μεγάλα request-bodies). Στην παραγωγή μετράει ότι τα όρια είναι συνεπή: Proxy-Timeout > App-Timeout, αλλιώς οι Clients βλέπουν «Gateway Timeout», παρότι η εφαρμογή θα είχε απορρίψει σωστά.

Threading, DB-Pools und Keep-Alive: Wo es in der Praxis kippt

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-Ablosung mit nativer Anbindung-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- und Linux-Services 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 (αδρή ανάλυση αιτιών, χωρίς παραβίαση της προστασίας δεδομένων)

Έτσι λαμβάνετε ένα σήμα αν τα όρια είναι πολύ αυστηρά (πολλά 429) ή πολύ ελαστικά (υψηλά WaitedMs, αυξανόμενες καθυστερήσεις). Και βλέπετε αν μεμονωμένες ρουτίνες κυριαρχούν. Για Windows- και Linux-Services αυτό είναι κρίσιμο στην καθημερινή λειτουργία: Χωρίς τηλεμετρία ένα πρόβλημα απόδοσης γρήγορα γίνεται εικασία μεταξύ δικτύου, βάσης δεδομένων, Proxy και εφαρμογής.

Ασυνήθιστο, αλλά εξαιρετικά χρήσιμο: «WaitedMs» ως δείκτης πρώιμης προειδοποίησης

Πολλές ομάδες κοιτούν μόνο τον χρόνο απόκρισης (Response-Time) και την CPU. WaitedMs είναι συχνά ο καλύτερος δείκτης, επειδή δείχνει ότι τα αιτήματα ήδη περιμένουν πριν από την ουσιαστική εργασία. Αν το WaitedMs αυξάνεται ενώ η CPU παραμένει μέτρια, ο περιορισμένος πόρος συχνά δεν είναι η CPU αλλά ένας pool (DB-συνδέσεις), ένα lock στην επιχειρησιακή λογική ή ένας εξωτερικός Downstream-Service. Αυτό εξοικονομεί χρόνο στην ανάλυση των αιτιών, γιατί αναζητάτε πιο στοχευμένα προς «Pool/Lock/I/O» αντί για «Compiler-Optimierung».

Παραλλαγές: Gate ανά Route, Προτεραιότητες και «Fast Lane»

Ένα Gate για τα πάντα είναι απλό, αλλά όχι πάντα ιδανικό. Σημερινές, πρακτικές παραλλαγές:

• Gate ανά ομάδα Route: «/reports» αυστηρό, «/api/orders» μέτριο, «/health» ανοικτό. Έτσι αποτρέπετε να εκτοπίζονται οι κεντρικές διεργασίες από δαπανηρά Report-Requests.
• Fast Lane για Admin/Monitoring: Διαχωρισμένο Gate με περιορισμένη παραλληλότητα, ώστε οι λειτουργικές ενέργειες να είναι δυνατές ακόμη και υπό φορτίο.
• Όρια βάσει προϋπολογισμού: Εάν τα μεγέθη αποκρίσεων ποικίλλουν σημαντικά, ένα επιπλέον Byte-Budget μπορεί να βοηθήσει (π.χ. το πολύ X MB ταυτόχρονα στη δημιουργία). Αυτό είναι πιο πολύπλοκο, αλλά ρεαλιστικό σε περιπτώσεις μεγάλων downloads.

Σημαντικό: Η προτεραιοποίηση γρήγορα γίνεται πολιτική («το Endpoint μου είναι πιο σημαντικό»). Τεχνικά σταθερό παραμένει το σύστημα όταν οι προτεραιότητες συνδέονται με διεργασίες (π.χ. καταχώρηση παραγγελίας πριν από reporting), όχι με ρόλους ή τμήματα.

Συμπέρασμα: Αξίζει το Gate — και πού καταρρέει η προσέγγιση;

Ένα Concurrency-Gate είναι ένα πρακτικό δομικό στοιχείο για έναν High Performance REST Server σε Delphi, γιατί κάνει τον Overload χειρίσιμο και διατηρεί τα συστήματά σας σταθερά κατά την κορύφωση του φορτίου. Αξίζει ιδιαίτερα όταν έχετε endpoints που εξαρτώνται από βάση δεδομένων, όταν μπροστά υπάρχει ένας Reverse Proxy ή όταν πολλοί clients (Legacy, Portale, Services) προκαλούν φορτίο σε κύματα.

Τα όρια είναι σαφή: Αν η ίδια η εργασία ανά αίτημα είναι υπερβολικά ακριβή (μη αποδοτικές ερωτήσεις, μεγάλα JSON-αντικείμενα, μπλοκάροντα εξωτερικά συστήματα), το Gate απλώς κρύβει τα συμπτώματα. Τότε πρέπει να βελτιωθούν η πρόσβαση στα δεδομένα, οι caching-στρατηγικές, τα timeouts και ενδεχομένως η ασύγχρονη επεξεργασία (Queue/Job-System). Ως ζώνη ασφαλείας στη λειτουργία, όμως, το Gate συχνά κάνει τη διαφορά μεταξύ «λίγο προβληματικό» και «πλήρως μη χρησιμοποιήσιμο».

Εάν θέλετε να εισαγάγετε συμπεριφορά Overload σε έναν υπάρχοντα Delphi REST-API und REST-Server ή να ισορροπήσετε όρια με timeouts βάσης δεδομένων και Proxy με τρόπο συνεπή, συζητήστε το έργο ή το σχέδιο εκσυγχρονισμού με Net-Base.

Στο τεχνικό πλαίσιο παίζουν επίσης ρόλο ο Thread-Pool Delphi και το Http 429 Too Many Requests, όταν οι ενσωματώσεις, οι ροές δεδομένων και η περαιτέρω ανάπτυξη πρέπει να συνεργάζονται αρμονικά.

Συζητήστε έργο ή σχέδιο εκσυγχρονισμού με Net-Base.