Kürzlich meldete sich ein Neukunde bei mir, der das Problem hatte, dass die Performance seiner Seite zunehmend mehr abnahm. Nach kurzer Sondierung der Site stellte ich fest, dass die Site mit unnötigen Transients quasi „vollgespammt“ wurde.
Das Problem in Zahlen:
- Die Datenbank war 450MB groß. Auf einer grade einmal ein Jahr alten Site!
- Nach meiner Optimierung war die Datenbank nur noch 40MB groß. Allerdings konnte man bei einer lokalen Installation sprichwörtlich zusehen, wie die Datenbank rasch wieder anwuchs.
- Und das mit nur
- Rund 250 Beiträgen
- 12 Seiten
- ~ 1500 Kommentaren
- 25 aktiven Plugins
- einem kommerziellen Theme (The7) mit dem WPBakery „Visual Composer“ Pagebuilder
Letztendlich konnte ich den Schuldigen ermitteln und das grundlegende Problem endgültig lösen. Das soll aber in diesem Beitrag nicht Thema sein.
Das Problem beim Update der Site lag an einer ganz anderen Stelle: Der Provider schränkte den Upload nämlich auf 10MB ein – womit ich dann Schwierigkeiten hatte, die reparierte Datenbank zu synchronisieren.
Als Lösung gibt es nun unter Umständen verschiedene Möglichkeiten. So kann man bei einem guten Provider eine eigene php.ini in das Rootverzeichnis der WordPress-Installation schreiben und damit die Standard-PHP Einstellungen überschreiben.
Die php.ini dann z.B. so aussehen:
memory_limit = 128M post_max_size = 64M upload_max_filesize = 50M max_execution_time = 5000 max_input_time = 5000
Wenn nun aber das Problem auftaucht, dass phpMyAdmin die Datei immer noch nicht hochladen kann, da die php.ini leider nicht greift oder das phpMyAdmin einen TimeOut beim Dekomprimieren erhält, bleibt einem nur der Umweg, die Datenbank in kleinere Häppchen aufzusplitten und diese nach und nach hochzuladen. Händisch ist das aber sehr aufwändig und hässlich.
Dafür empfehle ich das Tool SQL DUMP SPLITTR, mit dem sich ein SQL-Datenbankdump problemlos in beliebig große Teildateien splitten lässt, die dann nach und nach hochgeladen und ausgeführt werden können.
