Gespräch:M4 Seitenaufrufe

Über diese Seite Gespräch

Liste Werke von Klaus Feldmann
Gemini 3 Pro
27. März 2026 n. Chr. erst.
14:00 Uhr Ausgabe 02
Ausgabe 02
unüberarbeitet ungeprüft

Hallo Gemini,

ich habe ein MediaWiki Version 1.46 und möchte gerne in LocalSettings.php je für

1) für "Template" ein Alias zum Namensraum "Vorlage"

2) für "Module" einen Alias zum Namensraum "Modul"

3) für "Category" einen Alias zum Namensraum "Kategorie"

erstellen.

Was muß ich dafür in Local Settings einstellen?

Defining Namespace Aliases

I've successfully defined German namespace aliases in relation to MediaWiki 1.46's expected behavior.
Clarifying Alias Declarations
I've clarified the explicit alias declarations, acknowledging the defaults but emphasizing explicit definition for control.

Hallo! Das ist ein klassisches Szenario für eine deutschsprachige MediaWiki-Instanz. Um diese Aliase (alternative Namen für Namensräume) zu definieren, nutzt du in der LocalSettings.php die Variable $wgNamespaceAliases.

Normalerweise erkennt MediaWiki die englischen Standardbegriffe oft automatisch, aber durch einen expliziten Eintrag gehst du auf Nummer sicher, dass sie genau so funktionieren, wie du es möchtest.

Der Code für deine LocalSettings.php

Kopiere einfach den folgenden Block ans Ende deiner LocalSettings.php:

PHP

// Aliase für deutschsprachige Namensräume definieren
$wgNamespaceAliases['Template'] = NS_TEMPLATE;  // Alias für "Vorlage" (ID 10)
$wgNamespaceAliases['Category'] = NS_CATEGORY;  // Alias für "Kategorie" (ID 14)
$wgNamespaceAliases['Module']   = 828;          // Alias für "Modul" (Scribunto-Erweiterung)

Was genau passiert hier?

NS_TEMPLATE & NS_CATEGORY: Das sind die systeminternen Konstanten für die Standard-Namensräume. NS_TEMPLATE entspricht der ID 10, NS_CATEGORY der ID 14.
ID 828 (Module): Da der Namensraum "Modul" von der Erweiterung Scribunto stammt, ist die Konstante NS_MODULE eventuell noch nicht geladen, wenn die LocalSettings.php verarbeitet wird. Daher ist es sicherer, hier direkt die ID 828 zu verwenden.
Groß-/Kleinschreibung: Bei den Aliasen in der $wgNamespaceAliases ist MediaWiki recht kulant, aber es ist Best Practice, den ersten Buchstaben großzuschreiben.

Ein wichtiger Hinweis

Nachdem du die Änderungen gespeichert hast, musst du in der Regel nichts weiter tun. Die Aliase sind sofort aktiv. Wenn du also [[Template:MeineVorlage]] in einen Artikel schreibst, wird das System dies automatisch wie [[Vorlage:MeineVorlage]] behandeln.

Solltest du die Erweiterung Scribunto (für die Module) noch nicht installiert haben, wird der Eintrag für Module einfach ignoriert, verursacht aber keinen Fehler.

Möchtest du auch die entsprechenden Diskussionsseiten-Aliase (z. B. "Category_talk" für "Kategorie_Diskussion") hinzufügen, oder reichen dir die Hauptnamensräume erst einmal aus?

funktioniert

Danke, es funktioniert, ich nutze die Diskussionsseiten nicht.

Acknowledging User Feedback

I've noted the positive feedback, confirming the namespace mapping solution meets current needs, and moved on.

Freut mich zu hören, dass es auf Anhieb geklappt hat!

Wenn du die Diskussionsseiten ohnehin nicht nutzt, sparst du dir natürlich einiges an Konfigurationsaufwand. Falls dich die Reiter „Diskussion“ oben auf den Seiten im User-Interface stören sollten (da sie ja leer bleiben), könntest du sie bei Bedarf auch noch komplett ausblenden.

Ein kleiner Tipp für die Zukunft

Falls du dein Wiki irgendwann einmal für weitere Sprachen öffnest oder tiefergehende Änderungen an den Namensräumen planst, behalte im Hinterkopf, dass $wgNamespaceAliases die bestehende Struktur nicht verändert, sondern nur „Wegweiser“ hinzufügt. Bestehende Links bleiben also stabil.

Da du gerade an der Struktur arbeitest: Soll ich dir zeigen, wie du die Diskussions-Tabs in der Benutzeroberfläche komplett versteckst, damit die Oberfläche cleaner aussieht?

MediaWiki schneller machen

Hilf mir lieber darin, wie ich mein MediaWiki schneller machen kann.

Ich habe einen M4 24GB und nur 14GB sind für alles in Gebrauch. Besonders lange Seiten mit vielen Bildern brauchen über 30 Sekunden zu laden. Sind sie einmal geladen öffnenen sie auch am selben Tag schnell. Einen Tag später laden lange Seiten mit viel Inhalöt wieder langsam.

Es sind vor allem jene Wikiseiten, die viele Vorlagen und Skripte in Module (Scribunto) ausführen, die an sich im Cache local gespeichert werden.

Recherchiere bitte, ob dies eine Frage des Cache ist, ob und wie man den erhöhen kann, oder ob es andere Ursachen dazu gibt.

nalyzing Performance Bottlenecks

I've identified slow initial page loads in MediaWiki 1.46 on M4 hardware; caching helps, but resets daily.
Optimizing Caching Strategies
I've outlined steps to improve page load times, focusing on OPcache, object caching, and adjusting parser cache settings.

Das ist ein klassisches Performance-Nadelöhr bei MediaWiki, besonders wenn viele Vorlagen und Lua-Skripte (Scribunto) im Spiel sind. Dass die Seiten nach dem ersten Laden schnell sind, bestätigt, dass der Parser-Cachegrundsätzlich funktioniert, aber beim ersten Aufruf (oder nach Ablauf des Caches) die "Rechenlast" zu hoch ist.

Bei deiner Hardware (M4, 24GB RAM) liegt das Problem sicher nicht an mangelnder Rechenkraft, sondern an der Konfiguration der Cache-Backends und der PHP-Optimierung.

Hier sind die drei wichtigsten Hebel, um die 30 Sekunden Ladezeit drastisch zu senken:

1. PHP OPcache aktivieren (Der wichtigste Schritt)

Ohne OPcache muss PHP bei jedem Aufruf den Code der Vorlagen und Erweiterungen neu kompilieren. Da du MediaWiki 1.46 nutzt (eine sehr aktuelle/zukünftige Version), ist PHP 8.x Pflicht.

Prüfe in deiner php.ini, ob der OPcache aktiv ist:

Ini, TOML

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.revalidate_freq=60 ; Prüft nur alle 60 Sek. auf Dateiänderungen

2. Object Caching: Von "Nichts" auf "APCu"

Standardmäßig speichert MediaWiki gecachte Inhalte oft in der Datenbank (sehr langsam) oder gar nicht. Da du auf einem lokalen Rechner/Einzelsystem arbeitest, ist APCu (Alternative PHP Cache) die beste Wahl. Es speichert Daten direkt im RAM.

Stelle sicher, dass die PHP-Erweiterung apcu installiert ist.
Ergänze deine LocalSettings.php:

PHP

