Wie viel RAM für die Bereitstellung starker statischer Inhalte?

Ich möchte einen Server für meinen statischen Inhalt erstellen.
Ich muss einige 3-10 MB-Dateien bereitstellen - viel. (Ich werde auch einige .js und .css und Bilder von meinen Websites auf diesen Server stellen).
Ich dachte an Nginx und G-WAN ( http://trustleap.com/ ).
Was ich nicht weiß, ist, welche Ressourcen für die Bereitstellung statischer Inhalte benötigt werden? Wie viel RAM wird für jede Dateiübertragung verwendet?
Wenn ich mit einem 256 MB (oder 512 MB) VPS mit gutem Port und großem Band unterwegs bin, wie viele Treffer / Sekunden kann ich bedienen (3-10 MB Dateien)? (Ich weiß, "es kommt darauf an" - aber bitte geben Sie mir eine grobe Schätzung basierend auf Erfahrung oder Theorie).
Es gibt nicht viele Dateien, die nur oft heruntergeladen werden - sollte ich das Caching in Betracht ziehen, oder wird nur mein Speicher verwendet, der für die Bereitstellung von Treffern benötigt wird?

Wenn Sie nginx verwenden, sprechen Sie nur von wenigen KB Overhead pro aktiver Verbindung. Wenn Sie so etwas wie Apache verwenden, haben Sie einen Thread pro Verbindung, was Hunderte von KB oder sogar Megabyte pro Verbindung bedeutet.

Nginx unterstützt jedoch keine asynchronen Festplatten- E / A unter Linux (da asynchrone Festplatten- E / A unter Linux grundsätzlich schrecklich kaputt sind). Sie müssen also viele Nginx-Worker-Prozesse ausführen, da jeder Lesevorgang möglicherweise einen gesamten Worker-Prozess blockieren kann. Wenn Sie FreeBSD verwenden, ist dies kein Problem, und Nginx wirkt Wunder mit asynchronen Festplatten- und Netzwerk-E / A. Möglicherweise möchten Sie jedoch bei Apache bleiben, wenn Sie Linux für dieses Projekt verwenden.

Das Wichtigste ist jedoch der Festplatten-Cache und nicht der von Ihnen ausgewählte Webserver. Sie möchten viel freien Arbeitsspeicher, damit das Betriebssystem diese Dateien zwischenspeichert und sehr schnell liest. Wenn das "Hot Set" mehr als 8 GB beträgt, sollten Sie stattdessen weniger RAM und eine kostengünstige SSD in Betracht ziehen, da das Kosten-Nutzen-Verhältnis wahrscheinlich besser ist.

Schließlich sollten Sie ein CDN verwenden, um dies auszulagern und einen wirklich günstigen Server zu erhalten. Das Bereitstellen statischer Dateien ist das, was sie tun, und das sehr schnell und sehr billig. SimpleCDN hat die niedrigsten Preise, aber MaxCDN, Rackspace, Amazon usw. sind große Player am unteren Ende des CDN-Bereichs.

Wenn das Betriebssystem den heißen Teil des Inhalts in RAM zwischenspeichern kann, verwendet es die Festplatte nicht und erledigt die Dinge sehr schnell. Hunderte von Anforderungen pro Sekunde sollten auf einem VPS möglich sein. Sie werden das Netzwerk höchstwahrscheinlich lange überlasten, bevor Sie auf CPU-Grenzwerte stoßen.

Wenn der Inhalt nicht in den RAM passt, kommt die Festplatten-E / A (Suche, Durchsatz, Dateisystemfragmentierung) ins Spiel und die Gleichung ändert sich.

Der Webserver fügt pro Client einen Speicher-Overhead hinzu, aber nginx kann dies in wenigen Kilobyte pro Verbindung tun.

Hoffe, diese Hinweise können Ihnen helfen.

Welche Ressourcen werden für die Bereitstellung statischer Inhalte benötigt? Wie viel RAM wird für jede Dateiübertragung verwendet?

Erstens verwendet G-WAN v4.7 + bei gleicher Anzahl von Mitarbeitern beim Start weitaus weniger RAM als Nginx:

> Server 'nginx' process topology:
---------------------------------------------
  6] pid:21228 Process RAM: 0.77 MB
  5] pid:21229 Process RAM: 2.44 MB
  4] pid:21230 Process RAM: 2.44 MB
  3] pid:21231 Process RAM: 2.44 MB
  2] pid:21232 Process RAM: 2.44 MB
  1] pid:21233 Process RAM: 2.44 MB
  0] pid:21234 Process RAM: 2.44 MB
