Performance im Admin Bereich beschleunigen

Hi Jenna,
das war evt. der Post von mir:
http://www.drupalcenter.de/node/50838
In den meisten Fällen ist die Performance bei mir nun ausreichend.
Ich bin mir nicht ganz sicher, ob diese SQL-Optimierung sich auf die Performance im Adminbereich auswirkt.
Ganz sicher verhindert sie allgemeine Performance-Einbrüche durch eine kaputte cache_*** Tabelle, was ich vorher häufiger hatte.

Deine Tipps mit der Deaktivierung der Module werde ich auch mal austesten.

@montviso, das Script welches du geschrieben hast, hat das die gleiche Funktion wie wenn ich im PHPMyAdmin auf Cache_Tabellennamen gehe und dort reparieren/optimieren wähle?
Dann könnte ich das auf der Test mal ausprobieren, ohne erst ein Script basteln zu müssen.

Den Beitrag, den ich meinte, habe ich gerade gefunden, der Post von Ionit mit dem sql.tuner:
http://www.drupalcenter.de/node/49090#comment-177766

Da ja nicht jeder Root Zugriff hat würden mich weitere Vorschläge zur Verbesserung immer noch sehr interessieren.

Grüße Jenna

Ja, in meinem Script werden in einer Schleife für alle Tabellen die Repair und Optimize-Befehle ausgeführt,die PHPMyAdmin auch anbietet.
Falls eine Tabelle repariert werden muß, sieht man das ja auch schon in der Übersicht, wenn man PHPMyAdmin aufruft.

Hallo Jenna,
ich greife das Thema noch mal auf, weil ich eine Kleinigkeit zu erwähnen vergaß bei meinem letzten Post.
Dieser Repair-Befehl klappt nur bei myisam-Tabellen.

Nun ist es ja so, daß bei Drupal 7 per Default innodb zum Einsatz kommen soll.
Ich habe aber fest gestellt, daß bei meinen 7-er Projekten z.T. ein Mischmasch von myisam und innodb herrschte.

Die einhellige Meinung lautet: innodb-Tabellen sind zwar grundsätzlich etwas langsamer, aber zuverlässiger in der Datenvorhaltung und es wird der Einsatz von innodb empfohlen, auch wenn keine Transaktionen ect. genutzt werden.
Was ganz schlecht kommt, ist ein Join über myisam + innodb, deshalb sollten die Tabellen einheitlich aufgebaut haben.

Ich habe nun folgenden Befehl per Script in einer Schleife für diese Datenbank durchlaufen lassen:
ALTER TABLE <TABLENAME> ENGINE='InnoDB';

Damit wird die Tabelle gleichzeitig repariert und auf innodb konvertiert.

Drauf gekommen bin ich, weil ich heute mal wieder Performance-Probleme in dieser Datenbank hatte, und nun sind sie erst mal beseitigt.
Ob es an der einheitlichen innodb-Engine liegt oder daran, daß die Tabellen damit einen Repair durchlaufen haben, weiß ich nicht genau.
Jedenfalls braucht man danach den o.g. repiar-Befehle nicht mehr auf diese Datenbank anwenden, weil dann eine Fehlermeldung kommt.

Bist Du mit Deinem Performance-Problem weiter gekommen?
Welche Datenbank-Engine ist bei Dir aktiv?

Wenn man nach innodb + Drupal7 sucht, kommt einige Info.

Gruß, Regina

Bei mir laufen alle Tabellen auf InnoDB / utf8_general_ci

Wie kommt denn der Mix bei dir überhaupt zustande, ich exportiere die DB meistens über Servercon direkt auf den FTP Server und spiele sie per Putty wieder ein.
Hast du die händisch geändert oder woher kommen die 2 Formate?

Die Geschwindigkeit im Admin Bereich ist durch Deaktivierung o.g. Module richtig gut geworden, trotzdem probiere ich gern noch weitere Möglichkeiten aus.
Ich leere jetzt regelmäßig über PHPMyAdmin alle "cache" Tabellen und watchdog, ob das Performancemäßig etwas bringt kann ich nicht so wirklich erkennen, schaden tuts auch nicht.

http://drupal.stackexchange.com/questions/20893/drupal-database-innodb-o...

Habe gerade diese beiden Module entdeckt, aber noch nicht getestet, kennst du die?
https://www.drupal.org/project/db_maintenance
https://www.drupal.org/project/schema

Grüße Jenna

Hast du die händisch geändert oder woher kommen die 2 Formate?
Das ist die interessante Frage.
Einfach Drupal 7 installiert, nix händisch geändert.
Inzwischen habe ich sie leider alle auf innodb geändert und kann nicht mehr sagen, welche Tabellen myisam waren.
Auf jeden Fall field_data_* und field_revision_field_* Tabellen, die also nachträglich beim Anlegen neuer Inhaltstypen + Felder erzeugt wurden.

Die genannten Module werde ich mal austesten, ebenso wie das Deaktivieren der genannten Module.
Dann melde ich mich noch mal.

Ich habe nun die genannten Module näher angesehen:

db_maintenance macht wohl genau das gleiche, wie mein Script (Optimize), und ist eine Super alternative, für alle, die kein Script schreiben und den Cron Job nicht auf dem Server einrichten wollen.
Außerdem kann man auf die schnelle entweder alle oder nur einzelne Tabellen auswählen.
Ich habe das Modul installiert und einmal via Drupal-Cron für alle Tabellen laufen lassen.
Man kann es so einstellen, daß man das Ergebnis für die Optimierung im watchdog sieht.

Der Vorteil von meinem Script ist, daß es unabhängig vom Cronjob läuft und daß man kein extra Modul installieren muß (Performancevorteil???).
Ich hätte es vermutlich nicht geschrieben und eingerichtet, wenn ich vorher schon das Modul gekannt hätte, aber da es nun schon mal läuft und alle relevanten Datenbanken auf diesem Server bedient, habe ich das Modul wieder deinstalliert.

schema So wie ich es verstehe, ermöglicht es nur weiter gehende programmatische Zugriffe via API.
Ob das spezielle Vorteile für die Performance hat, wird mir auf die Schnell nicht ersichtlich.