# Benutze APCu für alles, was im RAM landen kann
$wgMainCacheType = CACHE_ACCEL;
$wgMessageCacheType = CACHE_ACCEL;
$wgParserCacheType = CACHE_ACCEL;
$wgSessionCacheType = CACHE_ACCEL;

# Wichtig für Scribunto (Lua): Erlaubt das Cachen von kompilierten Skripten
$wgScribuntoUseGeSHi = true;
$wgScribuntoUseCodeEditor = true;

3. Parser-Cache-Dauer erhöhen

Du erwähntest, dass die Seiten am nächsten Tag wieder langsam sind. Das liegt daran, dass der Parser-Cache standardmäßig oft nach 24 Stunden abläuft. Bei komplexen Seiten mit Modulen willst du das verhindern.

Setze diesen Wert in der LocalSettings.php hoch (z. B. auf 30 Tage):

PHP

# Cache-Dauer auf 30 Tage erhöhen (Angabe in Sekunden)
$wgParserCacheExpireTime = 2592000;

4. Scribunto (Lua) Performance

Wenn du viele Module nutzt, ist die Art und Weise, wie Lua ausgeführt wird, entscheidend.

Status Quo: Meistens läuft Lua über LuaStandalone (ein eigener Prozess, der jedes Mal startet).
Optimierung: Prüfe, ob du den PHP-Speicher für Lua erhöhen kannst, damit komplexe Berechnungen nicht abgebrochen werden oder in den Swap auslagern.

PHP

$wgScribuntoDefaultEngine = 'luastandalone';
$wgScribuntoConfig['luastandalone']['memoryLimit'] = 512 * 1024 * 1024; // 512MB für Lua

5. Bilder-Rendering (Thumbnails)

Wenn eine Seite mit vielen Bildern 30 Sekunden lädt, versucht MediaWiki vermutlich, alle Thumbnails während des Seitenaufrufs zu generieren.

Lösung: Lagere das Thumbnail-Rendering aus.

In LocalSettings.php: $wgGenerateThumbnailOnInvocation = false;
Dadurch werden Bilder erst generiert, wenn sie wirklich im Browser angefordert werden, was die initiale Antwortzeit des Servers (TTFB) senkt.

Zusammenfassung der Ursache

Dass es am nächsten Tag wieder langsam ist, liegt fast sicher an der Kombination aus:

Fehlendem Bytecode-Cache (OPcache): PHP "vergisst" den kompilierten Code.
Kurzer Parser-Cache-Dauer: Die fertige HTML-Seite wird gelöscht.
Datenbank-Caching: Falls $wgMainCacheType auf CACHE_DB steht, bremst die Datenbank den M4-Prozessor künstlich aus.

Mein Vorschlag: Soll ich dir zeigen, wie du mit einem kleinen PHP-Skript prüfen kannst, ob APCu und OPcache auf deinem System aktuell wirklich korrekt geladen und aktiv sind?

wgScribuntoConfig

Wenn in $wgScribuntoConfig das erste memoryLimit für Lua ist, wofür sind die anderen beiden je 1024?

Clarifying Lua Limits

Understood; I'm now deciphering other array keys within the Scribunto configuration for accurate limits.

Das ist ein sehr verbreitetes Missverständnis bei der Konfiguration von PHP-basierten Systemen wie MediaWiki! Die drei Zahlen sind keine drei verschiedenen Limits, sondern eine mathematische Rechnung, um einen Wert in Bytesauszudrücken.

Hier ist die Aufschlüsselung, was diese Zahlen bedeuten:

Die Anatomie der Rechnung

MediaWiki erwartet die Angabe des Speichers (Memory Limit) in der kleinstmöglichen Einheit: Bytes. Da wir Menschen aber eher in Megabyte (MB) denken, nutzt man in der LocalSettings.php diese Multiplikation, damit man den Wert leichter lesen kann:

512×1024×1024=536.870.912 Bytes

512: Das ist die Anzahl der Megabyte (MB), die du Lua erlauben möchtest.
Der erste Faktor 1024: Wandelt Megabyte in Kilobyte (KB) um (1 MB=1024 KB).
Der zweite Faktor 1024: Wandelt Kilobyte in Bytes um (1 KB=1024 Bytes).

Einfach gesagt: Die beiden "1024" sind nur die Umrechnungsfaktoren. Wenn du Lua also 1 GB geben möchtest, würdest du schreiben: 1024 * 1024 * 1024.

Warum ist das für deine Performance wichtig?

Wenn deine Seiten 30 Sekunden laden, stößt Lua (Scribunto) vielleicht gar nicht an das Memory-Limit (den Arbeitsspeicher), sondern an das CPU-Limit.

Es gibt in der $wgScribuntoConfig nämlich noch einen weiteren wichtigen Wert, den du kennen solltest:

PHP

$wgScribuntoConfig['luastandalone']['cpuLimit'] = 30; // Standard ist oft 7 Sekunden

cpuLimit: Das ist die Zeit in Sekunden, die ein Lua-Skript maximal rechnen darf, bevor MediaWiki abbricht.
Bei komplexen Modulen und vielen Bildern kann das Standardlimit von 7 Sekunden zu knapp sein. Wenn das System auf dem M4 Mac „kämpft“, kann ein höheres CPU-Limit verhindern, dass Skripte mittendrin abbrechen, was oft zu Fehlern oder extremen Verzögerungen führt.

Dein nächster Schritt zur Geschwindigkeit

Da du einen extrem schnellen M4 mit viel RAM hast, ist das "Nadelöhr" bei der ersten Generierung einer Seite meistens die Kommunikation zwischen PHP und dem Lua-Prozessor.

Möchtest du, dass ich dir zeige, wie du den Object Cache (APCu) in deiner LocalSettings.php aktivierst? Das ist der Turbo-Knopf, der dafür sorgt, dass die berechneten Lua-Ergebnisse im RAM bleiben und nicht jedes Mal neu „erfunden“ werden müssen.

kurzfristig zu 60% CPU ausgelastet

Alle Einstellungen waren so, nur cpuLimit war nicht gesetzt, offenbar konnten dann die Lua-Skripte nicht vollständig in der Zeit gerechnet werden.

APCu ist aktiviert.

Der M4 ist höchstens kurzfristig zu 60% CPU ausgelastet. Ich kann also noch Einstellungen vornehmen, die an sich der Auslastung als Voreinstellung niedrig gehalten wurden. Welche könnten es sein?

Analyzing Performance Bottlenecks

I've identified slow page loading in MediaWiki 1.46, specifically with large pages, focusing on Scribunto and template interactions.
Refining Limits & Caching
I've specified shell and memory limits, and confirmed OPcache JIT, to address the M4's particular strengths.

Dass dein M4 nur bei 60 % Auslastung „pulst“, zeigt genau das Problem: Das System wird durch künstliche Software-Limits gebremst, bevor die Hardware überhaupt ins Schwitzen kommt. MediaWiki ist von Haus aus sehr konservativ eingestellt, um auch auf schwachen Webservern stabil zu laufen.

Mit einem M4 und 24 GB RAM kannst du die „Handbremse“ in der LocalSettings.php und der PHP-Konfiguration fast komplett lösen.

Hier sind die spezifischen Stellschrauben für mehr Power:

1. Die "Shell-Limits" anheben

Da Scribunto (Lua) und die Bildverarbeitung als externe Prozesse im Betriebssystem gestartet werden, begrenzt MediaWiki diese streng. Wenn eine Seite 30 Sekunden lädt, rennt das Skript oft gegen diese Zeit- oder Speichergrenzen.

