Ein dedizierter Nginx-Server für CSS/JS/Bilder ist total cool, aber Bilder werden langsam geladen. Warum?

Ein dedizierter Nginx-Server für CSS/JS/Bilder ist total cool, aber Bilder werden langsam geladen. Warum?

Wir haben in unserem Unternehmen drei dedizierte Server. Auf einem läuft Nginx und er fungiert als Webserver (PHP), ein anderer verarbeitet MySQL und Memcached und der dritte wird zum Bereitstellen statischer Dateien verwendet: CSS, JS und Bilder.

Alle Server weisen unter New Relic eine hervorragende Leistung auf, insbesondere der Server für statische Dateien:

  • CPU dauerhaft unter 10%
  • Die empfangene Netzwerk-E/A ist sehr niedrig, die übertragene liegt bei maximal 10 Mbit/s, aber der MySQL-Server hat dieselben Spezifikationen und erreicht regelmäßig Spitzenwerte von 20 Mbit/s, also bezweifle ich, dass dies ein Problem darstellt.
  • Durchschnittliche Auslastung unter 0,5

Das Problem besteht darin, dass das Laden der Bilder (die zwischen 100 und 200 KB groß sein können) zu Spitzenzeiten bei manchen Benutzern offenbar sehr lange dauert (viele, viele Sekunden, manchmal sogar bis zu einer Minute, während es normalerweise höchstens ein paar Sekunden dauert).

Irgendeine Idee, was wir tun könnten? Im Idealfall sollte dies nicht passieren, wenn weder CPU, RAM noch Bandbreite irgendeine Art von Grenze erreicht haben.

Gibt es wichtige Nginx-Konfigurationsparameter, die wir uns ansehen (und wahrscheinlich ändern) sollten?

Antwort1

Mir fallen da zwei Möglichkeiten ein.

  1. Ihre Festplatte hat ihr E/A-Limit erreicht.
  2. Sie haben das Arbeitsthreadlimit in nginx erreicht. Sehen Sie sich dieArbeiter_*Konfigurationsparameter aus dem Core-Modul undArbeiterverbindungenaus dem Modul „Events“, um herauszufinden, wie Sie dies steigern können. Die Standardeinstellung ist ein einzelner, einfädiger Arbeitsprozess. Wenn Sie also auf einer Plattform mit mehreren CPUs arbeiten, sollten Sie dies unbedingt steigern. Selbst wenn Sie auf einer Maschine mit nur einer CPU arbeiten, profitieren Sie von einer Steigerung dieser Zahl auf einer Maschine, die statische Ressourcen bereitstellt, da Sie lange vor allem anderen an die Festplatten-E/A gebunden sind und andere Threads weitere Anfragen empfangen und verarbeiten können, während der erste darauf wartet, Daten von der Festplatte zu erhalten.

Antwort2

Wir könnten hier den ganzen Tag sitzen und raten, wo Ihr Engpass ist, aber einige allgemeinere Ratschläge werden Ihnen helfen, ihn viel schneller selbst zu finden.

jeffatrackaid schreibtdiese Antwort gesternDas ist eine prägnantere Version vonwas ich vor einiger Zeit geschrieben habe. Ich würde vorschlagen, diese zuerst zu lesen, um zu verstehen, wie die Leistungsfehlerbehebung funktioniert.

In Ihrem Fall würde ich zunächst Firebug verwenden, um zu ermitteln, welcher Teil der Anfrage während der Spitzenzeiten langsam ist. Dies sollte die Bandbreite ausschließen, wenn die Bandbreite nicht das eigentliche Problem ist. Sehen Sie im Abschnitt „Net“ von Firebug nach, welcher Teil der Anfrage sich zwischen den schnellen und den langsamen Zeiten ändert.

Anschließend würde ich während einer dieser langsamen Zeiten ein Strace mit -tden Optionen und auf einem der Nginx-Worker ausführen. Die Analyse der Ausgabe davon sollte Ihnen genau zeigen, wo Nginx langsam wird. Es ist nützlich, die Strace-Ausgabe in eine Datei zu schreiben und dann oder auf der Datei zu verwenden, um Systemaufrufe zu identifizieren, die lange gedauert haben.-Tlessgrep

-cMöglicherweise können Sie die Strace-Option nutzen .

Wenn Sie die langsamen Systemaufrufe identifiziert haben, kann es noch etwas Arbeit sein, herauszufinden, welcher Nginx-Parameter geändert werden muss, aber Sie sollten auf einem guten Weg sein. Bitte kommen Sie zurück und stellen Sie spezifischere Fragen, wenn Sie bei diesem Teil Hilfe benötigen.

Wenn es sich um einen dateibasierten Systemaufruf handelt, schauen Sie unbedingt in der Ablaufverfolgung nach hinten, bis Sie die Datei finden, auf die gewartet wurde. Das ist ein wichtiger Hinweis.

verwandte Informationen