Skalierung von Nginx, PHP-FPM und MongoDB

8

Ich suche nach dem besten Weg, um eine PHP-Anwendung unter Nginx mit PHP-FPM zu skalieren. Ich betrachte einen Nebenläufigkeit von etwa 1200. Gegenwärtig beginnt alles über 400 zu langsamen Antwortzeiten. Die Antwortgröße ist im Allgemeinen sehr klein, aber einige können ziemlich groß sein. Anfragengrößen sind in der Regel klein, mit Ausnahme einiger weniger.

Es geht schnell aufwärts, bis es stark beansprucht wird. Antwortzeiten krabbeln auf irgendwo zwischen 2 und 50 Sekunden. Bei einer geringen Last variieren die Reaktionszeiten zwischen 100 und 300 Millisekunden.

Server-Setup ist 2 Server. Load Balancer vorne, PHP-FPM, Nginx und MongoDB auf beiden Boxen. Ein Server führt den mongod Master und Arbiter aus, der andere den Slave (sofern kein Failover auftritt). Ich kenne Best Practices mit Mongo, aber ich habe nicht genug Server, um dedizierte Datenbankserver zu haben.

Es ist immer noch ziemlich frei von Stößern und der Last-1-Minuten-Lastdurchschnitt wird niemals über 0,7 liegen. Sie sind 8-Kern-Boxen mit jeweils 16 Gigs RAM, so dass dies nicht der Flaschenhals sein sollte. Mongo schwitzt überhaupt nicht und Nginx und PHP-FPM scheinen auch nicht zu sein. Ich habe Top-Statistiken und MongoDB mit db.serverStatus () überprüft.

Meine Frage ist angesichts meiner Nebenläufigkeit, ob meine Nginx-Fastcgi-Einstellungen korrekt aussehen, und gibt es noch etwas, das ich vermisse, auch wenn es nichts mit Nginx-Einstellungen zu tun hat?

%Vor%

Würde ein niedriger "ulimit -n" das verlangsamen? Mongo verwendet ungefähr 500 bis 600 Verbindungen bei starker Belastung. Ulimit-Einstellungen sind wie folgt:

%Vor%

Zu Ihrer Information: Ich werde "ulimit -n" aufstocken, wenn ich die Parallelität von 1200 testen muss.

Vielen Dank im Voraus.

    
Tres 31.05.2011, 01:00
quelle

2 Antworten

6

Es hat nur ein bisschen Berechnungen bedurft. Da ich 8 Kerne verfügbar habe, kann ich mehr Nginx-Worker-Prozesse generieren:

nginx.conf

%Vor%

Und 16 GB RAM werden für eine statische Menge von PHP-FPM-Arbeitern ein wenig Beinfreiheit geben.

php-fpm.conf

%Vor%

Die Nginx fastcgi Einstellungen blieben gleich. Ich habe wahrscheinlich ein bisschen mehr zwicken todo als die Einstellungen geändert, die akzeptable Nebenläufigkeit blieb gleich, während die Serverlast sank, aber dies scheint den Trick zu tun und ist zumindest ein Ausgangspunkt.

Ein einzelner Server scheint ungefähr mit der Gleichzeitigkeit von 2000 umzugehen, bevor die Last ziemlich hoch wird. ApacheBench beginnt Fehler um 500 Parallelität zu erhalten, daher sollte das Testen mit AB von mehreren Servern aus erfolgen.

Wie David sagte, würde dies idealerweise in etwas geschrieben werden, das leichter skalierbar wäre, aber angesichts des Zeitrahmens, der an diesem Punkt einfach nicht möglich ist.

Ich hoffe, das hilft anderen.

    
Tres 01.06.2011, 00:26
quelle
3

MongoDB ist hier nicht der Flaschenhals. Wenn Sie mehr als 1200 gleichzeitige Verbindungen benötigen, ist PHP-FPM (und PHP im Allgemeinen) möglicherweise nicht das Tool für den Job. Eigentlich kratze das. Es ist NICHT das richtige Werkzeug für den Job. Viele Benchmarks behaupten, dass nginx / PHP-FPM nach 200-500 gleichzeitigen Verbindungen ins Wanken gerät (siehe hier) ).

Ich war letztes Jahr in einer ähnlichen Situation und anstatt das Unkalierbare zu skalieren, schrieb ich die Anwendung in Java mit Kilim Erlang zu schreiben (was Facebook verwendet). Ich schlage vor, dass Sie Ihre Sprachwahl hier neu bewerten und umgestalten, bevor es zu spät ist.

Angenommen, PHP-FPM funktioniert mit 1200 oder sogar 1500 gleichzeitigen Verbindungen "in Ordnung". Was ist mit 2000? 5000? 10000? Absolut, unzweifelhaft, unzweifelhaft unmöglich.

    
David Titarenco 31.05.2011 01:11
quelle

Tags und Links