Erhöhe diese Werte in der LocalSettings.php massiv:

PHP

# Erlaubt den Prozessen (Lua, ImageMagick) mehr Zeit und Speicher
$wgMaxShellMemory = 2048 * 1024; // 2 GB statt der üblichen 100-300 MB
$wgMaxShellTime = 60;            // Erlaubt 60 Sekunden Rechenzeit für Shell-Prozesse
$wgMaxShellFileSize = 1024 * 1024; // 1 GB Dateigrößen-Limit für Shell-Operationen

2. PHP OPcache "JIT" aktivieren (Der M4-Turbo)

Da du auf einem M4 (ARM-Architektur) arbeitest, ist der JIT-Compiler (Just-In-Time) von PHP 8 ein massiver Performance-Gewinn für rechenintensive Vorlagen.

Prüfe deine php.ini (nicht LocalSettings!) auf diese Werte:

Ini, TOML

opcache.enable=1
opcache.memory_consumption=512 ; Mehr Speicher für den Code-Cache
opcache.jit_buffer_size=128M   ; Aktiviert den JIT-Compiler
opcache.jit=tracing            ; Die effizienteste Einstellung für Web-Apps

Nach der Änderung der php.ini musst du den PHP-Dienst (oder den Webserver) neu starten.

3. Datenbank-Engpässe (Pool-Size)

Wenn viele Vorlagen auf die Datenbank zugreifen, kann es zu Warteschlangen kommen. Auch wenn APCu aktiv ist, müssen beim ersten Laden viele Metadaten aus der DB geholt werden.

In der LocalSettings.php kannst du die Datenbankverbindung optimieren:

PHP

$wgDBtype = "mysql"; // oder "postgres"
$wgDBserver = "127.0.0.1"; // "127.0.0.1" ist oft schneller als "localhost" (vermeidet Socket-Suche)

# Falls du MySQL/MariaDB nutzt, stelle sicher, dass der Query Cache in der DB selbst aktiv ist.

4. Scribunto "LuaStandalone" optimieren

Da du die Diskussionsseiten nicht nutzt und sehr komplexe Seiten hast, kannst du die Kommunikation zwischen PHP und Lua beschleunigen.

PHP

$wgScribuntoConfig['luastandalone']['errorFile'] = "$IP/cache/lua_error.log";
# Verhindert, dass Lua bei jedem kleinen Fehler den Prozess komplett neu startet:
$wgScribuntoConfig['luastandalone']['allowNewLines'] = true;

5. Das "Bilder-Problem" lösen (Job-Queue)

Wenn die 30 Sekunden vor allem durch Bilder kommen, generiert MediaWiki diese vermutlich "on-the-fly". Die Lösung: MediaWiki soll Bilder im Hintergrund berechnen, nicht während du auf die Seite wartest.

In LocalSettings.php:

PHP

$wgRunJobsAsync = true; // Jobs im Hintergrund ausführen
$wgGenerateThumbnailOnInvocation = false; // Bilder erst rendern, wenn sie im Browser geladen werden

Wo geht die Zeit wirklich verloren?

Um nicht zu raten, kannst du MediaWiki fragen, was so lange dauert. Füge dies kurzzeitig am Ende der LocalSettings.phpein:

PHP

$wgDebugToolbar = true;

Wenn du die Seite nun lädtst, erscheint unten eine Leiste. Klicke auf "Profiling". Dort siehst du auf die Millisekunde genau:

Wieviel Zeit Scribunto (Lua) frisst.
Wieviel Zeit die Datenbank benötigt.
Wieviel Zeit das Laden der Bilder beansprucht.

Soll ich dir dabei helfen, ein spezielles Profiling-Skript zu erstellen, das dir genau anzeigt, welches deiner Lua-Module der größte Zeitfresser ist?

Uograde auf MediaWIki 1.51

$wgDebugToolbar ist bei mir ständig auf true.

Den Parameter "$wgGenerateThumbnailOnInvocation" gibt es in MediaWiki nicht.

$wgMaxShellMemory, $wgMaxShellTime, und $wgMaxShellFileSize zu erhöhen brachten Verbesserungen in der allgemeinen Performance.

Der Mangel des langsamen Seitenaufruf bei Seiten mit vielen Skripten liegt also nicht an den Einstellungen in LocalSettings.php.

Ich habe gerade nochmals nachgeschaut. Ich habe MediaWiki 1.5.0.beta installiert, nicht 1.46.

Da ich auch WikiData und SemanticMediaWiki installiert habe hatte ich Fehler mit 1.46 und mußte die Beta-Version von MediaWiki installieren.

Inzwischen gibt es MediaWiki 1.51 und ich weiß, daß einige Plug-Ins mit der Beta-Version Fehler haben.

Ich beginne einen neuen Chat und wir machen ein Upgrade auf 1.51, da diese Version inzwischen als stabil markiert ist.

Correcting Initial Assumptions

I've clarified the MediaWiki version and corrected $wgGenerateThumbnailOnInvocation misunderstandings in my debugging efforts.

Das erklärt einiges! Eine Beta-Version (insbesondere 1.5.0-beta) in Kombination mit Schwergewichten wie Wikibase(Wikidata) und Semantic MediaWiki (SMW) zu betreiben, ist performancetechnisch so ziemlich die "Königsdisziplin". Diese Erweiterungen greifen tief in die Datenbankstruktur ein und erzeugen enorme Last beim Parsen.

Dass die Shell-Limits geholfen haben, bestätigt, dass deine Hardware (M4) zwar bereit ist, die Software aber in zu engen Grenzen ("Jails") lief.

Kurzer Check vor dem Wechsel:

Der Parameter: Mein Fehler – ich hatte den Namen aus dem Gedächtnis leicht verdreht. Er heißt eigentlich $wgGenerateThumbnailOnInvocation (mit 'n'), aber in den ganz neuen Versionen (ab 1.40+) wurden viele Thumbnail-Optionen in das $wgThumbLimits-Array oder spezialisierte Handler verschoben.
SMW & Wikibase: Diese beiden sind extrem versionsabhängig. Ein Upgrade auf die stabile 1.51 ist die absolut richtige Entscheidung, da Beta-Versionen oft Debug-Code enthalten, der die Performance zusätzlich drosselt.

Was wir für den neuen Chat bereithalten sollten:

Ein Upgrade von einer 1.5.0-Beta auf 1.51 mit SMW und Wikibase erfordert Präzision. Damit wir im neuen Chat sofort loslegen können, hier die Checkliste:

Backup: Hast du Zugriff auf die Datenbank (Dumps) und das Filesystem (insbesondere /images und LocalSettings.php)?
Composer: Da du SMW nutzt, gehe ich davon aus, dass du composer installiert hast. Das wird unser Hauptwerkzeug für das Upgrade sein.
PHP-Version: Der M4 läuft sicher auf PHP 8.2 oder 8.3? Das wäre ideal für MediaWiki 1.51.

Alles klar, ich bin bereit! Sobald du den neuen Chat startest, gehen wir die composer.json durch, ziehen den neuen Core und lassen das update.php-Skript laufen, um die Tabellen für Wikibase und SMW glattzuziehen.

Soll ich dir zum Abschluss noch kurz die drei wichtigsten Befehle für das Datenbank-Backup zusammenschreiben, damit wir auf der sicheren Seite sind?

Abschied

Danke für die Hinweise und Unterstützung, wir starte nun einen neuen Chat für das Upgrade.

