> ## Documentation Index
> Fetch the complete documentation index at: https://docs.localmind.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Performance

> Performance-Optimierung für Automate-Workflows

Optimieren Sie die Performance Ihrer Automate-Workflows für schnellere Ausführung und bessere Ressourcennutzung. Vier Hebel zählen: die Gesamtausführungszeit, das Datenvolumen, das durch den Workflow fließt, die Skalierbarkeit unter Last — und der Credits-Verbrauch, den weniger und gezieltere Agent-Aufrufe senken.

## Ausführung verschlanken

Automate arbeitet die Nodes eines Workflows innerhalb einer Execution **sequenziell** ab — auch wenn Sie mehrere Branches nebeneinander zeichnen, laufen diese nacheinander. Echte parallele Ausführung innerhalb einer Execution gibt es nicht. Der wirksamste Hebel ist deshalb: weniger Arbeit pro Execution.

* **Branches sind kein Beschleunigungs-Werkzeug:** Die Gesamtzeit ist die Summe aller Node-Zeiten. Nutzen Sie Branches für Logik (Fallunterscheidungen), nicht für Tempo.
* **Unnötige Nodes vermeiden:** Jeder Node kostet Zeit. Konsolidieren Sie mehrere Transformations-Schritte in einem Node, entfernen Sie Nodes, deren Ergebnis nicht weiterverwendet wird, und prüfen Sie, ob Zwischenschritte wirklich nötig sind.
* **Batching statt Einzel-Calls:** Verarbeiten Sie Items in Gruppen statt einzeln — das reduziert API-Calls und Ausführungszeit deutlich. Details und die Konfiguration des Loop-Over-Items-Nodes finden Sie unter [Batching](/automate/batching).

## Caching (DIY-Pattern)

Automate bringt **keinen eingebauten Cache** mit — Caching ist ein selbstgebautes Pattern, das Sie mit Workflow Static Data (`$getWorkflowStaticData()`) oder einem externen Store (z. B. Redis oder einer Datenbank) umsetzen.

Planen Sie zuerst, was gecacht werden darf:

| Cachebar                              | Nicht cachebar       |
| ------------------------------------- | -------------------- |
| User Data (TTL: 1 Stunde)             | Real-time Data       |
| Product Information (TTL: 24 Stunden) | Transaction Data     |
| Configuration Settings (TTL: 1 Tag)   | Personalized Content |

Umsetzung mit Workflow Static Data in Code-Nodes:

<CodeGroup>
  ```javascript Cache lesen (Code-Node vor dem API-Call) theme={null}
  const staticData = $getWorkflowStaticData('global');
  const cacheKey = `user_${$json.userId}`;
  const TTL = 3600 * 1000; // 1 Stunde

  const cached = staticData[cacheKey];

  if (cached && Date.now() - cached.storedAt < TTL) {
    // Cache-Treffer: gespeicherte Daten verwenden
    return [{ json: { ...cached.data, fromCache: true } }];
  }

  // Cache-Miss: der nachfolgende Node führt den API-Call aus
  return [{ json: { ...$json, fromCache: false } }];
  ```

  ```javascript Cache schreiben (Code-Node nach dem API-Call) theme={null}
  const staticData = $getWorkflowStaticData('global');
  const cacheKey = `user_${$json.userId}`;

  staticData[cacheKey] = {
    data: $json,
    storedAt: Date.now(),
  };

  return $input.all();
  ```
</CodeGroup>

<Warning>
  Workflow Static Data wird nur bei **Production-Executions** (aktivierter Workflow) gespeichert — bei manuellen Test-Ausführungen im Editor gehen Änderungen verloren. Für robusteres Caching über Workflow-Grenzen hinweg nutzen Sie einen externen Store.
</Warning>

## API-Optimierung

| Technik                  | So funktioniert es                                                                                 |
| ------------------------ | -------------------------------------------------------------------------------------------------- |
| **Batch-Requests**       | Ein Batch-Request mit 100 Items statt 100 Einzel-Requests — siehe [Batching](/automate/batching)   |
| **Pagination**           | Große Datensätze seitenweise abrufen und verarbeiten (z.B. 100 Items pro Page)                     |
| **Selective Fields**     | Nur benötigte Felder anfordern: `GET /users?fields=id,name,email` statt `GET /users`               |
| **Conditional Requests** | ETags und Last-Modified Headers nutzen: `If-None-Match: "etag-value"`, `If-Modified-Since: "date"` |

