cache ping

cache ping prüft, ob die beiden Zwischenspeicher erreichbar sind, die Apparat über einzelne Aufrufe hinweg braucht — und wo sie liegen. Reine Diagnose: keine Sammlung wird geöffnet, kein Index angefasst, nichts neu berechnet.

Wofür ist das?

Zwei Ergebnisse hält Apparat länger vor, weil sie teuer sind und sich nicht ändern:

• Bedeutungs-Vektoren. Denselben Text in Zahlen zu übersetzen liefert immer dasselbe Ergebnis, also wird es einmal berechnet und danach nachgeschlagen. Dieser Speicher ist installationsweit geteilt — was eine Sammlung berechnen lässt, kommt allen zugute.
• Erkannte Beziehungen. Die Vorschläge zu einem Eintragstext werden beim Anfordern berechnet und bis zur nächsten Textänderung behalten. Dieser Speicher gehört jeweils einer Installation allein, denn er nennt deren eigene Einträge.

Beide leben außerhalb des Arbeitsspeichers eines einzelnen Web-Prozesses — sonst ginge das Ergebnis zwischen Anfordern und Anzeigen verloren. Typische Aufrufer:

• Erst-Einrichtung. Nach dem Hochfahren sagt cache ping in ein paar Zeilen, ob die Zwischenspeicher stehen und unter welchem Namensraum sie schreiben.
• Diagnose. Wenn Vorschläge immer wieder neu gerechnet werden, obwohl sich nichts geändert hat, zeigt cache ping, ob der Speicher überhaupt antwortet.
• Nach einem Umzug. Wechselt die Adresse oder der Namensraum, ist das die schnellste Gegenprobe.

Aufruf

apparat cache ping

Das Kommando hat keine Optionen. Geprüft wird immer genau das, was die Installation tatsächlich benutzt — nicht eine fest verdrahtete Adresse.

Beispielausgaben

Alles in Ordnung:

Embedding vectors (shared across tenants) — store "redis-shared"
  Driver: redis
  Connection "cache-shared": redis:6379, database 1
  Key prefix: "apparat-shared-" (connection) + "apparat-cache-" (cache store)
✅ Round trip completed.
Relation suggestions (this tenant) — store "redis"
  Driver: redis
  Connection "cache": redis:6379, database 1
  Key prefix: "apparat-acme-" (connection) + "apparat-cache-" (cache store)
✅ Round trip completed.
✅ All configured caches are healthy.

Speicher nicht erreichbar:

Embedding vectors (shared across tenants) — store "redis-shared"
  Driver: redis
  Connection "cache-shared": redis:6379, database 1
  Key prefix: "apparat-shared-" (connection) + "apparat-cache-" (cache store)
❌ Store unreachable.
  Connection refused [tcp://redis:6379]
❌ At least one cache did not answer.

Geprüft wird mit einem vollständigen Durchlauf: schreiben, zurücklesen, wieder entfernen. Ein bloßes Lesen würde einen Speicher durchgehen lassen, der nur noch antwortet, aber nichts mehr behält — und genau das macht ihn nutzlos. Der Prüfeintrag trägt einen zufälligen Namen und ist nach dem Aufruf wieder weg.

Die zwei Namensräume

Jeder Schlüssel trägt zwei Präfixe, und die Ausgabe zeigt beide, weil eine Schlüsselliste sie aneinandergehängt zeigt:

Dass der geteilte Vektor-Speicher ein eigenes Verbindungs-Präfix hat, ist der Grund, warum er installationsübergreifend wirkt: Er entkommt damit bewusst dem Präfix der einzelnen Installation.

Exit-Codes

Konfiguration

Ein Aufruf auf dem Host erreicht den Speicher-Dienst in der Regel nicht — er ist wie der Erkennungs-Dienst nur von innen sichtbar. Das apparat-Kommando führt cache ping deshalb automatisch im Container aus; aufrufseitig bleibt der Befehl gleich.

Was nebenbei wichtig ist

Ein ausgefallener Zwischenspeicher legt Apparat nicht lahm: Vektoren werden dann direkt berechnet, Beziehungsvorschläge bleiben aus, bis sie erneut angefordert werden. Spürbar ist der Ausfall als Langsamkeit und als Vorschläge, die nach jedem Aufruf neu erscheinen — nicht als Fehlermeldung. Genau deshalb lohnt der gelegentliche Blick mit cache ping.