Caching-Ebenen für Ingenieure
Diese Seite richtet sich an Ingenieure, die Leistung und Korrektheit zusammen betrachten. Exponential hat viele Caches; die meiste Leistungsarbeit besteht darin zu wählen, welche eingeschaltet werden, und die meisten Fehler mit "veralteter Seite" sind einer davon, der antwortet, wenn er es nicht sollte. Die Sicht der Betreiber auf dieselben Ebenen ist Caching-Ebenen, und die Administrationsseite ist unter Caches beschrieben.
Inhalt
- Die Ebenen der Reihe nach
- Wonach jede Ebene geschlüsselt ist
- Geteilt oder je Knoten
- Risiken für die Korrektheit
- Wählen, was eingeschaltet wird
Die Ebenen der Reihe nach
Vom Besucher hinunter zur Datenbank:
| # | Ebene | Ausgeliefert | Bedient | Quelle |
|---|---|---|---|---|
| 1 | Browser-Cache für statische Dateien | Velocity: StaticMaxAge ein Jahr | alle | HTTP-Caching |
| 2 | Browser-Cache für Seiten | aus ([HTTPHeaderSettings]) | anonyme Besucher, wenn eingeschaltet | HTTP-Caching |
| 3 | CDN oder Caching-Proxy | nicht Teil von Exponential | wie konfiguriert | Exponential sendet keine Purges |
| 4 | Antwort-Cache von Velocity | unter Velocity an (velocity.ini [CacheSettings] Enabled=enabled) | anonyme Besucher | Antwort-Cache von Velocity |
| 5 | Rollenbewusster HTTP-Cache | aus (httpcache.ini) | anonyme und angemeldete Besucher, je Berechtigungskontext | HTTP-Cache |
| 6 | Statischer Cache | aus | anonyme Besucher, als Dateien | Standards des statischen Cache |
| 7 | View-Cache für Inhalte | an ([ContentSettings] ViewCaching=enabled) | jeden Besucher | Caches |
| 8 | Cache für Template-Blöcke | an ([TemplateSettings] TemplateCache=enabled) | jeden Besucher | Die Template-Engine und die Design-Kette |
| 9 | Kompilierte Templates, INI- und Override-Caches | an | jede Anfrage | Caches |
| 10 | Redis oder Valkey für Views, Blöcke, INI | nur mit sevenx_valkey_cache | jede Anfrage | sevenx_valkey_cache |
| 11 | SQL-Abfrage-Cache | aus (querycache.ini Mode=off) | jede Anfrage, die er beantworten kann | Der SQL-Abfrage-Cache |
| 12 | OPcache, APCu | je PHP-Prozess | jede Anfrage | Ihre PHP-Konfiguration |
Den Antwort-Cache von Velocity gibt es nur unter der Engine qbix: FrankenPHP hat noch keinen, und PHP-FPM hinter Apache
oder nginx hat keinen eigenen (Anwendungsserver).
Wonach jede Ebene geschlüsselt ist
| Ebene | Schlüssel (kurz) | Invalidiert durch |
|---|---|---|
| Antwort-Cache von Velocity | die Anfrage eines anonymen Besuchers; Lebensdauer [CacheSettings] DefaultTtl (mitgeliefert 30 Sekunden), sofern Cache-Control der Seite nichts anderes sagt | Lebensdauer, ./console exp:velocity cache clear --apply |
| Rollenbewusster HTTP-Cache | die Inhaltsansicht und der Berechtigungskontext (anonym, ein gemeinsamer Rollenkontext oder privat) | Purges bei Inhaltsänderungen (standardmäßig ContentChangePurges=all), --clear-id=exphttpcache |
| View-Cache für Inhalte | der Knoten, die Ansicht und ihre Parameter und der Zugriffskontext des Benutzers | eZContentCacheManager beim Veröffentlichen, --clear-tag=content |
| Cache für Template-Blöcke | die in {cache-block} geschriebenen Schlüssel und sein Ablauf | Ablauf, --clear-id=template-block |
| INI-Cache | die Dateien der Kaskade für einen Siteaccess (und eine Umgebung) | --clear-tag=ini |
| SQL-Abfrage-Cache | die SELECT-Anweisung | ein Schreibvorgang in eine der gelesenen Tabellen |
Geteilt oder je Knoten
Die Caches in var/ sind Dateien, die über den Cluster-Datei-Handler geschrieben werden, sodass derselbe Code sie auf
Cluster-Speicher teilen kann. Der Antwort-Cache von Velocity und der Speicherzustand seiner Worker gelten je
Serverprozess; OPcache und APCu je PHP-Prozess. Entscheiden Sie bei mehreren Webknoten für jede Ebene, ob sie geteilt,
auf jedem Knoten geleert oder ablaufen gelassen wird (Skalierung und Clustering).
Risiken für die Korrektheit
- Leeren vor dem Neuladen. Eine Seite, die der alte Code zwischen dem Leeren eines Cache und dem Neuladen von PHP-FPM oder Velocity rendert, wird erneut zwischengespeichert; leeren Sie Seiten-Caches zuletzt (Eine Änderung bereitstellen).
- Schreibvorgänge von außen. Eine Wiederherstellung oder ein Schreibvorgang über einen SQL-Client umgeht die Invalidierung des SQL-Abfrage-Cache; leeren Sie ihn danach.
- Cache-Blöcke ohne die richtigen Schlüssel. Ein
{cache-block}, der nicht nach dem schlüsselt, was die Ausgabe ändert, liefert das Fragment eines Benutzers oder einer Seite an einen anderen aus. - Velocity hält Einstellungen im Speicher. Nach einer INI-Änderung genügt unter Velocity das Leeren des INI-Cache nicht; starten Sie es neu.
- Statischer Cache. War er an, erzeugte jedes Veröffentlichen jede betroffene Seite über HTTP innerhalb der Anfrage des Redakteurs neu; das Projekt liefert ihn ausgeschaltet aus und empfiehlt, ihn ausgeschaltet zu lassen.
Wählen, was eingeschaltet wird
- Behalten Sie die mitgelieferten Standards: View-Cache, Template-Blöcke, kompilierte Templates, INI-Cache.
- Für anonymen Verkehr bringt unter Velocity der Antwort-Cache den größten Gewinn je Änderung.
- Für angemeldeten Verkehr hält der rollenbewusste HTTP-Cache ganze Ansichten je Berechtigungskontext.
- Für Seiten, die sich nicht als Ganzes speichern lassen (die Administration, private Kontexte, Skripte), der SQL-Abfrage-Cache.
- Bei mehreren Webknoten erwägen Sie Redis oder Valkey für Views, Blöcke und INI.
Messen Sie jeden Schritt (Leistungsmessung und Benchmarks).
Verwandte Seiten
- Cache-Invalidierung und Leeren
- Caching in Anwendungen
- Der Antwort-Cache und dem Netz aus dem Weg gehen
- Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.
Werden Sie Exponential-Partner
Partner teilen ihre Informationen, stellen Mittel bereit, geben Beiträge zurück und entwickeln die Produkte mit uns, und so wächst Exponential. Eine Partner-Website und ein Dashboard sind für Mitte 2027 geplant: Werden Sie noch heute Partner, damit wir schneller wachsen und neue Funktionen früher liefern.