Hilfe:Vorlagenbeschränkungen

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von Hilfe:Seitenbeschränkungen)
Zur Navigation springen Zur Suche springen

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 und ihre Bedeutung
Bezeichnung Grenzwert Erläuterungen
CPU-Zeit (Sekunden)
CPU time usage
cputime
  • Die Echtzeitnutzung hat immer einen leicht größeren Wert als die CPU-Nutzung. Am Verhältnis der beiden Werte zueinander lässt sich die momentane Serverlast ablesen.
  • Es wird berichtet, dass bei großer Serverbelastung die Echtzeit den vierfachen Wert der CPU-Zeit annehmen könne. In ruhigen Zeiten ist der Unterschied gering.
  • Es ist die Zeit, in der auf dem Server der Wikitext in HTML umgewandelt wird zwecks Ablage im Seiten-Cache; nicht zu verwechseln mit Antwortzeiten aus dem Netzwerk.
Echtzeitbedarf (Sekunden)
Real time usage
walltime
Besuchte Knotenanzahl des Präprozessors
Preprocessor visited node count
ppvisitednodes
1000000
  • Bestimmte Syntaxelemente wie <nowiki> oder auch {{}} bilden einen oder mehrere Knoten.
  • Nicht wirksam gewordene Zweige von {{#if: etc. und {{#switch: zählen nicht als „besucht“.
Erzeugte Knotenanzahl des Präprozessors
Preprocessor generated node count
ppgeneratednodes
1500000
  • Alle Syntaxelemente der gesamten Seite auch außerhalb der Vorlagen, etwa Überschriften, werden ein- oder mehrfach als Knoten gezählt.
Einbindungsgröße nach dem Expandieren (Bytes)
Post-expand include size
postexpandincludesize
2097152
  • Gesamtlänge der Seite, zuzüglich aller Quelltexte von Vorlagen und Untervorlagen; teils mehrfach zählend.
  • Kommentare und noinclude/onlyinclude zählen nicht mit. Damit spielt es in diesem Zusammenhang keine Rolle (mehr), ob die Dokumentation auf einer separaten Seite steht.
  • Abschluss der ersten Runde, bei der alle eingebundenen Seiten (Vorlagen) expandiert wurden; MediaWiki-Elemente sind aber nur mit einer kleinen Markierung repräsentiert.
Vorlagenargumentgröße (Bytes)
Template argument size
templateargumentsize
2097152
  • Länge aller ersetzten Argumente der Vorlagen; teils mehrfach zählend.
Höchste Expansionstiefe
Highest expansion depth
expansiondepth
100[1] Verschachtelungstiefe
  • Jede Seiteneinbindung innerhalb einer anderen.
  • Jeder Aufruf einer Parserfunktion.
  • Jede Parserfunktion, die eine andere Parserfunktion oder Seiteneinbindung als Parameter hat, führt zu tieferer Verschachtelung (insbesondere {{#if: etc. und {{#switch:).
  • Ein Vorgabewert wie {{{1|{{ROOTPAGENAME}}}}} öffnet ebenso eine weitere Ebene; ggf. von dort weitere Einbindungen.

Stellt man sich alle Seiteneinbindungen expandiert vor, ist es die maximale Anzahl nacheinander geöffneter geschweifter Klammerpaare {{ bis zur tiefsten Ebene.

Anzahl aufwändiger Parserfunktionen
Expensive parser function count
expensivefunctioncount
500 Typische Vertreter:
  • Abfrage der Existenz von Seiten und Dateien
  • Statistische Zählungen, wie Seitenanzahl in einer Kategorie oder Seitengröße
  • Zugriff auf Wikidata-Objekte ungleich der aktuellen Seite. Dabei zählt die Mehrfachabfrage von Properties eines Wikidata-Objekts nur als eine solche aufwändige Parserfunktion.
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.
  • Mehr wären ohnehin nur noch über Programmierungen per {{#tag:}} zu erreichen. Der Sinn bliebe fragwürdig.
  • Ein Erreichen des Limits deutet auf eine unbegrenzte Selbsteinbindung (Endlosschleife) hin.
Textgröße bei der Auflösung von MediaWiki-Elementen („Unstrip“) überschritten. 5000000 Bytes
(5 MiB)
  • Gesamtlänge des HTML-Inhaltsbereichs der Seite, alle Quelltexte eingebundener Seiten (Vorlagen) expandiert.
  • Nun auch Montage der zwischenzeitlich separat verwalteten MediaWiki-Elemente.
  • Absolute Begrenzung für den HTML-Inhalt, der anschließend noch in den Portalrahmen oder die Geräte-Umgebung des Benutzers einmontiert wird, um das gesamte HTML-Dokument zu ergeben.
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-Ojekte
EntityAccessCount
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:
(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.

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 Werten collapsed oder expanded.

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

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.

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
  1. Seit Anfang 2022 – zuvor 40