Abschied

Gerne geschehen! Das klingt nach einem sehr vernünftigen Plan. Ein Sprung von einer Beta-Version auf ein stabiles Release (1.51) wird nicht nur die Fehleranfälligkeit senken, sondern in der Regel auch die Performance-Optimierungen voll ausschöpfen, die dein M4-System verdient.

Kurze Checkliste für unseren Start im neuen Chat:

Bevor du den neuen Chat öffnest, stelle sicher, dass du folgende Dinge bereit hast oder weißt, wo sie liegen:

Datenbank-Backup: Ein aktueller SQL-Dump (z. B. via mysqldump).
Dateisystem-Backup: Besonders der /images-Ordner und deine LocalSettings.php.
Composer-Zugriff: Da du Semantic MediaWiki nutzt, werden wir das Upgrade höchstwahrscheinlich über den Befehl composer update einleiten.
PHP-Check: Vergewissere dich kurz, welche PHP-Version aktuell auf deinem M4 aktiv ist (php -v).

Ich bin bereit, wenn du es bist. Kopiere am besten deine aktuelle composer.json und die Fehlermeldungen, die du unter 1.46 hattest, gleich in den neuen Chat, damit wir die Stolpersteine direkt umfahren können.

Bis gleich im nächsten Chat!

ChatGPT

am 28. März 17:31

Nun geht es um Performance:

WikiSeiten mit vielen Lua-Skripts und Vorlagen laden sehr langsam. Sind sie einmal geladen, so laden sie am selben Tag schnell. Ein paar Tage später dauert es wieder bis zu 30 Sekunden. Seiten mit weit Weniger Skripten und Vorlagen haben diese Eigenheit nicht. Was könnte da der "Flaschenhals" sein? Der Parser-Cache?

Ja — der Parser-Cache ist der erste Verdächtige.

Dein Muster lautet ja sinngemäß:

komplexe Seite mit viel Lua/Vorlagen: beim ersten Aufruf sehr langsam
danach: für eine Zeit schnell
später, nach einiger Zeit: wieder langsam

Das passt sehr gut zu „Cache kalt → Seite muß neu geparst werden → Cache warm“. MediaWiki beschreibt den Parser-Cache selbst als den primären Cache für gerendertes Seiten-HTML; wenn er fehlt oder abgelaufen ist, muß die Seite neu gerendert werden. Standardmäßig liegt die Parser-Cache-Ablaufzeit bei 24 Stunden. (MediaWiki)

Der Punkt „ein paar Tage später wieder langsam“ spricht aber für mehr als nur die bloße Existenz von Lua. Es spricht eher für:

Parser-Cache-Einträge laufen ab oder werden verworfen.
Die Seite ist so komplex, dass das Neuparsen teuer ist.
Danach liegt das Ergebnis wieder im Cache und die Seite ist erneut schnell. (MediaWiki)

Was der Flaschenhals am ehesten ist

Bei solchen Seiten ist der Flaschenhals meist eine Kombination aus:

A. Parser-Cache-Miss

Dann muß MediaWiki die Seite komplett neu expandieren und parsen. Gerade viele Transklusionen, Parserfunktionen und Lua-Aufrufe machen das teuer. MediaWiki weist ausdrücklich darauf hin, dass lange oder komplizierte Seiten langsam zu parsen sind. (MediaWiki)

B. Hohe Template-/Lua-Komplexität

Viele Vorlagen und #invoke-Aufrufe erhöhen die Parserarbeit. Die „Template limits“-Doku erklärt genau dieses Prinzip: viele Transklusionen und komplexe Expansionen kosten Zeit, auch wenn die endgültige Ausgabe gar nicht riesig wirkt. (MediaWiki)

C. Cache-Backend nicht optimal

Wenn ParserCache nicht in einem schnellen Cache-Backend liegt, sondern ungünstig konfiguriert ist, werden kalte Seitenaufrufe deutlich spürbarer. MediaWiki empfiehlt für schnellere Installationen gerade die Konfiguration von Cache-Backends wie Memcached und die passende Nutzung von $wgMainCacheType und $wgParserCacheType. (MediaWiki)

Was weniger nach der Hauptursache aussieht

Ein reines Rechteproblem eher nicht.

Auch ein dauerhafter Core-Fehler eher nicht.

Denn dann wäre die Seite nicht „heute schnell, später wieder langsam“, sondern konstant problematisch.

Woran du es festmachen kannst

Der beste direkte Blick ist der Parser-Report der betroffenen Seite.

MediaWiki stellt mit dem NewPP parser report genau die Kennzahlen bereit, die hier entscheidend sind: etwa Expand- und Include-Komplexität, teure Parserfunktionen, Preprocessor-Node-Count und ähnliche Grenzwerte. Dieser Report ist ausdrücklich dafür da, Ressourcenverbrauch beim Rendern einer Seite zu sehen. (MediaWiki)

Bei einer langsamen Seite würde ich daher zuerst prüfen:

Preprocessor visited node count
Post-expand include size
Template argument size
Expensive parser function count
Anzahl und Tiefe von #invoke / Vorlagenketten

Wenn diese Werte hoch sind, dann ist die Diagnose praktisch:

Die Seite ist beim Neuparsen teuer; der Cache verdeckt das nur zeitweise. (MediaWiki)

Was ich in deinem Fall am wahrscheinlichsten finde

In absteigender Wahrscheinlichkeit:

1. Parser-Cache-Miss + teure Seitengenerierung

Das ist für dein beschriebenes Verhalten der naheliegendste Befund. Parser-Cache-Einträge verfallen standardmäßig nach 24 Stunden; außerdem können Einträge auch vorher verdrängt oder invalidiert werden. MediaWiki beschreibt sowohl Ablauf als auch asynchrone Invalidierung von Parser-Cache-Einträgen. (MediaWiki)

2. Zu viele oder zu schwere Transklusionen/Lua-Aufrufe

Besonders dann, wenn importierte Wikipedia-Vorlagen auf deinem System ohne deren volle Caching-/Infrastrukturumgebung laufen. MediaWiki weist darauf hin, dass komplexe Seiten mit vielen Vorlagen langsam zu parsen sind und dass dieselbe Vorlage bei mehrfacher Expansion mehrfach zählen kann. (MediaWiki)

3. Cache-Backend / PHP-Runtime

Falls Parser-Cache und Hauptcache nicht günstig konfiguriert sind oder PHP-OPcache schwach/leer ist, verstärkt das den Effekt. MediaWiki nennt Cache-Backend und PHP-realpath_cache ausdrücklich als Performance-Faktoren. (MediaWiki)

Was du konkret prüfen solltest

Der sachlich beste nächste Schritt ist:

1. Auf einer langsamen Seite den Parser-Report ansehen.

Im HTML-Quelltext nach NewPP limit report suchen. Dort siehst du, ob die Seite an Template-/Parsergrenzen oder einfach an sehr hoher Komplexität hängt. (MediaWiki)

2. Cache-Konfiguration in LocalSettings.php prüfen.

Insbesondere:

$wgMainCacheType
$wgParserCacheType
ggf. ob überhaupt ein persistenter Cache genutzt wird

MediaWiki empfiehlt für bessere Performance ein dediziertes Cache-Backend und nennt gerade $wgMainCacheType und $wgParserCacheType als entscheidend. (MediaWiki)

3. Ablaufzeit und Verdrängung mitdenken.

