[Performance] Performance einer datenbankgestützten Anwendung verbessern

Serverhardware ersetzen

Es besteht die Möglichkeit einen neuen Server mit mehr Power zu kaufen/mieten, um die Datenbank dadurch zu beschleunigen.

Nachteil sind die Hardware-Kosten und der Aufwand beim Umzug der Webseite.

Vorteil ist eine leistungsstärkeres System, das für die Zukunft gerüstet wäre.

Datenbank analysieren

Die Datenbank sollte einer genauen Analyse unterzogen werden. Können die Queries durch geschickt gewählte Indizes beschleunigt werden, bzw. ist das Datenbank-Schema eventuell nicht für die Daten geeignet. Vielleicht ist die installierte Datenbank-Version zu alt, und eine neue Version bringt mehr Performance mit. Vielleicht können zu groß gewordene Tabellen durch das Löschen von alten Daten verkleinert werden.

Nachteil ist, je nach Komplexität der Datenbank, der zeitliche Aufwand für diese Analyse. Auch ist es möglich das der Quellcode der mit der Datenbank kommuniziert angepasst werden muss damit die Queries wieder passen.

Der größte Vorteil dieser Methode ist das hier, trotz des unter den Nachteilen erwähnten zeitlichen Aufwands, viele QuickWins erreicht werden können. Indizes z.B. sind schnell vergeben, und auch das Löschen nicht mehr benötigter Daten ist schnell gemacht.

Caching

Caching auf mehreren Ebenen wäre auch eine Möglichkeit.

a) das Cachen von Ergebnissen der Datenbank-Abfragen

Die Datenbank wird entlastet, und nicht mehr so häufig angefragt. Fast vollständige Abkopplung von Webserver-Request und Datenbank-Request.

b) das Cachen von gerenderten Seiten

Das gleiche Ergebnis wie unter a). Hier wird sogar noch die Power, die zum Rendern der Inhalte benötigt wird, gespart.

c) Optimierung vom Browsercaching durch sinnvolle Header

Durch das browserseitige Cachen von statischen Inhalten ist der Webserver bei mehreren Seitenaufrufen nur mit dem Rendern von Inhalten beschäftigt. Eventuell können statische Inhalte sogar auf ein CDN ausgelagert werden, um den Server noch weiter zu entlasten.

Vorteile: Datenbank wird, je nach Implementierung, komplett entlastet.

Nachteile: Das Cachen von Inhalten kann dafür sorgen, dass der User eventuell nicht die aktuellsten Inhalte sieht. Die Implementierung des Caching-Mechnismus bringt Aufwand mit sich.

Reihenfolge

Folgende Reihenfolge bietet sich an:

• Datenbank analysieren // kostengünstig und schnell gemacht
• Caching // kostengünstig und mit vertretbarem Aufwand
• Server-Hardware ersetzen // kostenintensiv und aufwändig

1. Überlegen ob man überhaupt halbwegs wusste, was man da tat.. Falls ok, prüfen ob alle Alkoholvorräte in den letzten Tagen auf seltsame weise vernichtet wurden. Fall ja - Projekt löschen - ggf Design überdenken - nochmal implementieren.

2. Anbindung der Datenbank prüfen. Reponsezeit des Netwerks prüfen. Prüfen ob irgendwo noch ein Modem verwendet wird. Falls ja, durch adäquate Infrastruktur ersetzen.

3. Hardware auf dem die Datenbank läuft hinsichtlich Auslastung und anderer konkurrierender Prozesse prüfen. Möglichkerweise ist die Hardware auch einfach hoffnungslos veraltet. Falls ja, entweder dedizierte Hardware verwenden, oder upgrade.

4. Prüfen wie groß die zu verarbeitende Datenmenge in der DB ist. Je nach Datenbank sollte evtl mit partitionen oder komprimierten Formaten gearbeitet werden.

5. Zugriffe der Applikation überprüfen. Werden rechnenintensive vergleiche oder große joins verwendet? Hier kann optimiert werden. Prüfen ob häufig verwendete Spalten mit einem Index versehen sind. Zurück zu 4.) (Index kostet Arbeitsspeicher)

Überprüfen der verwendeten Datentypen - nicht alles was zunächst auf Grund der Modellierung sinnvoll erscheint, macht auch in einem Produktivsystem sinn. Da es allerdings nur um ein "kleines" CMS handelt, sollte dies nicht der wesentliche Flaschenhals sein.

6. Versuch macht kluch... Zurück zu 1). Evtl ist die Verwendete Datenbank für den Zweck völlig ungeeignet. Da es nur um ein "kleines" CMS handelt, das scheinbar schon sehr früh auf die Nase fliegt, sollte dies nicht das ausschlaggebende Kriterium sein.

