Wikipedia Diskussion:Infoboxen/Server

Avoid using meta-templates

Schon mal gesehen:

However, note that Wikimedia developers agree that templates within templates can be severely problematic to server performance and that, as such, they should be avoided for technical reasons.

Lead Developer Jamesday has noted that they create a noticeable performance problem in general.

from en:WP:AUM

Pjacobi 12:38, 21. Dez 2005 (CET)

Die Analyse der Begründung dieser Aussagen hat mich zu folgender Erkenntnis gebracht: An denjenigen Stellen, an denen wir verschachtelte Vorlagen aus Funktionsgründen nötig haben, dürfte obige Aussage nicht wirklich relevant sein, da diese aufgrund bestimmter Voraussetzungen nicht den wesentlichen Anteil der Serverlast bedeuten würden.

Es gibt jedoch einige Stellen, wo man verschachtelte Vorlagen verwenden könnte aber nicht sollte. Beispielsweise obiger Vorschlag mit unterschiedlicher Funktion der Datenfelder je nach Parameteranzahl (mittels Vorlage:If) würde die für die Infoboxen benötigte Serverlast unnötigerweise erheblich erhöhen und sollte daher dringend vermieden werden. Weiterhin sollten benannte Datenfeldvorlagen "subst:" verwenden, wenn sie sich auf Vorlage:Datenfeld beziehen.

Aus den Begründungen, warum die verschachtelten Vorlagen vermieden werden sollten, kann man ableiten, dass das eigentliche Problem nicht die Verschachtelung ist, sondern zwei separate Aspekte, die ggf. mit verschachtelten Vorlagen auftreten können:

• Einerseits erhöht die Gesamtanzahl der verwendeten Vorlagen eines Artikels generell die Serverlast. Dieser Punkt wird hier natürlich auch bezüglich der direkt eingebundenen Vorlagen zu bedenken. Hier wäre zu verifizieren, ob die entstehende Serverbelastung noch vertretbar ist. Es wäre auch zu prüfen, ob die Belastung bei Verwendung einer gemeinsamen Datenfeldvorlage geringer ausfällt, da die Anzahl der verschiedenen in den Artikel einzubindenden Vorlagen stark sinken würde.
• Andererseits erzeugt eine Vorlage, die direkt oder indirekt in eine große Anzahl von Artikeln eingebunden wird, beim Editieren dieser Vorlage eine starke Belastungsspitze, da alle betroffenen Artikel invalidiert und beim nächsten Zugriff neu generiert werden müssen. Dies wäre hier insbesondere bei der Datenfeld- und der Trennfeld-Vorlage zu berücksichtigen, auch wenn diese keine verschachtelten Vorlagen enthalten. Hier könnte es Sinn machen, dass ein Admin diese generellen Vorlagen sperrt, um unsinnige Bearbeitungen zu vermeiden.

Wo wir verschachtelte Vorlagen meines Erachtens sinnvoll einsetzen sollten, wären die Farbeinstellungen. Die innere Vorlage würde dabei aber immer nur auf eine kleinere Anzahl von Artikeln angewendet und im Vergleich zu den Datenfeldern wird hier die Gesamtzahl an Vorlagenauswertungen innerhalb des Artikels nicht wesentlich erhöht. Es wäre sicher mit umständlicherem Artikelquellcode eine nicht verschachtelte Lösung möglich, die aber bezüglich Zahl der Vorlagen je Artikel und Zahl der Artikel je Vorlage keine Reduktion bringen und somit sinnlos wäre.

Nach meinem Empfinden sollte man das Problem der verschachtelten Vorlagen auch nicht überbewerten. Zum Vergleich basieren praktisch alle Navileisten auf verschachtelten Templates und bisher sind die inneren Vorlagen dazu nicht gesperrt. Die Stub-Vorlage wird in tausende Artikel eingebunden und wird dann auch noch monatlich verändert.-- StefanL 02:33, 22. Dez 2005 (CET)

Hi. Ich bin zwar nicht direkt für die Datenbanken zuständig (Jamesday hat da eindeutig mehr Ahnung), aber das Problem mit den Infoboxen ist weniger das Darstellen (wird alles gecached); das bleibt unkritisch, solange wir genug Slave-Server kaufen können, um die steigende Zahl von Anfragen zu kompensieren. Das Problem ist wohl eher, dass mit jedem Edit einer oft gebrauchten Vorlage hunderte oder tausende Seitencaches invalidiert werden müssen. Das sind einige Schreibzugriffe, und es kann pro Sprache maximal einen (1!) Datenbank-Server geben, über den alle Schreibzugriffe laufen. Diese müssen dann von den anderen Datenbank-Servern synchronisiert werden, was die wiederum Zeit kostet, was wiederum die Darstellung von Seiten verlangsamt...

Kurz gesagt: Infoboxen ja, aber nicht übertreiben, und Abhängigkeiten wenn möglich vermeiden, besonders bei häufig gebrauchten Boxen. --Magnus Manske 17:25, 31. Dez 2005 (CET) von meiner dis hierher verschoben greetz vanGore 16:03, 1. Jan 2006 (CET)

Hi allerseist,

mhh das große böse Thema;) Ich kann leider nicht einschätzen wie groß oder wie klein die Gefahr ist, doch hoffe das man einen guten Weg findet was usability und DB-Stabilität anbelangt. Ich hoffe das wir einen Weg finden der mit einer 2-hirarchischen das Wort hab ich mir selber ausgedacht ;) Lösung leben kann. Vielleicht muss man, wenn das ganze zu große Formen annimmt über eine echte php-whatever-sotwaretechnsiche Lösung nachdenken. Ich würde die Idee nur zu ungern sterben lassen; wenn die vertemplatung wirklich die DB in die Knie zwingt, dann bin ich auch für einen Rückzug, aber ists nicht wert das trotzdem auszuprobieren? greetz vanGore 01:06, 14. Jan 2006 (CET)

von verschoben greetz vanGore 00:14, 1. Feb 2006 (CET)