Ich habe ein System mit Nginx / PHP-Fpm / Lack / WordPress und Amazon S3.

Jetzt habe ich mir beim Einrichten des Systems viele Konfigurationsdateien angesehen und in allen etwas Ähnliches gefunden:

    /* If the request is for pictures, javascript, css, etc */
    if (req.url ~ "\.(jpg|jpeg|png|gif|css|js)$") {
        /* Remove the cookie and make the request static */
        unset req.http.cookie;
        return (lookup);
    }

Ich verstehe nicht, warum das gemacht wird. In den meisten Beispielen wird NginX auch als Webserver ausgeführt. Die Frage ist nun, warum Sie den Lackcache verwenden sollten, um diese statischen Dateien zwischenzuspeichern.

Es ist für mich viel sinnvoller, nur die dynamischen Dateien zwischenzuspeichern, damit php-fpm / mysql nicht so stark getroffen wird.

Bin ich richtig oder fehlt mir hier etwas?

AKTUALISIEREN

Ich möchte der Frage basierend auf der gegebenen Antwort einige Informationen hinzufügen.

Wenn Sie eine dynamische Website haben, auf der sich der Inhalt tatsächlich stark ändert, ist das Chaching nicht sinnvoll. Wenn Sie beispielsweise WordPress für eine statische Website verwenden, kann dies für längere Zeit zwischengespeichert werden.

Wichtiger für mich ist jedoch der statische Inhalt . Ich habe einen Link mit einigen Tests und Benchmarks für verschiedene Cache-Apps und Webserver-Apps gefunden.

http://nbonvin.wordpress.com/2011/03/14/apache-vs-nginx-vs-varnish-vs-gwan/

NginX ist tatsächlich schneller beim Abrufen Ihrer statischen Inhalte, daher ist es sinnvoller, sie einfach passieren zu lassen. NginX funktioniert hervorragend mit statischen Dateien.

- -

Abgesehen davon befindet sich der statische Inhalt meistens nicht einmal im Webserver selbst. Die meiste Zeit wird dieser Inhalt irgendwo auf einem CDN gespeichert, vielleicht AWS S3, so ähnlich. Ich denke, der Lackcache ist der letzte Ort, an dem statischer Inhalt gespeichert werden soll.

Lack hat einige Vorteile. Der erste Hinweis ist die Reduzierung der Belastung eines Backend-Servers. In der Regel durch Zwischenspeichern von Inhalten, die dynamisch generiert werden, sich jedoch selten ändern (im Vergleich zu der Häufigkeit, mit der auf sie zugegriffen wird). In Ihrem Wordpress-Beispiel ändern sich die meisten Seiten vermutlich nicht sehr oft, und es gibt einige Plugins, die einen Lackcache ungültig machen, wenn sich die Seite ändert (z. B. neuer Beitrag, Bearbeitung, Kommentar usw.). Daher werden Sie auf unbestimmte Zeit zwischengespeichert und bei Änderungen ungültig - was zu einer minimalen Belastung Ihres Backend-Servers führt.

