Schlechte Performance beim Schreiben

- Nutzt du einen Root-Server und hast Zugriff auf alle relevanten Logfiles und Einstellungen?
- Setzt du ein Server-Monitoring (Munin, Cacti, ..) ein? IOWait checken, CPU und RAM-Auslastung checken
- Ändert sich die Zeit in Abhängigkeit von Tageszeit / aktueller Besucheranzahl?
- Dauert das Speichern bei allen Inhaltstypen gleich lang?
- Dauert das Speichern lange, oder der Seitenaufbau nach dem Speichern? (Umleitung?) Mit Firebug checken.

...

Nutzt du einen Root-Server und hast Zugriff auf alle relevanten Logfiles und Einstellungen?
Ja.

Keine Fehler im apache2 error.log oder in einem der anderen Logs zum Zeitpunkt des Schreibens.

Auf dem Rootserver läuft übrigens Debian Etch mit Standard Apache 2.2.3 und MySQL 5.0.32. Die Datenbank läuft als MyISAM.

Habe schon mal überlegt teilweise auf InnoDB zu wechseln. Soll laut http://drupal.org/node/103402 Kommentar Boris Mann bei Debian schneller im Schreibvorgang sein.

Setzt du ein Server-Monitoring (Munin, Cacti, ..) ein? IOWait checken, CPU und RAM-Auslastung checken
Werte zum Zeitpunkt des Speicherns:
Real memory 3.83 GB total, 2.07 GB used
Virtual memory 2.01 GB total, 46.11 MB used
Local disk space 364.79 GB total, 23.73 GB used

IOWait, CPU und RAM-Auslastung zeigen keine besondere Schwankungen oder extreme Auslastungen zum Zeitpunkt des Speicherns eines Testeintrages an.

CPU Werte in der letzten Stunde max. 40% (Durchschnitt 11%), IOWAIT max. 6,9% (Durchschnitt 0,75%).
CPU load averages 0.09 (1 min) 0.15 (5 mins) 0.16 (15 mins)

Zum exakten Zeitpunkt des Speicherns lag CPU bei 16% und IOWAIT bei 0,02%

Ändert sich die Zeit in Abhängigkeit von Tageszeit / aktueller Besucheranzahl?
Nein, Schreibauer relativ konstant über die Tageszeit / Besucherzahl hinweg

Dauert das Speichern bei allen Inhaltstypen gleich lang?
Ja, überall ca. 10-18 Sekunden (konnte den Grund für die 8 Sekunden Unterschied allerdings noch nicht erkennen)

Dauert das Speichern lange, oder der Seitenaufbau nach dem Speichern? (Umleitung?) Mit Firebug checken.
Laut Firebug dauert das Speichern so lange. Der neue Seitenaufbau geht dann wieder normal schnell von statten.

InnoDB kann Vorteile haben. Die damit erzielbaren Performance-Gewinne beim Schreiben liegen aber nicht in Größenordnungen, die die Schreibperformance im Hinblick auf deine Zeitangaben auf übliche Werte legen würden.

Ich hatte zunächst die Vermutung, es könne mit dem Caching zusammen hängen. Wenn sich Inhalte ändern verwirft Drupal den kompletten Cache und muss ihn neu aufbauen. In Verbindung mit einem womöglich swappenden System führt das zu Latenzen, während denen ausgelagerte Pages eingelesen, verworfen und andere dafür ausgelagert werden müssten, etc. pp.

Hast du das Slow Query Log in MySQL aktiviert und die Zeit mal auf 1s oder drunter gesetzt und dir angeschaut, ob sich im Log verdächtige Einträge beim Speichern (INSERTs und UPDATEs) zeigen?

Ich würde an deiner Stelle auch das Devel-Modul mal einsetzen (dass in der D5 Version nicht an das D6 Modul herankommt, aber immerhin): http://drupal.org/project/devel
Achtung: Das Devel Modul selbst ist ein Performance-Killer dessen Abfragen man entsprechend in Gedanken "ausblenden" muss.

Auch das Trace Modul ist nen Blick wert: http://drupal.org/project/trace

Im Anschluss an die Tests hast du dann ein paar Hard Facts anhand derer man hoffentlich schlauer als zuvor ist.

Wenn du es nicht eh schon so handhabst würde ich anraten in einer Kopie des Live-Systems auf demselben Server zu arbeiten.

Hallo Z2009,

um welche Drupal Version handelt es sich denn? Welche Module setzt Du denn ein? Könnten wir vielleicht die URL zu der Website bekommen?

*************************************************************************************************

5, steht gleich im ersten Satz ;)

So habe mir mal ein paar Seitenaufrufe mit devel angeschaut. Dabei ist mir aufgefallen, dass die Datenbankabfragen der Funktion "sess_write" extrem viel Zeit bei der Ausführung brauchten.

Also habe ich bei den Protokolleinstellungen die Zugriffsstatistik deaktiviert (denke mal das sess_write damit in Verbindung steht) und seitdem rennt die Seite auch endlich wieder beim speichern neuer nodes.

Werde mir aber demnächst auch mal meine 2 kritischsten Module pathauto und xml-sitemap anschauen.

Ist deine Tabelle accesslog riesig? Stell sie mal auf InnoDB um, oder aber sorg unter admin/logs/settings dafür, dass sie in kürzeren Abständen geleert oder besser noch nicht gefüllt wird.

Xmlsitemap kannste ggf. einfach dahingehend umstellen, dass die Sitemap über den Cron erzeugt wird und nicht beim Anlegen neuer Inhalte. (auf die paar Minuten kommts nicht an)

Pathauto sollte unkritisch sein. Es wird ja nur ein neuer Pfad erzeugt.

Die Tabelle hatte knapp 90.000 Einträge. Habe jetzt eingestellt daß sie nicht gefüllt wird. In den letzten Cron-Läufen wurden die Inhalte der Tabelle dann auch gelöscht.

Habe ich jetzt auch so gemacht, und hat wieder etwas mehr Geschwindigkeit gebracht.

Jetzt bin in eigentlich sehr zufrieden mit der Geschwindigkeit meiner Seite beim Lesen und Schreiben von Daten.

Also Danke noch einmal !!!