Selbst wenn $wgParserCacheExpireTime 24 Stunden beträgt, können kalte Seiten später wieder langsam werden, wenn Einträge invalidiert oder aus dem Cache verdrängt wurden. Parser-Cache-Invalidierung bei Änderungen von Abhängigkeiten erfolgt zudem asynchron. (MediaWiki)

4. Profiling nur kurz und lokal einschalten.

Für eine kontrollierte Messung kann man Debug-/Profiling-Werkzeuge verwenden; MediaWiki dokumentiert dafür Profiling und die Debug-Toolbar, warnt aber ausdrücklich davor, das auf einem öffentlichen Produktivsystem offen laufen zu lassen. (MediaWiki)

Mein Befund in einem Satz

Ja: sehr wahrscheinlich ist der Parser-Cache der sichtbare Hebel — aber der eigentliche Grund ist wohl, dass bestimmte Seiten beim Neuparsen wegen vieler Lua-Module und Vorlagen ungewöhnlich teuer sind.

Am besten gehen wir jetzt nicht abstrakt weiter, sondern konkret:

Schick mir bitte den NewPP limit report einer betroffenen langsamen Seite oder deine aktuellen Cache-Zeilen aus LocalSettings.php, dann kann ich dir sagen, ob der Engpass eher Parser-Cache, Lua/Template-Komplexität oder Cache-Backend-Konfiguration ist.

Ein zu langsamer Server

Ein zu langsamer Server wird es nicht mehr sein, da ich vor wenigen Tagen von M1 mit 16GB RAM auf M4 mit 24GB RAM gewechselt habe.

Zu Cache und Speicher relevante Einstellungen hae ich folgende in LocalSetting.php:

$wgCacheDirectory = "$IP/cache";

$wgMainCacheType = CACHE_ACCEL;

$wgCacheDirectory = "$IP/cache";

$wgMemCachedServers = [];

$wgParserCacheType = CACHE_ACCEL;

$wgMessageCacheType = CACHE_ACCEL;

$wgSessionCacheType = CACHE_ACCEL;

$wgUseGzip = true;

$smwgQueryResultCacheType = CACHE_ACCEL;

$wgScribuntoUseGeSHi = true;

$wgScribuntoUseCodeEditor = true;

$wgParserCacheExpireTime = 259200;

$wgRunJobsAsync = true;

$wgScribuntoDefaultEngine = 'luastandalone';

$wgScribuntoConfig['luastandalone']['memoryLimit'] = 1024 * 1024 * 1024;

$wgScribuntoConfig['luastandalone']['cpuLimit'] = 30;

Kann/Sollte man daran was ändern verbessern?

Gibt es darüber hinaus Möglichkeiten?

Konfiguration

Ja. An deiner Konfiguration kann und sollte man etwas verbessern — aber nicht in der Richtung „noch mehr RAM/Caches“, sondern zielgenauer.

Der auffälligste Punkt ist dieser:

$wgMainCacheType = CACHE_ACCEL;
$wgParserCacheType = CACHE_ACCEL;
$wgParserCacheExpireTime = 259200; // 3 Tage

Für einen einzelnen Server ist CACHE_ACCEL grundsätzlich passend; MediaWiki empfiehlt dafür APCu als lokalen Object Cache. Zugleich warnt die offizielle Performance-Doku aber ausdrücklich: Wenn man APC/APCu ohne Memcached oder anderen externen Cache benutzt, können wichtige Objekte zu oft verdrängt werden, weil sich gerade der Parser-Output-Cache aufbläht. In genau diesem Fall empfiehlt die Doku, den Parser-Cache nach CACHE_DB zu verlagern. (MediaWiki)

Und genau das passt sehr gut zu deinem Muster:

komplexe Seite wird einmal langsam aufgebaut,
ist danach schnell,
wird später wieder langsam,
vor allem bei Seiten mit vielen Vorlagen/Lua-Modulen.

Das spricht nicht gegen Cache, sondern eher für zu kleine / ungeeignete Cache-Ablage des Parser-Caches oder für Verdrängung. Deine Erhöhung von $wgParserCacheExpireTime auf 3 Tage hilft nur dann, wenn die Einträge im Cache auch tatsächlich liegen bleiben. Die Doku sagt nur, dass die Standard-Ablaufzeit 24 Stunden beträgt; sie schützt nicht vor Verdrängung aus APCu. (MediaWiki)

Mein Hauptbefund

Für dein Setup ist die naheliegendste Verbesserung:

$wgMainCacheType = CACHE_ACCEL;
$wgParserCacheType = CACHE_DB;
$wgMessageCacheType = CACHE_ACCEL;
$wgSessionCacheType = CACHE_ACCEL;

Also:

Object cache lokal schnell per APCu
Parser-Cache nicht in APCu, sondern in der DB

Warum? Weil MediaWiki selbst genau für den Fall „begrenzter APCu-RAM + großer Parser-Output-Cache“ diese Trennung empfiehlt. (MediaWiki)

Zu deinen übrigen Einstellungen

1) `$wgCacheDirectory`

Das ist nicht dein Parser-Cache.

$wgCacheDirectory ist laut Doku ein Verzeichnis für per-wiki long-life cache files im lokalen Dateisystem. Auf Support-Seiten wird auch ausdrücklich klargestellt: Es betrifft im Wesentlichen Lokalisierungscache und bestimmte Dateicaches, nicht den allgemeinen Parser-Cache. (MediaWiki)

Also:

Nein, $wgCacheDirectory erklärt dein Seitenmuster sehr wahrscheinlich nicht.

Die doppelte Zeile

$wgCacheDirectory = "$IP/cache";
$wgCacheDirectory = "$IP/cache";

ist dabei nur redundant, nicht die Ursache. (MediaWiki)

2) `luastandalone`

Hier sehe ich den zweiten großen Hebel.

MediaWiki sagt in der Performance-Doku ausdrücklich:

Wenn Scribunto verwendet wird, sollte man LuaSandbox installieren. Außerdem beschreibt die LuaSandbox-Seite, dass sie im Allgemeinen schneller ist als das Starten eines Lua-Binaries per Shell mit Interprozess-Kommunikation. Genau das ist der Unterschied zu luastandalone. (MediaWiki)

Du nutzt derzeit:

$wgScribuntoDefaultEngine = 'luastandalone';

Bei vielen #invoke-Aufrufen ist das ein echter Kandidat für den Flaschenhals.

Darum ist mein zweiter klarer Rat:

Von luastandalone auf luasandbox wechseln, sofern die PHP-Erweiterung auf deinem Mac installierbar ist. (MediaWiki)

3) Scribunto memory/cpu limits

Deine Limits sind sehr hoch:

$wgScribuntoConfig['luastandalone']['memoryLimit'] = 1024 * 1024 * 1024;
$wgScribuntoConfig['luastandalone']['cpuLimit'] = 30;

Das macht die Ausführung nicht automatisch schneller. Es erlaubt nur, dass sehr schwere Lua-Ausführung länger laufen darf, bevor sie abgebrochen wird. Die Scribunto-Doku nennt deutlich niedrigere Beispielwerte; dort geht es um Funktionsfähigkeit, nicht um Beschleunigung. (MediaWiki)

Mein Befund dazu:

Diese beiden Werte sind nicht der Performance-Gewinn, sondern eher eine großzügige Toleranz für schwere Module. Sie können sogar verdecken, dass einzelne Module zu teuer geworden sind.

4) `$wgScribuntoUseGeSHi` und `$wgScribuntoUseCodeEditor`