## Timeout-Konfiguration

| API-Typ       | Timeout | Beschreibung                                        |
| ------------- | ------- | --------------------------------------------------- |
| Schnelle APIs | 5 s     | Lokale APIs, schnelle Services                      |
| Standard-APIs | 30 s    | Externe APIs, Standard-Services                     |
| Langsame APIs | 60 s    | Schwere Operationen, Batch-Processing               |
| Agent-Aufrufe | 45 s    | Localmind Agent Aufrufe (unverbindlicher Richtwert) |

<Note>
  Diese Werte sind **unverbindliche Richtwerte** aus der Praxis, keine garantierten Antwortzeiten. Die tatsächliche Dauer — insbesondere von Agent-Aufrufen — hängt von Modell, Prompt-Länge und Tool-Nutzung ab. Messen Sie Ihre realen Zeiten über die Executions-Liste und passen Sie die Timeouts entsprechend an.
</Note>

## Datenfilterung

Filtern Sie Daten so früh wie möglich im Workflow — das bedeutet weniger Daten zu verarbeiten, schnellere Ausführung und geringeren Speicherverbrauch:

```javascript Frühe Filterung theme={null}
// Gut: Filtere früh
Trigger → Filter (nur relevante Daten) → Process

// Schlecht: Filtere spät
Trigger → Process (alle Daten) → Filter → Output
```

Typische Ansatzpunkte: nach Status filtern vor der Verarbeitung, nach Datum vor dem API-Call, nach Typ vor der Transformation.

## Ausführungen auswerten

Automate bringt **kein Performance-Dashboard und keine automatische Metriken-Überwachung** mit. Was Sie real haben: Die **Executions-Liste** zeigt Status und Dauer jeder Ausführung — daraus werten Sie manuell aus.

* **Langsame und fehlerhafte Workflows finden:** Status (Erfolg/Fehler) und Dauer pro Execution ablesen, nach fehlgeschlagenen Executions filtern, auffällig lange Ausführungen identifizieren und öffnen.
* **Einzelne Execution analysieren:** In der Detailansicht nachvollziehen, an welchem Node die Zeit verloren geht oder welcher Node fehlgeschlagen ist. Vergleichen Sie mehrere Executions desselben Workflows, um Ausreißer von systematischen Problemen zu unterscheiden.
* **Eigene Auswertung bauen (DIY):** Wenn Sie Kennzahlen über viele Executions hinweg brauchen, arbeiten Sie mit der Executions-Liste in der Web-App und übertragen die relevanten Werte in Ihr eigenes Tooling — ein selbstgebautes Pattern, kein eingebautes Feature. Für eine programmatische Anbindung siehe [Automate-API](/administration/api).

## Häufige Performance-Probleme

| Problem                     | Lösung                                                                                                                                                           |
| --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Zu viele einzelne API-Calls | Calls zu Batch-Requests kombinieren ([Batching](/automate/batching)), Caching implementieren (DIY-Pattern, siehe oben), prüfen ob alle Calls wirklich nötig sind |
| Unnötige Datenverarbeitung  | Daten früh im Workflow filtern, Selective Fields in API-Calls nutzen, unnötige Transformationen vermeiden                                                        |
| Fehlende Timeouts           | Angemessene Timeouts setzen, [Retry-Logik](/automate/Retry-Logic) implementieren, betroffene Executions in der Detailansicht prüfen                              |

## Performance-Checkliste

* [ ] Unnötige Nodes und Branches wurden entfernt
* [ ] Caching (DIY) ist für wiederholte Anfragen implementiert, wo sinnvoll
* [ ] API-Calls sind optimiert (Batching, Pagination)
* [ ] Timeouts sind angemessen konfiguriert
* [ ] Datenfilterung erfolgt früh im Workflow
* [ ] Executions werden regelmäßig auf Dauer und Fehler geprüft
* [ ] Langsame Nodes wurden identifiziert und optimiert

Weiterführend: [Batching](/automate/batching), [Testing](/automate/testing) und [Debugging](/automate/debugging).