Hilfe:Vorlagenbeschränkungen
Diese Hilfeseite für Vorlagenprogrammierer beschreibt Begrenzungen der Wikisyntax, die bei sehr großen Seiten oder solchen mit sehr vielen Vorlagen dazu führen können, dass die Seite nicht richtig angezeigt wird.
Man mag sich darüber streiten, ob ein Schwellenwert von 40 oder 50 der geeignete sei, oder ob es statt 500 lieber 1000 sein dürfen. Gleichwohl sind Begrenzungen notwendig:
- Durch endlose Rekursion könnte eine einzelne Seite den gesamten Server zum Erliegen bringen.
- Böswillige Attacken könnten einen Server damit bewusst flachlegen.
- Die resultierenden HTML-Seiten sollen bei den Lesern noch in vertretbarer Zeit abgerufen werden und dargestellt werden. Eine Begrenzung der gesamten Seitengröße ist auch deshalb irgendwann unausweichlich.
- Extrem ineffiziente und überflüssige Vorlagenprogrammierung muss nicht gefördert werden.
Auf dieser Hilfeseite wird der Begriff „Vorlage“ auch für beliebige eingebundene Wikitext-Seiten verwendet; er gilt weiterhin analog für die Programmierung in Lua wie für die klassische Vorlagensyntax.
Grenzwerte
[Bearbeiten | Quelltext bearbeiten]Bezeichnung | Grenzwert | Erläuterungen |
---|---|---|
CPU-Zeit (Sekunden) CPU time usage cputime
|
| |
Echtzeitbedarf (Sekunden) Real time usage walltime
| ||
Besuchte Knotenanzahl des Präprozessors Preprocessor visited node count ppvisitednodes
|
1000000
|
|
Erzeugte Knotenanzahl des Präprozessors Preprocessor generated node count ppgeneratednodes
|
1500000
|
|
Einbindungsgröße nach dem Expandieren (Bytes) Post-expand include size postexpandincludesize
|
2097152
|
|
Vorlagenargumentgröße (Bytes) Template argument size templateargumentsize
|
2097152
|
|
Höchste Expansionstiefe Highest expansion depth expansiondepth
|
100 [1]
|
Verschachtelungstiefe
Stellt man sich alle Seiteneinbindungen expandiert vor, ist es die maximale Anzahl nacheinander geöffneter geschweifter Klammerpaare |
Anzahl aufwändiger Parserfunktionen Expensive parser function count expensivefunctioncount
|
500 | Typische Vertreter:
|
Verschachtelungstiefe bei der Auflösung von MediaWiki-Elementen („Unstrip“) überschritten. | 20 | Sinnvoll vorstellbar wären 3–4 Ebenen, auf denen MediaWiki-Tags andere MediaWiki-Tags einschließen könnten.
|
Textgröße bei der Auflösung von MediaWiki-Elementen („Unstrip“) überschritten. | 5000000 Bytes (5 MiB) |
|
Lua-Zeit (Sekunden) Lua time usage scribunto .limitreport-timeusage
|
10
|
Anteil der CPU-Zeit, in der ausschließlich Lua-Code ausgewertet wird. |
Lua-Speichernutzung (MB) Lua memory usage scribunto .limitreport-memusage
|
50
| |
Wikidata-OjekteEntityAccessCount
|
400
|
Anzahl eingebundener Wikidata-Ojekte, ausgenommen des eigenen Items der Seite. |
In der Regel und bei normalen (und damit recht kleinen) Seiten werden die Grenzwerte bei weitem nicht erreicht. Nur wenn es Darstellungsprobleme gibt oder deshalb zu einer vorhandenen Vorlagenprogrammierung eine effizientere Struktur ausgetüftelt werden muss, sind die Daten zu analysieren.
Parser Profiling Report
[Bearbeiten | Quelltext bearbeiten]Der „PP Report“ gibt für die aktuelle Seite die benötigte Ressourcennutzung an.
JavaScript-Quelltext (ab 2016)
[Bearbeiten | Quelltext bearbeiten]Es wird ein JavaScript-Konfigurationsparameter wgPageParseReport
generiert.
- Die Angaben könnten von Programmierern ausgewertet und beliebig in der Seite dargestellt werden.
- Seine Definition ist im HTML-Quelltext nachlesbar.
- Er steht in einer HTML-Struktur
<script></script>
am Ende des Dokuments; nach Inhalten und Fußzeilen. - Beispiel:
- Er steht in einer HTML-Struktur
(window.RLQ=window.RLQ||[]).push(function(){mw.config.set( {
"wgPageParseReport": {
"limitreport": {
"cputime": "0.100",
"walltime": "0.126",
"ppvisitednodes": {
"value": 405,
"limit": 1000000
},
"ppgeneratednodes": {
"value": 0,
"limit": 1500000
},
"postexpandincludesize": {
"value": 7879,
"limit": 2097152
},
"templateargumentsize": {
"value": 617,
"limit": 2097152
},
"expansiondepth": {
"value": 6,
"limit": 40
},
"expensivefunctioncount": {
"value": 0,
"limit": 500
},
"timingprofile": [
"100.00% 92.359 1 -total",
" 87.87% 81.154 1 Vorlage:Hilfe",
" 10.33% 9.538 11 Vorlage:Anker",
" 5.28% 4.877 11 Vorlage:Anker/code",
" 2.98% 2.753 5 Vorlage:Hilfe/style"
]
},
"scribunto": {
"limitreport-timeusage": {
"value": "0.048",
"limit": "10.000"
},
"limitreport-memusage": {
"value": 1400206,
"limit": 52428800
}
},
"EntityAccessCount": 0,
"cachereport": {
"origin": "mw1212",
"timestamp": "20160829130745",
"ttl": 2592000,
"transientcontent": true
}
}
} );});
mw.config.set( { "wgBackendResponseTime": 268,
"wgHostname": "mw1323"
} );
Dieses Feature wurde im August 2016 eingeführt.
HTML-Quelltext
[Bearbeiten | Quelltext bearbeiten]Der „NewPP limit report“ steht noch bis auf Weiteres im HTML-Quelltext jeder aus Wikitext generierter Seiten (also außer Spezialseiten) als Kommentar am Ende des Content
-Bereichs innerhalb des Portalrahmens.
- Das durch die Skin vorgegebene Portal wird aus vorgefertigten Elementen je nach Namensraum, Benutzergruppe usw. als Grundgerüst der HTML-Seite erstellt und zählt bei den Begrenzungen nicht mit; nur der aus dem Wikitext generierte
Content
wird gewertet. Spezialseiten haben deshalb keine solche Auswertung. - Der „PP Report“ steht sowohl im Quelltext der statischen Seite (mit
/wiki/
) wie auch in der Seitenvorschau. - Dem LivePreview wird zurzeit kein PP Report mitgegeben, erst recht nicht aktualisiert.
- Achtung: Bei den Werkzeugen der Browser zur HTML-Inspektion der Seite werden meist keine Kommentare wiedergegeben; es müsste ein HTML-Quelltext eingesehen werden, wie er ursprünglich vom Server übermittelt wurde.
Beispiel (Kommentar):
<!--
NewPP limit report
Parsed by deployment‐mediawiki‐07
Cached time: 20190704122006
Cache expiry: 2592000
Complications: []
Dynamic content: false
CPU time usage: 0.176 seconds
Real time usage: 0.213 seconds
Preprocessor visited node count: 172/1000000
Preprocessor generated node count: 1251/1500000
Post‐expand include size: 6349/2097152 bytes
Template argument size: 391/2097152 bytes
Highest expansion depth: 8/40
Expensive parser function count: 0/500
Unstrip recursion depth: 0/20
Unstrip post‐expand size: 123456/5000000 bytes
Number of Wikibase entities loaded: 0
Lua time usage: 0.005/10.000 seconds
Lua memory usage: 509 KB/50 MB
Transclusion expansion time report (%,ms,calls,template)
100.00% 11.709 1 - Vorlage:Wartungskategorie
100.00% 11.709 1 - -total
38.76% 4.538 1 - Vorlage:„
22.32% 2.613 2 - Vorlage:De-ch
20.02% 2.344 1 - Vorlage:“
17.54% 2.054 1 - Vorlage:Bausteindesign1
-->
Seitenvorschau
[Bearbeiten | Quelltext bearbeiten]Im Fußbereich der Quelltext-Seitenvorschau wird eine ausklappbare Tabelle gezeigt, aus der Vorlagenprogrammierer die aktuellen Werte entnehmen können, ohne erst im HTML-Quelltext nachsehen zu müssen.
- Für Normalbenutzer ist dies jedoch völlig belanglos.
- Für den letzten Ausklappzustand wird ein Session-Cookie
preview-limit-report
angelegt mit den Wertencollapsed
oderexpanded
.
Die Tabelle hat .limitreport
als CSS-Selektor und ließe sich bei Nichtgefallen ausblenden.
Beispiel (deutschsprachige Tabelle, mit class="preview-limit-report"
)
Genutzte CPU-Zeit | 18.665 Sekunden |
Genutzte Zeit | 18.862 Sekunden |
Vom Präprozessor besuchte Knoten | 595310/1000000 |
Vom Präprozessor erzeugte Knoten | 0/1500000 |
Einbindungsgröße nach dem Expandieren | 2097152/2097152 Bytes |
Vorlagenargumentgröße | 970555/2097152 Bytes |
Höchste Expansionstiefe | 24/40 |
Anzahl aufwändiger Parserfunktionen | 7/500 |
Unstrip-Rekursionstiefe | 0 von 20 |
Unstrip-Größe nach dem Expandieren | 8.354 von 5.000.000 Bytes |
Anzahl der geladenen Wikibase-Objekte | 0 von 400 |
Lua – Zeitnutzung | 2.819/10.000 Sekunden |
Lua – Speichernutzung | 1,79 MB/50 MB |
JavaScript
[Bearbeiten | Quelltext bearbeiten]Der Konfigurationsparameter wgBackendResponseTime
enthält die Antwortzeit des Servers in ganzzahligen Millisekunden.
Seit August 2016 wird außerdem wgPageParseReport
definiert.
Cache-Informationen
[Bearbeiten | Quelltext bearbeiten]Traditionell und bis auf Weiteres wird in den HTML-Quelltext ein Kommentar wie nachstehend am Ende des Inhaltes (vor Fußzeilen und Portal-Rahmen) geschrieben:
<!-- Saved in parser cache with key dewiki:pcache:idhash:8883558-0!*!0!!de!2!* and timestamp 20160829120204 and revision id 57388067
-->
Er identifiziert den Seiten-Cache des Inhalts. Möglicherweise wird er gelegentlich ebenfalls im JavaScript-Format generiert.
Lua
[Bearbeiten | Quelltext bearbeiten]Für Lua ist die Länge expandierter Zeichenketten und die Knotenanzahl wenig relevant.
- Das
#invoke
und eine Handvoll Parameter tragen nicht auf; insbesondere wenn die Lua-Programmierung bereits in der Nähe der angezeigten Seite greift und dort komplexe Aufgaben löst und nicht erst vielfach in tieferen Schachtelungsebenen einsetzt. - Die Länge der Lua-Programmierung geht nicht in die Grenzwerte ein.
Maßgeblich ist die Begrenzung der Echtzeit.
- Damit es auch in Spitzenzeiten nicht zu Problemen kommt, sollte die CPU-Zeit bei nicht mehr als gut zwei Sekunden gehalten werden.
Generell senkt der Einsatz von Lua den Ressourcenverbrauch einer stark mit Vorlagen bestückten Seite auf etwa ein Drittel.
- Effizient ist die Nutzung von mw.loadData() für mehrfach in eine Seite eingebundene größere Datenmengen (keine Funktionen), die dann nur einmal ausgeführt wird.
Wartungskategorien
[Bearbeiten | Quelltext bearbeiten]Beim Überschreiten der Grenzwerte werden die Seiten in Wartungskategorien der Seitenbeschränkung überschritten eingeordnet.
Kandidaten für gesprengte Limits finden sich unter Spezial:Längste Seiten.
Möglichkeiten der Abhilfe
[Bearbeiten | Quelltext bearbeiten]Wenn Grenzen überschritten werden, gibt es folgende Lösungsansätze:
- Aufteilung der Seite
- Verzicht auf Einbindung vieler selbstständiger Unterseiten in einer großen Zusammenstellung
- Vereinfachung von Vorlagenprogrammierung
- Ersatz von Vorlagen durch Lua
Anmerkungen
[Bearbeiten | Quelltext bearbeiten]- ↑ Seit Anfang 2022 – zuvor
40