Wie wir langsame API-Anfragen auf einer WordPress-Website gefunden haben

Wir entwickeln eine Bildungsplattform, die Ihnen ermöglicht:

Alle Aktionen mit Inhalten beinhalten große Datenmengen und aktive Kommunikation mit der Datenbank.

Einige Zeit nach dem Teststart des Projekts stellten wir fest, dass das Laden, Speichern und Klonen von Lektionen zu viel Zeit in Anspruch nahm. Dies veranlasste uns, das Problem im Detail zu untersuchen und auf der Grundlage der identifizierten Engpässe nach Lösungen zu suchen.

Technischer Stack der Plattform

Wir wählten Vue.js als Frontend-Framework, was es uns ermöglichte, die Benutzeroberfläche der Hauptfunktionalität des Projekts responsiv zu gestalten. Das betrifft die Funktionalität des Editors und die Präsentation von Lektionen. Die Besonderheit der Implementierung lag im Aufbau der Kommunikation zwischen Client und Server in Form von API-Anfragen. Die Anfragen werden aufgrund des Ansatzes zur Verwaltung von Beiträgen im gewählten CMS (WordPress) in großer Anzahl gesendet, sodass eine Reduzierung der Anfragenanzahl nicht möglich war. Parallelisierung und asynchrone Ausführung ermöglichten es jedoch, die gewünschten Leistungsergebnisse zu erzielen.

Server

Die skalierbare Architektur auf Basis von AWS ermöglichte es uns sicherzustellen, dass die Serverkapazität ausreichte, um einen großen Benutzerstrom zu verarbeiten und bei Spitzenlasten eine angemessene Leistung zu gewährleisten. Diesmal erwies sich die Situation jedoch als so unvorhersehbar, dass horizontale und vertikale Skalierung keine besseren Ergebnisse brachten.

Die ursprüngliche Problembeschreibung erklärte, dass der entwickelte Frontend-Lektionseditor sowie die Seiten zur Bearbeitung von Einträgen im Administrationsbereich zu lange zum Laden benötigten. Das Erste, was uns in den Sinn kam, war, dass das Admin-Panel in React geschrieben war und API-Anfragen verwendete, um Kategorien, Taxonomien und Tags abzurufen. Unser Lektionseditor verwendete ebenfalls API-Anfragen zum Lesen und Schreiben von Lektionsinhalten.

Nach der Untersuchung des “Netzwerk”-Tabs in den Browser-Entwicklertools stellten wir fest, dass alle asynchronen Anfragen an den Server wie erwartet funktionierten, mit Ausnahme der API-Anfragen, die jeweils mindestens 3 Sekunden dauerten. Eine detaillierte Ansicht der Anfrage zeigte ein hohes TTFB (Time to First Byte), was auf eine Verlangsamung im Backend oder auf der Serverseite hindeutete.

Es wurde empirisch ermittelt, dass unabhängig davon, welche Aktionen der API-Endpunkt ausführte, das Ergebnis immer gleich war – mindestens 3 Sekunden für die Verarbeitung, mit Zunahme der Datenbank auf 5-6 Sekunden ansteigend.

Besonders auffällig war, dass die Produktionsumgebung die langsamste Phase darstellte, da sie die größte Datenmenge enthielt – Beiträge und Metadaten für die Beiträge. Um zu überprüfen, ob die Ladegeschwindigkeit mit zunehmendem Datenvolumen abnahm, wurde die Produktionsdatenbank in einer Testumgebung eingesetzt, wo wir eine Bestätigung dieser Theorie erhielten.

Wir stellten uns ständig dieselbe Frage:

Warum wird die Geschwindigkeit einer API-Anfrage, die bei der Verarbeitung interner Logik keine Datenbank verwendet, von der Größe der Datenbank beeinflusst?

So wurde beschlossen, die verwendeten Plugins nacheinander zu deaktivieren, um ihren Einfluss auf die Ladegeschwindigkeit zu ermitteln. Das erste Ergebnis kam nach der Deaktivierung des LearnDash-Plugins, dessen Inhalt die Grundlage der gesamten Plattform bildet. Die Verarbeitungsgeschwindigkeit von API-Anfragen war sofort 40-mal schneller! Da jedoch die Möglichkeit, das Plugin aufzugeben und nach Alternativen zu suchen, nicht in Frage kam, wurde die Untersuchung fortgesetzt.

Beim Durchgehen des LearnDash-Plugin-Codes, beginnend mit der Initialisierung und den eingebundenen Dateien, kommentierten wir große Codeblöcke aus und überprüften deren Auswirkung auf die Geschwindigkeit. Besondere Aufmerksamkeit galt der REST-API-Funktionalität, wo der erste Hook auftrat. Durch vollständiges Auskommentieren der REST-API-Nutzung durch das Plugin wurde das Problem behoben. Dies war jedoch ebenfalls keine praktikable Lösung. Im weiteren Verlauf fanden wir schließlich den Grund für dieses Verhalten.

Das LearnDash-Plugin verwendete den WordPress-Hook rest_api_init nicht nur, um eigene API-Endpunkte und Felder zu registrieren, sondern auch, um zusätzliche Controller mit Logik einzubinden, von denen einer eine umfangreiche, nicht optimierte sequenzielle Abfrage aus mehreren Datenbanktabellen enthielt. Daher wurde diese Abfrage unabhängig von der Route-API-Funktion jedes Mal ausgeführt, wenn wir eine API-Anfrage an den Server sendeten (und wie bereits erwähnt, werden viele Anfragen gesendet). Der Grund für diesen Ansatz war unklar, jedoch wurde eine Anfrage zur Klärung an die LearnDash-Plugin-Entwickler gesendet, in der Hoffnung auf eine Lösung in zukünftigen Versionen.

Das Vorhandensein eines Filters im Plugin-Code (bereitgestellt vom LearnDash-Support-Team als Antwort auf unser Ticket) half dabei, die Situation problemlos zu lösen und die Ausgrenzung von mit Logik geladenen Controllern vor dem Laden zu ermöglichen. Genau das haben wir für den problematischen Controller getan.

Antwort vom

LearnDash Entwicklerteam

Wir haben dies aktualisiert und planen, die Änderungen im nächsten Hauptrelease zu veröffentlichen.

Danke für Ihr Feedback – das Entwicklerteam hat dies berücksichtigt und eigene Verbesserungen hinzugefügt.