7. Wenn sonst nix hilft: Cache hilft immer. Ist meist aber auch nur ein Zeichen eines verkorksten Designs.

Prinzipielle Möglichkeiten in Reihenfolge des Aufwands für den Entwickler bzw. Kosten:

1. Erstellen von Indizes über Tabellenspalten, die oft zur Filterung eines SELECT Statements (WHERE Klausel) verwendet werden. Nachteil hierbei wäre ein leicht erhöhter Zeitaufwand bei INSERTs, da dabei die Indizes aktualisiert werden müssen.
2. Nutzen des Browser-Caches bzw. cachen der Ergebnisse der Datenbankabfragen, falls möglich.
3. Aufrüsten der Hardware des Rechners, auf dem der Datenbankserver läuft.
4. Auslagern der Datenbank auf eigenen Rechner (falls diese beispielsweise zuvor auf dem gleichen Server wie der Webserver lag). In diesem Fall muss auf eine gute Netzwerkverbindung zwischen Webserver und Datenbankserver geachtet werden.
5. Einführen weiterer Datenbankserver zwecks Lastenverteilung.

Ich würde gern den Kindle gewinnen... ;-)

a) Datenbank-Aufrufe auf so wenig wie möglich Anfragen reduzieren, Joins reduzieren (ggf. vorhandenes DB-Schema dahingehend optimieren)

-> Nachteil: ggf. redundanz im Schema, Vorteil: schnellere Abarbeitung durch verringerte DB-Abfragen

b) Inhalte und Layout trennen, "statische" Templates plus nur die veränderlichen Inhalte aus der DB laden

c) Datenbank-Aufrufe cachen (Frequenz je nach Aktualisierungsbedarf, z.B. einmal am tag, einmal pro Stunde etc.) -> Cache

aus den vorberechneten Abfragen statische Caceh-Seiten erstellen z.B: mit php-Funktion erzeugen und diese Seiten immer nur aus dem Cache laden. Bei vielen gleichen dynamischen Abfragen ebenfalls Ergebnisse vorberechnen und nur bei neuen Anfragen direkte Ausgabe aus der DB, Steuerung der Aktualisierung über Codierung der erzeugten Cache-Seiten

Vorteil: extrem schnelles Laden der Inhalte, da keine oder nur sehr wenige DB-Aufrufe und nach außen nur "statische" Seiten.

Nachteil: Neuberechnung des Cache bei jeder Inhalt-Änderung erforderlich, kann aber automatisiert werden (z.B. mit cron).

d) letzter Schritt: Komprimierung der HttpAufrufe aktivieren (z.B. im Apache gzip für JS, CSS und Bilder), Ablaufdaten festlegen etc. -> sollte stets implementiert werden!

Reihenfolge: wie beschrieben

Hallo,

1. Mein Vorschlag wäre 

• die Datenbanküberhänge optimieren bzw. von Überhängen zu befreien.
• Für Tabellen mit häufigen Anfragen einen sinnvollen index bereistellen, falls nicht vorhanden.
• SQL-Statements überprüfen, ob Performencebremsen in den Abfragen, wie zum Beispiel LIKE '%xyz%' verwendet werden und diese vielleicht optimieren.

Ein anderer Ansatz die Datenbank zu entlasten wäre ein Caching zu installieren, welche das Frontend bereit stellen, so dass nicht immer eine komplette Abfrage der Datenbank geschehen muss.

2.

• Die Datenbanküberhänge zu optimieren würde keine Nachteile mit sich bringen, nur dass man das in rgelmäßigen Abständen tun sollte.
• Indizes zu erstellen bringt für häufige Anfragen einen großen Performencegewinn. Dr Nachteil ist, das bei seltenen Abfragen dagegen es zu Einbußen der Performence kommen kann. Man sollte also die Indizes sinnvoll wählen.
• SQL-Abfragen umzugestalten hat den Vorteil, dass diese schneller werden können, aber auch den Nachteil, dass man vielleicht an der Datenbankstruktur dafür auch was ändern müsste.

Das Caching hat den Nachteil, dass ein Zeitraum definiert werden muss, für welches das Caching gilt. Wenn also dynamische Seiten vorhanden sind, die sich täglich ändern, dann würde man die Neuerungen erst sehen, wenn der Cache gelöscht werden würde. Oder man wartet bis der aktuelle Caching Zeitraum abgelaufen ist.

3. Reihenfolge der Änderung und dem Aufwand:

• Datenbanküberhänge optimieren (per phpMyadmin) (kleiner Aufwand)
• Indizes erstellen (kleiner Aufwand)
• Caching programmieren (mittlerer Aufwand)
• SQL-Abfragen optimieren und gegebenfalls Datenbankstruktur optimieren (großer Aufwand wenn nötig)