Skip to main content

Checkout-Latenz mit drei konkurrierenden Strategien senken

Lass 3 parallele Devin-Sessions gegen eine langsame Checkout-API antreten – jede probiert eine andere Optimierung, anschließend wird der beste Ansatz ausgeliefert.
AuthorCognition
CategoryDevin Optimization
FeaturesFortgeschritten
1

Definieren Sie die Problemstellung und die Erfolgskriterien

Ihre Checkout-API (POST /api/checkout) hat eine p99-Latenz von 1,8 Sekunden – Nutzer brechen den Kaufvorgang ab und Ihr SLA-Ziel liegt bei 400 ms. Es gibt mehrere sinnvolle Ansätze, um das zu beheben: Caching, Query-Optimierung, asynchrone Verarbeitung, Connection-Pooling. Sie wissen nicht, welcher Ansatz am besten funktioniert, bevor Sie ihn ausprobiert haben, und sie nacheinander auszuprobieren bedeutet Tage des Wartens.Verwenden Sie stattdessen Advanced Devin, um 3 Sessions parallel zu starten, von denen jede eine andere Strategie untersucht. Nachdem alle 3 fertig sind, vergleicht Advanced Devin die Ergebnisse und stellt den Gewinner bereit – oder kombiniert die besten Teile aus allen zu einem einzelnen PR.Um loszulegen, wählen Sie Advanced im Agent Picker auf der Devin-Homepage und klicken Sie dann auf den Tab Start Batch Sessions.
2

Formulieren Sie einen Prompt, der jede Sitzung auf eine andere Fehlerbehebung ausrichtet

Der Nutzen von 3 Sitzungen hängt davon ab, dass jede wirklich einen anderen Ansatz verfolgt. Formulieren Sie Ihren Prompt so, dass er unterschiedliche Ansätze fördert – schlagen Sie konkrete Strategien vor und definieren Sie, was „best“ bedeutet, damit die Ergebnisse direkt vergleichbar sind.Tipps für einen guten Multi-Strategie-Prompt:
  • Definiere „best“ mit gewichteten Kriterien. Das Auflisten von Vergleichsdimensionen – Latenz, Fehlerrate, Komplexität, Konsistenz – verhindert, dass Devin standardmäßig nur auf rohe Geschwindigkeit optimiert.
  • Schlage konkrete Strategien vor. Optionen wie „Caching, Query-Rewriting, asynchrone Verarbeitung“ lenken jede Sitzung in eine andere Richtung.
  • Füge einen Benchmark-Befehl ein. Jede Sitzung braucht eine reproduzierbare Methode, um ihr eigenes Ergebnis zu messen – npm run bench, k6 run load-test.js oder eine einfache curl-Schleife.
  • Verweise auf den Code. Ein Dateipfad wie src/routes/checkout.ts stellt sicher, dass alle 3 Sitzungen vom gleichen Ausgangspunkt starten.
3

Ergebnisse vergleichen und den Gewinner auswählen

Sobald alle 3 Sessions abgeschlossen sind, überprüft Advanced Devin ihre Arbeit nebeneinander anhand deiner Kriterien – verwendete Strategien, Benchmark-Zahlen, Trade-offs – und wählt entweder die beste Lösung aus oder fasst sie zu einer kombinierten Lösung in einem finalen PR zusammen.So sieht dieser Vergleich für das Checkout-Latenz-Problem aus:
Session 1 — Redis-Response-Caching
  Strategie:    Serialisierten Warenkorb + Inventarabfragen in Redis mit
                30s TTL cachen, DB für wiederholte Anfragen umgehen
  p99:          1,8s -> 320ms  (BESTANDEN — 82% Reduktion)
  Fehler:       Keine Änderung
  Komplexität:  +1 Abhängigkeit (ioredis), 2 neue Dateien
  Kompromiss:   Veraltete Inventardaten für bis zu 30s; 40 MB Redis-Speicher

Session 2 — Query-Optimierung + Connection-Pooling
  Strategie:    N+1-Abfragen durch einen einzelnen JOIN ersetzt, PgBouncer
                Connection-Pool hinzugefügt (25 Verbindungen)
  p99:          1,8s -> 580ms  (FEHLGESCHLAGEN — noch über 400ms)
  Fehler:       Keine Änderung
  Komplexität:  0 neue Abhängigkeiten, sauberere Abfragen
  Kompromiss:   Keine wesentlichen — insgesamt geringere DB-Last

Session 3 — Asynchrone Auftragsverarbeitung
  Strategie:    Zahlungsverarbeitung und E-Mail in eine Hintergrundwarteschlange
                (BullMQ) verschoben, 202 sofort nach Inventarprüfung zurückgeben
  p99:          1,8s -> 190ms  (BESTANDEN — 89% Reduktion)
  Fehler:       Keine Änderung
  Komplexität:  +1 Abhängigkeit (bullmq), 3 neue Dateien, Webhook-Handler
  Kompromiss:   Checkout wird eventually consistent; benötigt Webhook
                zur Zahlungsbestätigung

Fazit: Session 1 und 3 erfüllen beide das 400ms-Ziel. Die Query-Korrekturen
aus Session 2 sind wertvoll, aber allein nicht ausreichend.

Finaler PR: Query-Optimierung aus Session 2 (ohne Mehraufwand, eindeutig
besser) mit asynchroner Verarbeitung aus Session 3 kombiniert. Zahlung + E-Mail
in Warteschlange verschoben, N+1-Abfragen behoben. Finales p99: 150ms. PR #412 erstellt.
Sie können die einzelnen Session-PRs überprüfen, bevor Advanced Devin die zusammengeführte PR erstellt. Wenn Sie eine Vorgehensweise klar bevorzugen, sagen Sie Devin einfach: „Verwende den Ansatz aus Session 3, überspring die Kombination.“
4

Wann Sie drei Strategien bei einem einzelnen Problem gegeneinander antreten lassen sollten

Gute Eignung — es gibt mehrere sinnvolle Ansätze:
  • Performance-Engpässe, bei denen Caching, Query-Tuning und Architekturänderungen alle infrage kommen
  • Architekturentscheidungen mit echten Abwägungen (Aufspaltung eines Monolithen, Neugestaltung des State-Managements)
  • Auswahl eines Algorithmus für ein datenintensives Problem (unterschiedliche Indexierung, Ranking- oder ML-Ansätze)
Schlechte Eignung — die Lösung ist offensichtlich:
  • Bugfixes mit klarer Ursache
  • Hinzufügen eines standardmäßigen CRUD-Endpunkts
  • Aktualisieren von Abhängigkeiten oder Konfigurationsdateien
Dieses Pattern verbraucht das 3‑Fache der ACUs einer einzelnen Session. Reserviere es für Probleme, bei denen du sonst Tage damit verbringen würdest, nacheinander verschiedene Ansätze auszuprobieren. Für unkomplizierte Aufgaben ist eine einzelne Devin-Session schneller und günstiger.Du kannst Batch-Sessions auch über die API starten, indem du advanced_mode auf batch setzt — nützlich für die Integration in CI-Pipelines, die automatisch mehrere Fixes gegeneinander laufen lassen, um eine Performance-Regression zu beheben. Wenn Devin vollständig autonom laufen soll, ohne auf deine Freigabe für Vorschläge zu warten, aktiviere das Flag bypass permissions, damit Sessions automatisch genehmigt werden und weiterlaufen.