Performance Bremsen - eine Übersicht
Es gibt diverse Elemente einer Drupalseite (oder auch allgemein einer Webseite), welche die Geschwindigkeit beeinträchtigen. Dazu gehören die folgenden Elemente:
In diesem Kapitel werden diese Punkte kurz erläutert ohne auf die genauen Konzepte einzugehen.
CPU
Um einen Request zu verarbeiten, wird entsprechende CPU Leistung benötigt: PHP kompilieren, PHP abarbeiten, Datenbankabfragen machen usw. Durch geschickte Programmierung und das Einsetzen von Caches kann diese Last reduziert werden.
Daher: Je mehr Module und je grösser die Komplexität, desto höher die CPU Belastung
Abhilfe: OPcache oder Loadbalancing. Es gibt mehrere Server, welche die PHP Verarbeitung vornehmen. Falls die DB zuviel Last erzeugt, dann muss ein Master-Slave System eingesetzt werden.
Skalierung: Loadbalancing
Festplatte
Bei einer PHP Applikation werden die benötigten Dateien bei jedem Seitenaufruf von der Festplatte gelesen. Das hat den Effekt, dass bei einer grossen Anzahl an Modulen beim Booststrapen von Drupal eine beachtliche Anzahl an Dateien in den Speicher geladen werden muss.
Daher: Je mehr Module, desto grösser die Belastung auf die Festplatte.
Abhilfe: Ein OPcache, wie z.B. APC. Hier wird der PHP Code vorkompiliert und in den Arbeitsspeicher geladen, so dass dieser nicht bei jedem Request von der Festplatte gelesen und kompiliert werden muss.
Skalierung: Gibt es grundsätzlich zwei Möglichkeiten: 1) Den Drupal files Ordner (z.B. sites/default/files) auf einen anderen Rechner auslagern und über Mount einbeziehen. Dies ist erfolgversprechend, wenn der Files Ordner sehr viel IO Last erzeugt. Weiterführende Links: NFS, GlusterFS.
Datenbank
Die Datenbank kann Anfragen nur seriel abarbeiten und ist daher limitiert. Folgende Faktoren beeinflussen die Geschwindigkeit der Applikation:
- Die Anzahl an Anfragen pro Zeiteinheit
- Die Komplexität der Anfragen
Daher: Je komplexer und je mehr Anfragen, desto langsamer die Seite.
Als Faustregel kann man sagen, dass ein Seitenaufruf mit ...
... 50 Queries -> sehr gut. Alles in Ordnung
... 200-500 Queries -> Hier wird bereits einiges geladen -> Je nach Server jedoch noch tragbar
... > 1000 -> hier muss definitiv etwas gemacht werden
Abhilfe:Anzahl Anfragen reduzieren und vereinfachen, sowie Cachingstrategien einsetzen.
Skalierung: Hier gibt es diverse Möglichkeiten: Datenbank auf einen eigenen Server auslagern, Datenbankreplikation, Indizes korrekt setzen, Drupalcache mittels Cacherouter in Memory auslagern usw.
Schlecht programmierte Module
Wie bereits in der Einleitung erwähnt reicht die Palette an Drupalmodule von sehr schlecht bis ausgezeichnet. Als Grundsatz gilt: Jedes installierte Modul (ob gut oder schlecht) ist eine Belastung fürs System. Das kommt daher, dass beim Aufrufen eines Hooks, jedes Modul durchgelaufen wird und geprüft wird, ob der entsprechende Hook vorhanden ist.
Schlecht programmierte Module können die verschiedensten Auswirkungen auf ein System haben (Datenbank, CPU und Festplatte). Als schlechtes Beispiel bezüglich der DB Verwendung:
<?php
$ar_nid = array(3, 5, 6);
foreach ($ar_nid as $nid) {
$title = db_result(db_query("SELECT title FROM {node} WHERE nid=%d", $nid));
drupal_set_message($title);
}
?>Besser wäre der folgende Ansatz:
<?php
$ar_nid = array(3, 5, 6);
$result = db_query("SELECT title FROM {node} WHERE nid=%d OR nid=%d OR nid=%d", $ar_nid);
while ($title = db_fetch_object($result)) {
drupal_set_message(check_plain($title)));
}
?>Im ersten Beispiel muss die Datenbank 3. Mal befragt werden, beim 2. Mal lediglich 1 Mal.
Daher: Je mehr Module, desto langsamer das System
Abhilfe: Module überlegt einsetzen. Nur Module einsetzen, welche auch wirklich benötigt werden und nicht benötigte Module wieder deaktivieren und deinstallieren.
Skalierung: -
Cron
Der Cron wird periodisch ausgeführt. Je nach Webseite kann das alle 15 Minuten sein oder lediglich 1 mal Pro Tag. Im Cron werden aynchrone Arbeiten durchgeführt: Das können Aufgaben sein, wie das Zeitgesteuerte Publizieren, das Aufräumen des temporären Verzeichnisses, Import von Daten usw.
Daher: Je häufiger der Cron läuft, desto grösser die Belastung für das System.
Abhilfe: Den Cron weniger häuft laufen lassen, bzw. bei der Programmierung darauf achten, dass Prozesse, welche lediglich 1 mal pro Tag durchgeführt werden müssen, auch lediglich 1 mal pro Tag laufen (Flag setzen), auch wenn der Cron alle 15 Minuten läuft
Skalierung: -
Bildbearbeitung
Die Bildbearbeitung ist von Natur aus sehr Ressourcenintensiv, was die CPU sowie den Speicherverbrauch angeht. Es spielt hier primär eine Rolle, wie gross (Pixel) ein Bild ist und nicht wie schwer (MB), denn: Ein Bild, welches 10 MB gross ist bei 5000x3000 Pixel, mag vollkommen unproblematisch sein. Ein Bild dagegen, welches lediglich 4 MB gross ist bei 6000x10000 Pixel kann jedoch problematisch sein, was den Speicherverbrauch angeht. Imagecache ist ein kleines Wundertool. Die gewünschten Bilder werden immer auf dem Originalbild berechnet und dann als gecachte Version abgespeichert.
Daher: Je grösser (Pixel) die hochgeladenen Bilder sind, desto grösser die Belastung für das System.
Abhilfe: Zu grosse Bilder beim Hochladen skalieren, damit Imagecache nicht auf den Originalbildern rechnen muss (VORSICHT: Dabei gehen IPTC Dateien verloren!)
Skalierung: Den Bildbearbeitungsprozess auf einen eigenen Server auslagern.
Frontend
Das Frontend stellt nicht direkt eine Belastung für den Server dar, ist jedoch dennoch dafür verantwortlich, dass der Benutzer warten muss. Wartezeiten im Frontend entstehen vor allem durch schlechte JQuery Selektoren, viele & grosse Bidler und viele CSS und Js Dateien.
Abhilfe: CSS und JS aggregieren, Sprites einsetzen, HTML Komprimierung einschalten, JQuery Selektoren wenn möglich auf IDs legen. Firebug und das Plugin YSlow sind hier sehr hilfreich.
Skalierung: -
- Anmelden oder Registrieren um Kommentare zu schreiben
Neue Kommentare
vor 58 Minuten 21 Sekunden
vor 3 Stunden 7 Minuten
vor 21 Stunden 54 Minuten
vor 3 Tagen 3 Stunden
vor 3 Tagen 4 Stunden
vor 1 Woche 3 Stunden
vor 1 Woche 8 Stunden
vor 1 Woche 2 Tagen
vor 1 Woche 2 Tagen
vor 1 Woche 3 Tagen