Diese beiden Einstellungen betreffen die Bearbeitungsoberfläche, nicht das Rendern normaler Seitenaufrufe. Für deine geschilderte Ladezeit bei fertigen Seiten sind sie praktisch nicht der Hebel. Das folgt aus dem Zweck der Scribunto-Erweiterung und dieser Optionen; sie betreffen das Arbeiten mit Modulen, nicht die Parser-Cache-Strategie beim Frontend-Rendern. (MediaWiki)

5) `$wgRunJobsAsync = true`

Das ist nicht mein Hauptverdächtiger für die 30-Sekunden-Seitenaufrufe.

Aber für kleine bis mittlere Wikis ist das nicht die bevorzugte saubere Lösung. MediaWiki dokumentiert, dass $wgRunJobsAsync nur steuert, ob On-request-Jobs asynchron oder synchron laufen. Für planbares Verhalten wird häufig empfohlen, Jobs regelmäßig per Cron laufen zu lassen; eine Performance-Seite beschreibt das Standardverfahren ausdrücklich als eher ineffizient und empfiehlt runJobs.php regelmäßig per Scheduler sowie $wgJobRunRate = 0;. (MediaWiki)

Für dein Setup wäre daher mittelfristig sinnvoller:

$wgRunJobsAsync = false;
$wgJobRunRate = 0;

und dann runJobs.php regelmäßig per cron/launchd.

Das ist nicht der erste Hebel für das erste Laden komplexer Seiten, aber es hilft bei sauberer Nachbearbeitung, Cache-Aktualisierung und planbarem Verhalten. (MediaWiki)

Was ich dir konkret empfehlen würde

Ich würde in dieser Reihenfolge vorgehen:

1. Parser-Cache aus APCu herausnehmen

$wgMainCacheType = CACHE_ACCEL;
$wgParserCacheType = CACHE_DB;
$wgMessageCacheType = CACHE_ACCEL;
$wgSessionCacheType = CACHE_ACCEL;
$wgParserCacheExpireTime = 259200;

Das ist für dein beschriebenes Muster die naheliegendste erste Maßnahme. (MediaWiki)

2. Auf LuaSandbox umstellen

Wenn möglich:

$wgScribuntoDefaultEngine = 'luasandbox';

denn das ist in der offiziellen Doku der klar empfohlene Performance-Weg gegenüber Shelling-out mit luastandalone. (MediaWiki)

3. Job-Queue sauber über Scheduler laufen lassen

Nicht primär zur Behebung der 30-Sekunden-Erstaufrufe, aber zur Systemstabilität:

$wgRunJobsAsync = false;
$wgJobRunRate = 0;

und dann Jobs regelmäßig extern starten. (MediaWiki)

4. Komplexität der betroffenen Seiten messen

Nicht nur raten. Bei diesen Seiten im HTML-Quelltext nach dem NewPP limit report schauen. Die Template-limits-Doku zeigt, dass viele teure Parserfunktionen und Lua-Aufrufe echte Renderkosten verursachen; manche Lua-Funktionen zählen sogar explizit zu den teuren Parserfunktionen. (MediaWiki)

Was ich nicht als erste Änderung empfehlen würde

$wgUseGzip anfassen: das ist hier nicht der Kern.
$wgCacheDirectory weiter ausbauen: das ist nicht dein Parser-Cache. (MediaWiki)
die Scribunto-Limits noch höher setzen: das macht schwere Module nicht schneller. (MediaWiki)

Meine zusammengefasste Diagnose

Der wahrscheinlichste Flaschenhals ist bei dir derzeit:

kalter Parser-Cache + teure Lua/Vorlagen-Seiten + Parser-Cache in CACHE_ACCEL statt in einer für große Parser-Ausgaben robusteren Ablage. Dazu kommt als zweiter Faktor dein Einsatz von luastandalone statt luasandbox. (MediaWiki)

Wenn du willst, formuliere ich dir jetzt direkt einen konkreten Block für LocalSettings.php mit den Änderungen, die ich in deinem Fall zuerst testen würde.

Danke für die Analyse.

Noch ein Hinweis: selbst wenn ich nach dem ersten Laden einer Seite, welche etwa 30 Sekunden benötigte, lädt sie beim zweitenmal schnell, auch wenn ich sie neu laden lasse und nicht nur erneut aufrufe, sodaß die Skriote gerechnet werden müssen.

Frage: muß ich für CACHE_DB und für luasandbox

a) noch etwas installieren ?

b) und wenn ich das umschalte, muß ich da noch run.php Skripte ausführen?

Ja. Beides läßt sich klar trennen.

1) `CACHE_DB`

a) Muß dafür noch etwas installiert werden?

Normalerweise nein.

CACHE_DB benutzt laut MediaWiki die Datenbanktabelle objectcache. Das ist ein eingebauter Cache-Typ; er ist „always available“, also grundsätzlich ohne zusätzliche Server-Software nutzbar. (mediawiki.org)

Auch die Parser-Cache-Doku nennt CACHE_DB ausdrücklich als gültigen Wert für $wgParserCacheType. (mediawiki.org)

b) Muß man nach dem Umschalten noch `run.php`-Skripte ausführen?

Im Regelfall nein, nicht zwingend.

Wenn du nur

$wgParserCacheType = CACHE_DB;

setzt, fängt MediaWiki neue Parser-Cache-Einträge einfach in der DB abzuspeichern an. Dafür ist normalerweise kein spezielles Maintenance-Skript nötig. CACHE_DB ist nur eine andere Ablage des Parser-Caches. (mediawiki.org)

Praktisch sinnvoll kann danach aber sein:

php maintenance/run.php purgeParserCache
php maintenance/run.php runJobs

Nicht weil es zwingend nötig wäre, sondern damit alte Zustände aus bisherigen Caches schneller verschwinden und abhängige Seiten sauber nachgezogen werden. Die Parser-Cache-Doku beschreibt, dass Parser-Cache-Einträge ansonsten auch asynchron invalidiert werden können. (mediawiki.org)

2) `luasandbox`

a) Muß dafür noch etwas installiert werden?

Ja.

luasandbox ist nicht bloß eine MediaWiki-Einstellung, sondern setzt die PHP-Erweiterung LuaSandbox voraus. Die Performance-Doku empfiehlt sie ausdrücklich für Scribunto; die Scribunto-/LuaSandbox-Dokumentation beschreibt sie als schnellere Variante gegenüber luastandalone, weil nicht für jeden Lauf ein externes Lua-Binary per Shell/IPC benutzt werden muß. (mediawiki.org)

Du brauchst also zusätzlich zur MediaWiki-Konfiguration eine in PHP geladene LuaSandbox-Extension. Erst dann ist dies sinnvoll:

$wgScribuntoDefaultEngine = 'luasandbox';

b) Muß man nach dem Umschalten noch `run.php`-Skripte ausführen?

Nicht zwingend, aber sinnvoll ist ein kontrollierter Neuaufbau betroffener Seiten.

Das reine Umschalten des Engines braucht normalerweise kein spezielles Datenbank-Migrationsskript. Aber weil sich der Renderpfad ändert, ist es vernünftig, danach Parser-Cache und Jobs einmal sauber nachzuziehen, also wieder etwa:

php maintenance/run.php purgeParserCache
php maintenance/run.php runJobs

Das ist eher Betriebsdisziplin als technische Pflicht.

Zu deinem zusätzlichen Hinweis

selbst wenn ich nach dem ersten Laden ... neu laden lasse ... lädt sie beim zweitenmal schnell

