Drei schnelle Tipps zum Optimieren der Performance von NGINX-/PHP-Applikationen

Schnelle Starthilfe für die Performance Ihrer auf NGINX ausgeführten PHP-Applikationen

Die Performance umfangreicher Websites ist eine komplexe Mischung aus Wissenschaft und Kunst.

Immer mehr Entwickler und IT-Profis stellen fest, dass NGINX die für ihre Anforderungen am besten geeignete PHP-Applikationsperformance bietet. NGINX wurde ursprünglich entwickelt, um das C10K-Problem zu bewältigen:http://www.kegel.com/c10k.html. Es wurde ein Server gesucht, der mehr als 10.000 Benutzer gleichzeitig bedienen konnte.

Auf unterster Ebene, um die sich die wenigsten Entwickler kümmern müssen, bietet NGINX ein hohes Niveau an Optimierung in Bezug auf benutzerdefiniertes Speichermanagement, Puffer-, String-Funktionen usw.

Auf höherer Ebene nutzt NGINX eine ereignisgesteuerte Architektur, so dass HTTP-Aufrufe keine Erstellung oder Terminierung einzelner Betriebssystem-Datensätze oder -Prozesse erfordern, weil dies sehr Ressourcen-intensiv ist.

Wenn Sie von einem anderen Webserver zu NGINX wechseln, sind Sie es vermutlich gewohnt, eine Menge detaillierter Anpassungen vorzunehmen, um die bestmögliche Performance aus Ihrer speziellen Konfiguration heraus zu holen.

Mit NGINX ist keine umfangreiche Anpassung der Konfiguration für mehr Performance mehr erforderlich, da NGINX von Grund auf für maximale Performance ausgelegt ist.

Es sind jedoch eine Reihe von Optionen verfügbar, die eine Anpassung des NGINX-Verhaltens und die optimale Nutzung der zugrunde liegenden Hardware und des Betriebssystems ermöglichen. (Für durchschnittliche Auslastungen sind wahrscheinlich keine weiteren Konfigurationen erforderlich. Wenn Ihre Applikation jedoch Zehn- oder Hunderttausende Verbindungen pro Sekunde verarbeiten muss, sind die im Folgenden beschriebenen Informationen, ein erster Startpunkt für Sie.)

1: Worker-Prozesse anpassen

Moderne Hardware ist mit Multiprozessor-Technik ausgestattet und NGINX kann zahlreiche physische oder virtuelle Prozessoren nutzen.

In den meisten Fällen wird Ihr Webserver-Computer nicht für die Verarbeitung multipler Workloads konfiguriert sein (etwa für die gleichzeitige Bereitstellung von Webserver- und Druckserver-Diensten), daher konfigurieren Sie NGINX möglicherweise so, dass alle verfügbaren Prozessoren verwendet werden, da Worker-Prozesse auf NGINX nicht auf Multithreading basieren.

Sie können feststellen, über wie viele Prozessoren Ihr Linux-Computer verfügt, indem Sie ein Terminal öffnen und den folgenden Befehl ausführen:
cat /proc/cpuinfo | grep processor

Auf meinem System gibt der Befehl Folgendes aus:

Die Standard-Konfigurationseinstellung für Ihre NGINX-Installation finden Sie unter: /etc/nginx/nginx.conf

Auf meinem System enthält die Datei nginx.conf den folgenden Eintrag für Worker-Prozesse:

worker_processes 1;

Mein Computer hat also 2 verfügbare Prozessoren, NGINX ist jedoch so konfiguriert, dass nur einer verwendet wird.

Dies lässt sich erweitern, indem der Eintrag der Konfigurationsdatei wie folgt geändert wird:

worker_processes 2;

Wenn es bei Ihren Anwendungen hauptsächlich um weniger leistungsintensive Anforderungen geht, kann es für Sie die richtige Wahl sein, die Anzahl der Worker gleich der Anzahl der Prozessoren festzulegen. Wenn Ihre Applikation jedoch zahlreiche Features umfasst, bei denen Anforderungen viel Wartezeit beanspruchen (z. B. längere Datenträger-E/A), dann sollten Sie wahrscheinlich besser die Einstellung für Worker höher wählen.

worker_processes 4;

2: „Worker-Connection“ bei hohem Datenverkehr erhöhen

Eine Worker-Connection begrenzt effektiv die Anzahl der Verbindungen, die jeder Worker-Prozess gleichzeitig bereitstellen kann. Die Standardanzahl für Worker-Verbindungen ist 1024, wie in einem Abschnitt der Datei nginx.conf wie folgt festgelegt:

events { 
   worker_connections 1024;
}

Das scheint auf den ersten Blick viel zu sein, wenn man aber bedenkt, dass moderne Browser 2 bis 8 Serververbindungen öffnen können, und das Keep Alive-Timeout standardmäßig 65 oder 75 beträgt (je nach Installation), kann man sich leicht vorstellen, dass die tatsächlich realisierte Anzahl an Verbindungen pro Sekunde stark reduziert werden kann.

Diese Zahl mag für viele Sites geeignet sein, jedoch können High Traffic Sites eine höhere Zahl an Verbindungen gut vertragen und weisen sicherlich die Ressourcen auf, die für die Unterstützung einer höheren Verbindungsanzahl erforderlich sind.

3: Mithilfe des Zend Server-Dashboards lange andauernde Requests und Performance-Probleme ermitteln

Auf stak ausgelasteten Servern mit anspruchsvollen Applikationen kann es sich als schwierig erweisen, herauszufinden, warum unsere Applikationen, die doch problemlos funktionieren SOLLTEN, es eben nicht tun.

Zend Server zeichnet sich durch zahlreiche Funktionen aus, mit denen sich feststellen lässt, was tatsächlich auf unseren Servern passiert.

Manchmal funktionieren Hardware, Betriebssystem und Server völlig problemlos, jedoch ist unser Code irgendwie nicht in Ordnung, was häufig zu schwer vorhersehbaren Ergebnissen führt.

Sehen Sie sich die folgende Zend Server Dashboard-Ansicht an:

Sie zeigt, dass eine bestimmte URL-Anforderung außergewöhnlich lange für eine Reaktion benötigt. Bei der URL handelt es sich um eine, die ein Benutzerprofil auf dieser Community-Site anzeigen soll.

Da Benutzerprofile „benutzerdefiniert“ sind und Bilder sowie gewisse Beschreibungen enthalten können, ist es nun möglich, das spezielle Profil zu untersuchen, um das Problem zu ermitteln und den unerwünschten Inhalt zu entfernen. Anschließend kann eine Programmänderung durchgeführt werden, die die Aufnahme von Inhalten dieser Art in Zukunft verhindert (z. B. Bilddateien über einer bestimmten Größe, Remote-Verknüpfungen usw.)

Wenn Sie mehr über Performance-Tuning erfahren möchten, finden Sie im Folgenden einige erste Starthilfen.