Verbesserung der Drupal-Leistung um 80%

Drupal ist ein wenig bekannt für die Anzahl der Datenbankabfragen, die gegen eine Datenbank ausgeführt werden. Wenn es Tausende von gleichzeitigen Benutzern gibt, die bedient werden müssen, kann die Datenbank schnell zu einem großen Engpass werden. Dies war der Fall bei http://kwestiasmaku.com, einer sehr beliebten Website mit Rezepten. Die Website wird von Millionen von Kochbegeisterten besucht.

Als wir unsere Zusammenarbeit mit KwestiaSmaku begannen, konzentrierten wir uns zunächst auf die Hinzufügung neuer Funktionen und Features zur Website. Schließlich zwang uns jedoch die wachsende Popularität, die Anwendung aus dem Blickwinkel der Leistung zu betrachten.

Unsere Drupal-Entwickler haben viele Leistungsoptimierungen unterschiedlichster Art durchgeführt, und unten ist nur ein Beispiel dessen, was wir oft erreichen.

Analyse

Um die Leistungsengpässe anzugehen, wollten wir zuerst verstehen, was die größte Last verursacht. Normalerweise gibt es zwei Möglichkeiten:

1. Der Code der Website ist ineffizient (er kann offensichtliche Fehler enthalten, die zusätzliche unnötige Datenbankabfragen verursachen, manchmal in Schleifen und Iterationen wiederholt).
2. Es gibt möglicherweise keine direkten Fehler. Sie können alle Kriterien erfüllen, um die Website auf die Drupal-Weise zu erstellen und dabei alle bewährten Praktiken zu befolgen, aber bei einem bestimmten Benutzeraufkommen dennoch auf einen Engpass stoßen (normalerweise mit Bezug zur Datenbank).

Wir haben KwestiaSmaku nicht gebaut, sondern die Wartung übernommen, daher wollten wir zunächst sicherstellen, dass benutzerdefinierte Module keine Überraschungen enthielten, die in Option Nummer eins passen würden. Dafür haben wir x-debug profiler und blackfire verwendet. Diese Tools sind in vielen Aspekten sehr ähnlich, bieten jedoch jeweils einige einzigartige Optionen. Beide erlauben Ihnen zu beobachten, wie die Seite generiert wird und wie viel Zeit für jede Funktion im Aufrufstapel aufgewendet wird.

Eine Sache, die wir mit den Tools gefunden haben, war das browsercap-Modul, das installiert war, aber nicht für irgendetwas verwendet wurde. Es führte jedoch bei jeder Seitenanfrage umfangreiche Datenbankabfragen aus. Abgesehen davon fanden wir einige suboptimale Dinge, die wir beheben konnten, aber nichts so Wesentliches, um uns aus dem Datenbankengpass herauszubekommen. Wir mussten zu Phase 2 übergehen - die Leistungsoptimierung.

Eines der besten Tools, das Ihnen hilft zu verstehen, was mit Ihrem Server passiert, ist New Relic. Die gesammelten Daten bestätigten, was wir von Anfang an vermutet hatten: Die schwerwiegendsten und zeitaufwändigsten Abfragen wurden vom Views-Modul generiert. KwestiaSmaku verwendete ziemlich komplexe Views, um Listen von Rezepten auf der Startseite und in Kategorien anzuzeigen. Das Views-Modul ist großartig, aber es ist ein zweischneidiges Schwert - Sie können schnell komplexe Listen von Einträgen erstellen, aber Sie erhalten dabei große und schwere Datenbankabfragen mit mehreren JOINS und verschachtelten Unterabfragen. 

Search API Solr

Abgesehen davon, dass wir einen zeitbasierten Cache festlegen oder eine Slave-Datenbank erstellen und diese verwenden, um die View zu speisen, konnten wir nicht viel tun, um die vom Views-Modul erstellen Datenbankabfragen zu optimieren. Um dies zu umgehen, schlugen wir vor, die gesamte View von einer Datenbankabfrage zu einem Index basierend auf Apache Solr zu verschieben. Wir verwendeten Solr bereits, um das Suchfenster der Website zu betreiben, sodass wir nur einen weiteren Index erstellen mussten, der die Daten hält, die wir zur Anzeige auf den Rezeptlisten benötigten.

Mit Solr haben wir die umfangreichen Datenbankabfragen entfernt und die Last auf der Datenbank erheblich reduziert. Dies ist auf den New Relic Grafiken aus diesem Zeitraum deutlich sichtbar. Wir führten die Änderung in der Nacht vom 7. auf den 8. November durch und bereits am folgenden Tag war die Datenbank deutlich weniger belastet. 

Am 8. November deaktivierten wir das browsercap-Modul, das immer noch eine ineffiziente Abfrage ausführte (die blaue Farbe auf dem Diagramm)

Dank der Änderung von der Datenbank zu Apache Solr Index konnten wir die ineffizientesten und zeitaufwändigsten Datenbankabfragen vollständig eliminieren. Die längsten Abfragen sind jetzt fünfmal kürzer als vor der Änderung (die scharfen Ticks in den Diagrammen sind nächtliche Sicherungen)

Dank unserer Optimierungen kann kwestiasmaku.com weiter wachsen, ohne dass ein Serverwechsel oder die Implementierung einer komplexen Serverinfrastruktur erforderlich ist. 

Wenn Sie eine Website haben, die Leistungsprobleme aufweist, lassen Sie von sich hören. Im Rahmen unserer Drupal-Entwicklungsdienste verbessern wir häufig die Website-Leistung.