Miese Performance killt den Server ....
Eingetragen von Thoor (3678)am 05.12.2010 - 20:09 Uhr in
Eine eher kleine Drupal 6.x Seite mit knapp 550 angemeldeten Usern belastet den Server ungewöhnlich hoch mit Datenbankabfragen. Meist, wenn mehr als als ca. 30 User zeitgleich online sind. Manchmal aber auch schon mit weniger Usern. Der Traffic und Abfragelast wird zu mindestens 90% von angemeldeten Usern verursacht.
Die Folge ist ein erlahmen des Servers bis hin zum kompletten Ausstieg. Die Datenbank wird dabei so stark belastet, daß der Provider letzte Woche den Verdacht eines Hacker Angriffes hatte und die Seite letzte Woche zeitweilig sogar abgeschaltet hat.
---------
Die standardmäßigen Lastreduzierungen unter Leistung sind natürlich alle aktiviert.
Caching-Modus: Normal
Minimale Cache-Lebensdauer: 15 Min.
Seitenkompression: Aktiviert
Block-Cache: Aktiviert
CSS Dateien optimieren: Aktiviert
JavaScript optimieren: Aktivieren
Auch bei Übersichtsseiten die mit VIEWS erstellt wurden, wird ein Cache eingesetzt.
-----------
Die eingesetzten Module der Seite können dieser beigefügten Grafik( 460 kB! ) entnommen werden:
http://www.thoor.de/sites/default/files/bilder/projekte/module.gif
-------------
Die Seite selbst läuft auf einem managed Server der Fa. Netcup mit den folgenden Leistungsmerkmalen:
http://www.netcup.de/bestellen/produkt.php?produkt=142
Zugriff auf den Server nur bis auf CONFIXX Ebene und Datenbankzugriff mit phpMyAdmin.
Die Server Ausstattung ist wie folgt:
Betriebssystem: Linux
MySQL-Version: 5.0.51a-24+lenny4
PHP-Version: 5.2.6-1+lenny9 Speicher: 100.00 MB Maximale Ausführungszeit: 30 Sekunden PHP-Info
PHP-Erweiterungen: zip, xmlwriter, libxml, xml, wddx, tokenizer, sysvshm, sysvsem, sysvmsg, session, SimpleXML, sockets, soap, SPL, shmop, standard, Reflection, posix, mime_magic, mbstring, json, iconv, hash, gettext, ftp, filter, exif, dom, dba, date, ctype, calendar, bz2, bcmath, zlib, pcre, openssl, xmlreader, cgi-fcgi, curl, gd, imagick, imap, mcrypt, mhash, mysql, mysqli, PDO, pdo_mysql, ionCube Loader, Zend Optimizer
Abgeschaltete Funktionen: system, exec, shell_exec, passthru
-----------
Eine frühere Analyse einer fast identischen Seite ergab den Verdacht, daß es vielleicht an einem VIEWS Bug liegen könnte. Bei der Analyse wurde die Seite auf einen anderen Server bei ALL INKL gespiegelt und auch dieser hatte dann auch die Performance Probleme.
Da der Fehler jetzt auch auf einem Angebot auftritt, das erst vor einem Jahr programmiert wurde, könnte es vielleicht auch an einer unglücklichen Modulkonstellation oder - kombination liegen?
Ein Testen als angemeldeter User ist unter http://www.gewinnspiele.be/login mit "Antester-Testan" möglich.
Das Ganze brennt mir dringendst unter den Nägeln, da es eine Produktivseite ist, die kaum noch zu nutzen ist.
Aktuell sieht schon jemand drüber, aber mehr augen sehen ja vielleicht mehr, als nur vier ... Jemand Tipps, Ahnungen oder Mutmaßungen, wie dieses Problem erfolgreich bewältigt werden kann?
- Anmelden oder Registrieren um Kommentare zu schreiben
Wie sieht das PHPMemoryLimit
am 05.12.2010 - 23:16 Uhr
Wie sieht das PHPMemoryLimit aus?
Gerade die Anzahl der aktiven Module und die Tatsache, dass ImageAPI GD2 verwendet wird, kann dei Speicher ziemlich ausreizen (ist mir in den Sinn gekommen, da es bei mir für einen kleinen Ubercart-Shop eine Warnung geworfen hat, dass 64MB zu gering sein könnten.
It is highly recommended that you set you PHP memory_limit to 96M to use ImageAPI GD. A 1600x1200 images consumes ~45M of memory when decompressed and there are instances where ImageAPI GD is operating on two decompressed images at once.
)
steht oben bei den Server
am 05.12.2010 - 23:19 Uhr
steht oben bei den Server Infos ... 100 MB - das sollte es nich sein, denke ich
ImageCache ist unkritisch.
am 05.12.2010 - 23:26 Uhr
ImageCache ist unkritisch. Bei 20-30 Usern braucht es schon eine Menge Zufälle, dass alle User gleichzeitig einen PHP Prozess auslösen in dem ImageCache ein großes Bild resizen muss. Wie der Name schon verrät cacht ImageCache, so dass jede Transformation von der Quelle ins Zielformat nur einmal pro Bild ausgeführt wird.
Hast du dir mal mittels
am 06.12.2010 - 00:38 Uhr
Hast du dir mal mittels 'devel' die Ausführungszeiten der Datenbankabfragen ausgeben lassen?
Meistens findet man dadurch recht schnell den 'Bösewicht', sprich das Modul oder die View.
Da sieht aktuell alles ganz
am 06.12.2010 - 01:21 Uhr
Da sieht aktuell alles ganz okay aus (Zeit und ANzahl der DB-Abfragen, Ausführungszeit der Skripte). Mglw. tritt das Problem erst auf, wenn eine bestimmte Anzahl User im System unterwegs sind.