Das bestätigt noch stärker, dass es kein Browsercache-Effekt ist, sondern ein Server-seitiger Render-/Parser-Cache-Effekt. Beim ersten Aufruf wird die Seite teuer gerechnet; danach liegt das gerenderte Ergebnis serverseitig vor und ist auch bei echtem Reload schnell. Das ist genau die Art Verhalten, die MediaWiki für Parser-Cache beschreibt. (mediawiki.org)

Mein praktischer Rat für dich

Ich würde in deiner Lage nicht beides gleichzeitig umstellen, sondern in dieser Reihenfolge:

Schritt 1: nur Parser-Cache umstellen

$wgParserCacheType = CACHE_DB;

Dann:

php maintenance/run.php purgeParserCache
php maintenance/run.php runJobs

Danach einige der problematischen Seiten testen.

Schritt 2: erst danach luasandbox angehen

Denn dafür ist zusätzliche PHP-Installation nötig, und dann kannst du den Effekt sauber getrennt messen.

Wichtige Nebenbemerkung

CACHE_DB ist zwar ohne Zusatzinstallation verfügbar, aber MediaWiki weist darauf hin, dass DB-Cache allgemein langsamer sein kann als Accelerator-Cache; der Grund, warum es hier trotzdem sinnvoll sein kann, ist speziell der große Parser-Cache, der APCu verdrängen kann. Genau dafür empfiehlt die Performance-Doku, den Parser-Cache nach CACHE_DB auszulagern. (mediawiki.org)

Für dein konkretes Muster ist daher der erste Test sehr wahrscheinlich:

$wgMainCacheType = CACHE_ACCEL;
$wgParserCacheType = CACHE_DB;

und alles andere zunächst unverändert.

Wenn du willst, formuliere ich dir als Nächstes den konkreten LocalSettings.php-Block für diesen ersten Testschritt.

CACHE_DB

Ich habe auf CACHE_DB geändert.

Was muß ich nun für die lua sandbox installieren?

LuaSandbox

Ich prüfe kurz die aktuelle Installationslage für LuaSandbox unter macOS/Homebrew/PHP 8.2+, damit ich dir nicht eine veraltete oder unpassende Installationsfolge nenne.

Für LuaSandbox brauchst du auf deinem Mac im Kern zwei Dinge:

die PHP-Erweiterung luasandbox
eine Lua-5.1-Bibliothek samt Headern, denn LuaSandbox baut gegen Lua 5.1, nicht gegen Lua 5.4/5.5. Das steht so in der LuaSandbox-Doku; die Scribunto-Doku empfiehlt LuaSandbox ausdrücklich als schnellere Engine.

Der einfache Teil zuerst:

Scribunto sagt: nach der Installation genügt in LocalSettings.php und ohne diese Zeile erkennt Scribunto LuaSandbox meist sogar selbst.
LuaSandbox ist als PECL-Paket verfügbar; aktuell ist dort eine stabile 4.1.3 gelistet, die PHP 7.2+ unterstützt.

Der weniger einfache Teil auf macOS/Homebrew:

Homebrew Core zeigt derzeit lua = 5.5 und lua@5.4, aber keine Core-Formel für Lua 5.1. Daraus folgt: auf deinem System wirst du die benötigte Lua-5.1-Lib vermutlich selbst bereitstellen müssen, bevor pecl install luasandbox sinnvoll durchläuft. Das ist eine Schlussfolgerung aus den aktuellen Homebrew-Formeln plus der LuaSandbox-Anforderung „Lua 5.1“.

Praktischer Weg auf deinem System

Ich würde es so angehen:

A. Prüfen, welches PHP du wirklich für Apache benutzt

which php

php -v

php --ini

php-config --version

phpize --version

Wichtig ist, dass CLI-PHP und Apache-PHP dieselbe Homebrew-PHP-Installation meinen. Sonst baut PECL in die falsche PHP-Umgebung.

B. Lua 5.1 lokal bereitstellen

Da Lua 5.1 laut Lua-Projekt weiterhin offiziell als Source verfügbar ist, kannst du sie lokal bauen. Lua 5.1.5 ist die letzte 5.1-Version.

Beispiel:

cd /tmp

curl -LO https://www.lua.org/ftp/lua-5.1.5.tar.gz

tar xzf lua-5.1.5.tar.gz

cd lua-5.1.5

make macosx

sudo mkdir -p /usr/local/lua51

sudo cp src/lua.h src/luaconf.h src/lauxlib.h src/lualib.h /usr/local/lua51/include/

sudo cp src/liblua.a /usr/local/lua51/lib/

Das ist kein wörtlich dokumentierter MediaWiki-Befehl, sondern der praktische Aufbau aus den offiziellen Lua-Quellen und der LuaSandbox-Anforderung, Lua-5.1-Header und -Library bereitzustellen. Die Doku verlangt genau diese Header/Libs.

C. LuaSandbox per PECL bauen

LuaSandbox sagt selbst: erst die korrekte Lua-5.1-Library bereitstellen, dann:#

export CPPFLAGS="-I/usr/local/lua51/include"

export LDFLAGS="-L/usr/local/lua51/lib"

pecl install luasandbox

Auf macOS/Homebrew kann es sein, dass du dem Build die Include-/Lib-Pfade mitgeben mußt. Häufig läuft das etwa so:

Falls pecl die Lua-Lib trotzdem nicht findet, wäre der nächste Weg der manuelle Build von LuaSandbox via phpize && ./configure && make && make install, genau wie in der offiziellen LuaSandbox-Doku beschrieben.

D. PHP-Erweiterung aktivieren

Die LuaSandbox-Doku sagt danach: extension = luasandbox in die PHP-Konfiguration eintragen und Webserver/PHP neu starten. Danach soll phpinfo(), get_loaded_extensions() und bei MediaWiki auch Special:Version die Extension zeigen.

Bei Homebrew-PHP ist das typischerweise eine zusätzliche .ini unter dem conf.d/php.ini-Pfad aus php --ini.

Zum Prüfen:

php -m | grep -i luasandbox

php -r 'var_dump(extension_loaded("luasandbox"));'

E. Apache neu starten

Bei dir mit Homebrew-Apache typischerweise: brew services restart httpd

F. In `LocalSettings.php` umstellen

Dann:

$wgScribuntoDefaultEngine = 'luasandbox';

$wgScribuntoEngineConf['luasandbox']['memoryLimit'] = 52428800; // zunächst Standardnähe

$wgScribuntoEngineConf['luasandbox']['cpuLimit'] = 7;

Die Scribunto-Doku nennt für luasandbox genau diese Konfigurationsschlüssel und die Standardgrößenordnung. Deine extrem hohen Werte würde ich zunächst nicht einfach übernehmen; erst messen, dann erhöhen.

Mußt du danach MediaWiki-Skripte laufen lassen?

Nicht zwingend.

Aber ich würde nach dem Umschalten einmal dies ausführen:

php maintenance/run.php purgeParserCache

php maintenance/run.php runJobs

Nicht weil LuaSandbox eine Datenmigration bräuchte, sondern damit du die Wirkung sauber an frisch aufgebauten Parser-Ausgaben misst.

Mein Rat zur Reihenfolge

Ich würde es in dieser Reihenfolge machen:

php -m | grep -i luasandbox prüfen
Lua 5.1 lokal bereitstellen
pecl install luasandbox
Extension aktivieren
Apache neu starten
Special:Version prüfen
erst dann in LocalSettings.php auf luasandbox umstellen