Ungeachtet des verlinkten Artikels würden die meisten Leute vorschlagen, dass Varnish bei korrekter Einrichtung eine bessere Leistung als Nginx erbringt - obwohl (und ich gebe es wirklich nicht gerne zu) meine eigenen Tests zu stimmen scheinen, dass Nginx eine statische Datei schneller als Lack bereitstellen kann ( Zum Glück benutze ich keinen Lack für diesen Zweck. Ich denke, das Problem ist, dass Sie Ihrem Setup eine zusätzliche Ebene hinzugefügt haben, wenn Sie am Ende Lack verwenden. Das Weiterleiten dieser zusätzlichen Ebene an den Backend-Server ist immer langsamer als das direkte Bereitstellen direkt vom Backend aus. Aus diesem Grund kann das Zwischenspeichern von Varnish möglicherweise schneller erfolgen. Sie speichern einen Schritt. Der andere Vorteil liegt auf der Disk-Io-Vorderseite. Wenn Sie den Lack so einrichten, dass er malloc verwendet, schlagen Sie überhaupt nicht auf die Festplatte, wodurch sie für andere Prozesse verfügbar bleibt (und normalerweise die Arbeit beschleunigt).

Ich denke, man würde einen besseren Benchmark brauchen, um die Leistung wirklich zu messen. Durch wiederholtes Anfordern derselben einzelnen Datei werden Dateisystem-Caches ausgelöst, die den Fokus von den Webservern selbst weg verlagern. Ein besserer Benchmark würde die Belagerung mit einigen tausend zufälligen statischen Dateien (möglicherweise sogar aus Ihren Serverprotokollen) verwenden, um realistischen Datenverkehr zu simulieren. Wie Sie bereits erwähnt haben, ist es wohl immer häufiger geworden, statische Inhalte auf ein CDN zu verlagern, was bedeutet, dass Varnish sie wahrscheinlich zunächst nicht bereitstellt (Sie erwähnen S3).

In einem realen Szenario würden Sie wahrscheinlich Ihre Speichernutzung priorisieren - dynamischer Inhalt zuerst, da die Generierung am teuersten ist; dann kleine statische Inhalte (z. B. js / css) und zuletzt Bilder - Sie würden wahrscheinlich keine anderen Medien im Speicher zwischenspeichern, es sei denn, Sie haben einen wirklich guten Grund dafür. In diesem Fall übertrifft Varnish beim Laden von Dateien aus dem Speicher durch Varnish und beim Laden von Dateien von der Festplatte durch Nginx wahrscheinlich die Leistung von Nginx (beachten Sie, dass die Caches von Nginx nur für Proxy und FastCGI vorgesehen sind und diese standardmäßig auf der Festplatte basieren - obwohl dies der Fall ist möglich, nginx mit memcached zu verwenden).

(Mein schneller - sehr rauer, um keine Glaubwürdigkeit zu erhalten - Test ergab, dass Nginx (direkt) am schnellsten war - nennen wir es 100%, Lack (mit Malloc) war etwas langsamer (ca. 150%) und Nginx hinter Lack (. mit Pass) war am langsamsten (ca. 250%). Das spricht für sich - alles oder nichts - und fügt die zusätzliche Zeit (und Verarbeitung) für die Kommunikation mit dem Backend hinzu. Dies schlägt einfach vor, wenn Sie Varnish verwenden und über genügend RAM verfügen Sie können auch einfach alles zwischenspeichern, was Sie können, und es von Varnish aus bereitstellen, anstatt es an nginx zurückzugeben.)

Ich denke, Sie könnten etwas vermissen.

Per Definition ändern sich dynamische Dateien. In der Regel ändern sie sich durch eine Art Datenbankabfrage, die sich auf den Inhalt der Seite auswirkt, die dem Benutzer bereitgestellt wird. Daher möchten Sie keinen dynamischen Inhalt zwischenspeichern. Wenn Sie dies tun, wird es einfach zu statischem Inhalt und höchstwahrscheinlich zu statischem Inhalt mit falschem Inhalt.

Nehmen wir als einfaches Beispiel an, Sie haben eine Seite mit dem Benutzernamen des angemeldeten Benutzers oben auf der Seite. Jedes Mal, wenn diese Seite geladen wird, wird eine Datenbankabfrage ausgeführt, um festzustellen, welcher Benutzername zu dem angemeldeten Benutzer gehört, der die Seite anfordert, um sicherzustellen, dass der richtige Name angezeigt wird. Wenn Sie diese Seite zwischenspeichern würden, würde die Datenbankabfrage nicht stattfinden und alle Benutzer würden den gleichen Benutzernamen oben auf der Seite sehen und es wird wahrscheinlich nicht ihr Benutzername sein. Diese Abfrage muss bei jedem Laden der Seite erfolgen, um sicherzustellen, dass jedem Benutzer der richtige Benutzername angezeigt wird. Es ist daher nicht zwischenspeicherbar.

Erweitern Sie diese Logik auf etwas Problematischeres wie Benutzerberechtigungen, und Sie können sehen, warum dynamischer Inhalt nicht zwischengespeichert werden sollte. Wenn die Datenbank nicht für dynamischen Inhalt getroffen wird, kann das CMS nicht feststellen, ob der Benutzer, der die Seite anfordert, über Berechtigungen zum Anzeigen dieser Seite verfügt.

Der statische Inhalt ist per Definition für alle Benutzer gleich. Daher muss keine Datenbankabfrage stattfinden, um diese Seite für jeden Benutzer anzupassen. Daher ist es sinnvoll, diese zwischenzuspeichern, um unnötige Datenbankabfragen zu vermeiden. Bilder sind ein wirklich gutes Beispiel für statischen Inhalt. Sie möchten, dass alle Benutzer dasselbe Header-Bild, dieselben Anmeldeschaltflächen usw. sehen, sodass sie sich hervorragend für das Caching eignen.

In Ihrem obigen Code-Snippet sehen Sie ein sehr typisches Varnish VCL-Snippet, das das Zwischenspeichern von Bildern, CSS und Javascript erzwingt. Standardmäßig speichert Varnish keine Anforderungen mit einem darin enthaltenen Cookie zwischen. Die Logik ist, dass, wenn die Anforderung ein Cookie enthält, es einen Grund geben muss, warum der Server dieses Cookie benötigt, sodass es im Back-End erforderlich ist und durch den Cache geleitet werden muss. In der Realität hängen viele CMS (Drupal, Wordpress usw.) Cookies an fast alles an, unabhängig davon, ob sie benötigt werden oder nicht. Daher ist es üblich, VCL zu schreiben, um die Cookies aus Inhalten zu entfernen, von denen bekannt ist, dass sie statisch sind, was wiederum dazu führt, dass Varnish zwischengespeichert wird es.

Sinn ergeben?

Für dynamische Inhalte , eigentlich eine Art wie Aktienkurse oft (aktualisiert sich auf eine Sekunde ändern SaaS servervon einem backend server) , aber vielleicht noch häufiger abgefragt werden (von Zehntausenden von subscription clients):

[stock calculation / backend server] ----- [SaaS server] ------ [subscription clients]

In diesem Fall ermöglicht das Zwischenspeichern der SaaS serverAktualisierung pro Sekunde von backend serversdie Erfüllung der Abfragen von Zehntausenden von subscription users.

Ohne einen Cache auf dem SaaS-Server würde dieses Modell einfach nicht funktionieren.

Das Zwischenspeichern statischer Dateien mit Varnish würde sich positiv auf das Auslagern von Nginx auswirken. Wenn Sie viele statische Dateien zwischenspeichern müssen, wird natürlich RAM verschwendet. Varnish hat jedoch eine nette Funktion - es unterstützt mehrere Speicher-Backends für seinen Cache.

Für statische Dateien: Cache auf Festplatte Für alles andere: Cache auf RAM.

Dies sollte Ihnen mehr Einblick in die Implementierung dieses Szenarios geben: http://www.getpagespeed.com/server-setup/varnish-static-files-cache