---------------------------------------------
Total 'nginx' server footprint: 15.39 MB

> Server 'gwan' process topology:
---------------------------------------------
  6] pid:6054 Thread
  5] pid:6053 Thread
  4] pid:6052 Thread
  3] pid:6051 Thread
  2] pid:6050 Thread
  1] pid:6049 Thread
  0] pid:5839 Process RAM: 2.19 MB
---------------------------------------------
Total 'gwan' server footprint: 2.19 MB

G-WAN verwendet Threads (normalerweise einen pro Kern), Nginx verwendet Prozesse (normalerweise einen pro Kern) und Prozesse verursachen mehr Overhead, erfordern eine Synchronisierung über den gemeinsam genutzten Speicher usw. Beide verwenden das "asynchrone" Modell der Ereignisbehandlung.

Beachten Sie, dass G-WAN hier automatisch auf mehr als 1 Million gleichzeitige Verbindungen anwachsen kann, während Nginx auf seine worker_connectionsEinstellungen beschränkt ist (im obigen ab.c- Test nur auf 4096 definiert ).

Was mir nicht klar ist, ist, ob es pro Verbindung Speicher-Overhead gibt: dh ob Nginx oder Gwan für jeden Treffer Speicher verbrauchen?

Die Kurzgeschichte besagt, dass G-WAN v4.7 + (bei dem das In-Memory-Caching standardmäßig deaktiviert ist) für alle Dateigrößen viel weniger RAM als Nginx verbraucht und gleichzeitig mehr Anforderungen pro Sekunde bearbeitet.

Die lange Geschichte ist, dass Nginx selbst bei neuen HTTP-Keep-Alived-Anforderungen immer mehr Speicher verbraucht, die Speichernutzung von G-WAN jedoch für HTTP-Keep-Alived-Anforderungen stabil bleiben kann und weit weniger wächst als bei Nginx mit Non-Keep-Alived Anfragen.

Unser weighttp-Wrapper ab.c misst den Speicherverbrauch der Serveranwendung und des Systems für die Dauer des Tests. Und es zeigt, dass Nginx das System in Bezug auf den Speicherressourcenverbrauch stärker belastet.

Dies liegt an der Art und Weise, wie jeder Webserver Anforderungen verarbeitet und Speicher zuweist.

Wenn ich 10 Anfragen für eine 5-MB-Datei gleichzeitig habe, bedeutet dies, dass 50 MB Speicher für die Bereitstellung verwendet werden? Vielleicht + Speicher für Threads (Ich weiß nicht, ob Nginx oder Gwan Threads für jede Verbindung verwenden).

Beide Server (Nginx und G-WAN) verwenden, sendfile()sodass der Kernel (und nicht die Anwendung) die Ressourcen für E / A zuweist.

Die Webserver weisen weiterhin Ressourcen zu, dies dient jedoch dazu, den Kontext jeder Verbindung beizubehalten, anstatt die Datenträger-E / A zu puffern.

Daher hängt der Momory-Verbrauch von der Größe der bei jedem sendfile()Aufruf gesendeten Dateiblöcke ab und nicht direkt von der Gesamtgröße der Datei.

Die Größe der Totfiles hat einen langfristigen Einfluss auf hohe Parallelitäten. Dies liegt jedoch an der Anzahl der Chunks, die vom Kernel zwischengespeichert werden müssen.

Wenn Sie weitere Fragen haben, schreiben Sie uns eine E-Mail an G-WAN. Wir haben stark in CDN-ähnliche Anwendungen investiert.