Startseite
  • » Home
  • » Handbuch & FAQ
  • » Forum
  • » Übersetzungsserver
  • » Suche
Startseite › Benutzerhandbuch › Fortgeschrittene › Best Practice - Drupal Sites - Guidelines ›

Performance Bremsen - eine Übersicht

Eingetragen von rapsli (1500) am 02.03.2010 - 21:35 Uhr

Es gibt diverse Elemente einer Drupalseite (oder auch allgemein einer Webseite), welche die Geschwindigkeit beeinträchtigen. Dazu gehören die folgenden Elemente:

  • Festplatte
  • CPU
  • Datenbank
  • Schlecht programmierte Module
  • Cron
  • Bildbearbeitung
  • Frontend

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:

  1. Die Anzahl an Anfragen pro Zeiteinheit
  2. 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: -

‹ Best Practice - Drupal Sites - Guidelines nach oben Eine neue Seite bauen - Architektur ›
  • Anmelden oder Registrieren um Kommentare zu schreiben

Benutzeranmeldung

  • Registrieren
  • Neues Passwort anfordern

Aktive Forenthemen

  • für drupal11 ein Slider Modul
  • [gelöst] W3CSS Paragraphs Views
  • Drupal 11 neu aufsetzen und Bereiche aus 10 importieren
  • Wie erlaubt man neuen Benutzern auf die Resetseite zugreifen zu dürfen.
  • [gelöst] Anzeigeformat Text mit Bild in einem Artikel, Drupal 11
  • Social Media Buttons um Insteragram erweitern
  • Nach Installation der neuesten D10-Version kein Zugriff auf Website
  • Composer nach Umzug
  • [gelöst] Taxonomie Begriffe zeigt nicht alle Nodes an
  • Drupal 11 + Experience Builder (Canvas) + Layout Builder
  • Welche KI verwendet ihr?
  • Update Manger läst sich nicht Installieren
Weiter

Neue Kommentare

  • melde mich mal wieder, da ich
    vor 21 Stunden 57 Minuten
  • Hey danke
    vor 1 Tag 16 Stunden
  • Update: jetzt gibt's ein
    vor 2 Tagen 10 Stunden
  • Hallo, im Prinzip habe ich
    vor 6 Tagen 20 Stunden
  • Da scheint die Terminologie
    vor 6 Tagen 23 Stunden
  • Kannst doch auch alles direkt
    vor 1 Woche 4 Tagen
  • In der entsprechenden View
    vor 1 Woche 4 Tagen
  • Dazu müsstest Du vermutlich
    vor 1 Woche 4 Tagen
  • gelöst
    vor 4 Wochen 19 Stunden
  • Ja natürlich. Dass ist etwas,
    vor 4 Wochen 1 Tag

Statistik

Beiträge im Forum: 250233
Registrierte User: 20449

Neue User:

  • Mroppoofpaync
  • 4aficiona2
  • AppBuilder

» Alle User anzeigen

User nach Punkten sortiert:
wla9461
stBorchert6003
quiptime4972
Tobias Bähr4019
bv3924
ronald3857
md3717
Thoor3678
Alexander Langer3416
Exterior2903
» User nach Punkten
Zur Zeit sind 0 User und 19 Gäste online.

DrupalCenter durchsuchen:

Benutzerhandbuch

  • FAQ - Häufig gestellte Fragen.
  • Links & Downloads
  • Über Drupalcenter.de und das deutschsprachige Benutzerhandbuch
  • Über Drupal
  • Einsteiger
  • Fortgeschrittene
    • Best Practice - Drupal Sites - Guidelines
      • Performance Bremsen - eine Übersicht
      • Eine neue Seite bauen - Architektur
      • Performance während der Entwicklung im Griff halten
      • Modulentwicklung - Bestpractices
      • Anhang
    • Die beliebtesten Themes und Module
    • Tutorials & How To's - Tipps & Tricks
  • Entwicklung von Modulen und Themes
  • Drupalcenters Community
  • Drupal 7 Video-Trainings (Deutsch)
  • Drupal-Testumgebung erstellen
  • Drupal 6 Module
  • Drupal 7 Module
  • Drupal Screencasts auf deutsch
  • Archiv

Das Copyright des deutschsprachigen Drupal-Benutzerhandbuches unterliegt den jeweiligen Autoren. Übersetzungen des englischsprachigen Drupal-Benutzerhandbuches unterliegen der Creative Commons License, Attribution-ShareAlike 2.0.

Hauptmenü

  • » Home
  • » Handbuch & FAQ
  • » Forum
  • » Übersetzungsserver
  • » Suche

Quicklinks I

  • Infos
  • Drupal Showcase
  • Installation
  • Update
  • Forum
  • Team
  • Verhaltensregeln

Quicklinks II

  • Drupal Jobs
  • FAQ
  • Drupal-Kochbuch
  • Best Practice - Drupal Sites - Guidelines
  • Drupal How To's

Quicklinks III

  • Tipps & Tricks
  • Drupal Theme System
  • Theme Handbuch
  • Leitfaden zur Entwicklung von Modulen

RSS & Twitter

  • Drupal Planet deutsch
  • RSS Feed News
  • RSS Feed Planet
  • Twitter Drupalcenter
Drupalcenter Team | Impressum & Datenschutz | Kontakt
Angetrieben von Drupal | Drupal is a registered trademark of Dries Buytaert.
Drupal Initiative - Drupal Association