Leistung und Skalierung
Diese Seite richtet sich an Datenbankadministratoren, die die Datenbank einer Exponential-Website bemessen oder den Grund suchen, warum sie langsam ist. Sie beantwortet: wie viel des Verkehrs die Datenbank überhaupt erreicht, was sie erreicht und welche Hebel bei jeder Engine helfen. Quellen: Datenbankunterstützung, Leistung und Skalierung, Was die Leselast trägt und 10.12 Leistungsoptimierung.
Inhalt
- Die meisten Anfragen erreichen die Datenbank nie
- Was sie erreicht
- Verbindungen und Worker
- Je Engine
- Die Hebel, der Reihe nach
- Checkliste
Die meisten Anfragen erreichen die Datenbank nie
| Ebene | Einstellung | Was ein Treffer kostet |
|---|---|---|
| Antwort-Cache von Velocity | settings/velocity.ini [CacheSettings] Enabled=enabled, DefaultTtl=30 | vom Elternprozess von Velocity beantwortet: kein PHP-Worker, keine Datenbank; nur anonyme Besucher |
| Cache der Inhaltsansichten | site.ini [ContentSettings] ViewCaching=enabled | der Hauptbereich einer Seite aus einer Datei |
| Template-Block-Cache | site.ini [TemplateSettings] TemplateCache=enabled | Menüs und Fußzeilen aus Dateien |
| SQL-Abfrage-Cache | standardmäßig querycache.ini Mode=off | ein wiederholtes SELECT aus APCu oder einer Datei; nicht auf MongoDB (Der SQL-Abfrage-Cache) |
| Dateicache des Betriebssystems | Datenbankseiten nach dem ersten Lesen aus dem Speicher |
Der statische Cache ([ContentSettings] StaticCache) ist im mitgelieferten Installer ausgeschaltet und sollte es bleiben: Mit
ihm erzeugte jede Veröffentlichung die betroffenen Seiten innerhalb der Anfrage des Redakteurs über HTTP neu.
Was sie erreicht
- die ersten Aufrufe nach dem Leeren eines Cache oder einer Veröffentlichung;
- angemeldete Redakteure und die Administration;
- die Suche (die eingebaute Maschine liest
ezsearch_*); - Veröffentlichen, Workflows, Cronjobs, Importe.
Bemessen Sie die Datenbank dafür, nicht für die Gesamtzahl der Seitenaufrufe. Rechnen Sie nach einem Deploy, der Caches leert,
mit einem kurzen Schub (dem Aufwärmen); exp:preload wärmt die Seiten einer Website gezielt vor
(Caches vorladen).
Verbindungen und Worker
- Unter PHP-FPM öffnet jeder Worker seine eigene Verbindung, wenn eine Anfrage eine braucht.
UsePersistentConnection=enabledbehält sie für die Lebensdauer des Workers (MySQL, PostgreSQL, Oracle). - Unter Velocity mit persistenten Workern (
settings/velocity.ini [ServerSettings] ForkPerRequest=disabled, der mitgelieferte Wert) hält jeder Worker die Anwendung, seine Verbindung und seine Caches warm. Die Poolgröße ist[ServerSettings] Workers(mitgeliefert4), optional dynamisch mitSpareWorkersundIdleWorkerTimeout(Velocity-Worker und Pools). - Zählen Sie die Verbindungen: PHP-FPM-Worker plus Velocity-Worker plus Cron- und Konsolenprozesse, je Website, gegen das Limit
des Servers (
max_connectionsauf MySQL und PostgreSQL, Sessions oder ein DRCP-Pool auf Oracle).
Je Engine
| Engine | Hebel |
|---|---|
| SQLite | Lesezugriffe skalieren mit der Zahl der Prozesse; Schreibzugriffe reihen sich ein. Rechnen Sie mit bis zu 64 MB Seiten-Cache je Prozess, der die Datenbank geöffnet hat (SQLitePragmas[]=cache_size=-16384 senkt ihn auf 16 MB). ANALYZE nach Importen (SQLite-Wartung) |
| PostgreSQL | Sperren auf Zeilenebene; persistente Verbindungen; Ihr übliches Tuning von shared_buffers und Autovacuum; Replikation ist extern |
| MariaDB, MySQL | InnoDB-Zeilensperren; persistente Verbindungen; innodb_buffer_pool_size für den Arbeitsbestand bemessen; Lesereplikate mit UseSlaveServer (Lesereplikate) |
| MongoDB | die Leistung folgt der Zahl der Anweisungen je Seite; legen Sie die Indizes aus bin/mongodb/create_indexes.js an, ohne die Teilbaumabfragen und URL-Alias-Suchen ganze Collections durchsuchen |
| Oracle | eine neue dedizierte Session kostet Dutzende Millisekunden: Persistent=enabled und DRCP; die Einstellungen zu Prefetch; Statistiken mit gather-stats (Oracle-Tuning) |
Serverparameter wie Buffer-Pools gehören Ihrer Engine; Exponential setzt oder verlangt keine bestimmten Werte.
Die Hebel, der Reihe nach
- Caches an: View-Cache, Template-Block-Cache, Antwort-Cache von Velocity; prüfen Sie sie unter Setup > Systeminformationen, Karte Caches.
- Statistiken aktuell:
ANALYZE(SQLite, PostgreSQL),gather-stats(Oracle); MongoDB-Indizes angelegt. - Die Anweisungen finden: Langsame Abfragen finden; korrigieren Sie wiederholte Abfragen an ihrer Quelle.
- Abfrage-Cache
request, dannshared. - Persistente Verbindungen oder die persistenten Worker von Velocity.
- Replikate für MySQL und MariaDB; ein größerer Server oder eine andere Engine, wenn sich Schreibzugriffe stauen (Eine Engine wählen).
Messen Sie jeden Schritt mit exp:benchmark --save und --baseline (Benchmark).
Checkliste
- To do: Caches eingeschaltet; statischer Cache aus.
- To do: Verbindungszahl aller Worker unter dem Limit des Servers.
- To do: SQLite-Speicher für
cache_sizeje Worker bemessen. - To do: Statistiken und Indizes aktuell.
- To do: Jede Änderung vorher und nachher gemessen.
Verwandte Seiten
- Caching-Ebenen, PHP-FPM-Tuning
- Speicher, CPU und Festplatte bemessen
- Die Datenbank überwachen
- 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.