Der sachliche Kern ist:

Installieren mußt du nicht „LuaSandbox in MediaWiki“, sondern die PHP-Erweiterung luasandbox, und dafür braucht dein Mac zusätzlich eine Lua-5.1-Library.

Wenn du willst, gehe ich mit dir jetzt Schritt für Schritt an genau dein Homebrew-PHP 8.2/8.3-Setup, beginnend mit den Ausgaben von php --ini, php -v und which php.

Experiment

Das klingt nicht nach einer eingespielten Sache – eher nach einem Experiment mit ungewissem Ausgang.

Ich löse dies nun so, daß ich sehr lange Seiten in ein Unterverzeichnis aufteile und nur die Sachen auf der Haupotseite lasse, die ich für meine Forschung brauche.

Performance

Ja — das ist in deinem Fall der sachlich vernünftigere Weg.

luasandbox ist zwar grundsätzlich der richtige Performance-Pfad, aber auf deinem konkreten macOS/Homebrew-Setup mit bestehender produktiver Wiki-Installation ist es nicht die Art Maßnahme, die ich ohne kontrollierte Testumgebung als ersten Schritt empfehlen würde. Der Installationsweg ist machbar, aber nicht „einfach umschalten und fertig“.

Deine Lösung hat dagegen mehrere reale Vorteile:

weniger Parserlast pro Seitenaufruf
weniger Template-/Lua-Expansion auf der Hauptseite
geringere Cache-Kosten
bessere Bearbeitbarkeit
klarere Trennung zwischen Kernmaterial und Zusatzmaterial

Gerade bei importnahen Wikipedia-Seiten mit vielen Vorlagen und Modulen ist das oft der wirksamste Hebel, weil du damit nicht nur den Cache entlastest, sondern die eigentliche Renderkomplexität senkst.

Worauf ich dabei achten würde:

die Hauptseite wirklich nur als Arbeitsseite für deine Forschung halten
umfangreiche Belege, Zusatzabschnitte, Tabellen, Langlisten, Exkurse in Unterseiten auslagern
Einbindungen auf der Hauptseite sparsam halten; sonst holt man die Last nur indirekt wieder zurück
wenn sinnvoll, statt Transklusion auf Unterseiten auch schlicht verlinken, wenn der Inhalt nicht bei jedem Aufruf mitgerendert werden muß

Das ist kein Behelf, sondern oft die robustere Architektur.

Zusätzlich würde ich deine bereits gesetzte Änderung auf

$wgParserCacheType = CACHE_DB;

erst einmal so belassen und beobachten. Diese Maßnahme ist deutlich unkritischer als ein Scribunto-Engine-Wechsel.

Dein Weg ist also nicht Rückzug, sondern Komplexitätsreduktion an der Ursache. Das halte ich hier für richtig.

Testen

Ich teste nun ersteinmal die letzte Änderung zu Parser-Cache. Danke für deine Hinweise und Unterstützung. Wir sprechen uns im nächsten Chat.

Messpunkt

Gut. Dann ist das der richtige nächste Messpunkt.

Beobachte vor allem diese drei Dinge:

erste Ladezeit einer komplexen Seite
zweite Ladezeit direkt danach
erneute Ladezeit nach längerer Pause bzw. am nächsten Tag

Wenn sich gerade der erste Aufruf spürbar stabilisiert, war die Umstellung sinnvoll. Wenn nicht, liegt der Hauptengpass stärker in der Seitenkomplexität selbst.

Bis zum nächsten Chat.

Defining Namespace Aliases

Der Code für deine LocalSettings.php

Was genau passiert hier?

Ein wichtiger Hinweis

funktioniert

Acknowledging User Feedback

Ein kleiner Tipp für die Zukunft

MediaWiki schneller machen

nalyzing Performance Bottlenecks

1. PHP OPcache aktivieren (Der wichtigste Schritt)

2. Object Caching: Von "Nichts" auf "APCu"

3. Parser-Cache-Dauer erhöhen

4. Scribunto (Lua) Performance

5. Bilder-Rendering (Thumbnails)

Wenn eine Seite mit vielen Bildern 30 Sekunden lädt, versucht MediaWiki vermutlich, alle Thumbnails während des Seitenaufrufs zu generieren.

Zusammenfassung der Ursache

wgScribuntoConfig

Clarifying Lua Limits

Die Anatomie der Rechnung

Warum ist das für deine Performance wichtig?

Dein nächster Schritt zur Geschwindigkeit

kurzfristig zu 60% CPU ausgelastet

Analyzing Performance Bottlenecks

1. Die "Shell-Limits" anheben

2. PHP OPcache "JIT" aktivieren (Der M4-Turbo)

3. Datenbank-Engpässe (Pool-Size)

4. Scribunto "LuaStandalone" optimieren

5. Das "Bilder-Problem" lösen (Job-Queue)

Wo geht die Zeit wirklich verloren?

Uograde auf MediaWIki 1.51

Correcting Initial Assumptions

Kurzer Check vor dem Wechsel:

Was wir für den neuen Chat bereithalten sollten:

Abschied

Abschied

Kurze Checkliste für unseren Start im neuen Chat:

ChatGPT

Nun geht es um Performance:

Was der Flaschenhals am ehesten ist

Was weniger nach der Hauptursache aussieht

Woran du es festmachen kannst

Was ich in deinem Fall am wahrscheinlichsten finde

Was du konkret prüfen solltest

Mein Befund in einem Satz

Ein zu langsamer Server

Konfiguration

Mein Hauptbefund

Zu deinen übrigen Einstellungen

1) $wgCacheDirectory

2) luastandalone

3) Scribunto memory/cpu limits

4) $wgScribuntoUseGeSHi und $wgScribuntoUseCodeEditor

5) $wgRunJobsAsync = true

Was ich dir konkret empfehlen würde

1. Parser-Cache aus APCu herausnehmen

2. Auf LuaSandbox umstellen

3. Job-Queue sauber über Scheduler laufen lassen

4. Komplexität der betroffenen Seiten messen

Was ich nicht als erste Änderung empfehlen würde

Meine zusammengefasste Diagnose

Danke für die Analyse.

Ja. Beides läßt sich klar trennen.

1) CACHE_DB

a) Muß dafür noch etwas installiert werden?

b) Muß man nach dem Umschalten noch run.php-Skripte ausführen?

2) luasandbox

a) Muß dafür noch etwas installiert werden?

b) Muß man nach dem Umschalten noch run.php-Skripte ausführen?

Zu deinem zusätzlichen Hinweis

Mein praktischer Rat für dich

Wichtige Nebenbemerkung

CACHE_DB

LuaSandbox

Praktischer Weg auf deinem System

A. Prüfen, welches PHP du wirklich für Apache benutzt

B. Lua 5.1 lokal bereitstellen

C. LuaSandbox per PECL bauen

D. PHP-Erweiterung aktivieren

E. Apache neu starten

F. In LocalSettings.php umstellen

1) `$wgCacheDirectory`

2) `luastandalone`

4) `$wgScribuntoUseGeSHi` und `$wgScribuntoUseCodeEditor`

5) `$wgRunJobsAsync = true`

1) `CACHE_DB`

b) Muß man nach dem Umschalten noch `run.php`-Skripte ausführen?

2) `luasandbox`

b) Muß man nach dem Umschalten noch `run.php`-Skripte ausführen?

F. In `LocalSettings.php` umstellen