2016-05-03 7 views
1

Ich bin in einem Blogpost auf diese Frage gestoßen. Es wurde von Mozilla in ihrem Praktikumsinterview gefragt. (Blog Post)Ressourcennutzung eines statischen Webservers

Sie führen einen HTTP-Server (nginx, Apache, etc.), die konfiguriert ist, statische Dateien aus dem lokalen Dateisystem Ihres modernen, Multi-Core-Server zu einem Gigabit-Netzwerk verbunden dienen. Eine Handvoll Clients beginnen, die gleiche 4kb statische Datei so schnell wie möglich anzufordern. Was Systemressource werden Sie zuerst erschöpft sein?

a. CPU
b. Disk/I/O
c. Speicher
d. Netzwerk
e. Andere

Nach meiner Meinung würde nichts davon auf einer modernen Maschine mit Nginx/Apache erschöpft sein. Wird der Webserver eine so kleine Datei nicht zwischenspeichern und nur so weiterreichen? Auch für wiederholte Anfrage kann es leicht einen Not-Modified-Header senden.

Im Fall von Apache, denke ich, da es mehrere Clients durch Launch von Threads behandelt, CPU wird zuerst erschöpft sein, aber für eine "Handvoll" von Clients, das spielt keine Rolle.

Ich wollte wissen, was andere über diese Frage zu sagen haben.

+1

Netzwerk dann CPU. – ardhitama

Antwort

1

Es reeeeeeeeeally hängt ab. 4k ist die magische Größe, die so gut wie alle Caches und Puffer in ihren Standardeinstellungen passt, so dass es leicht (und schnell) ist, herumzugehen. Speicher ist hier kein einschränkender Faktor, da Webserver auf Dateihandles und nicht auf ganzen Dateien arbeiten. In diesem Fall würde ich annehmen, dass sie es im Speicher behalten, aber das wäre eine Datei pro Worker-Instanz, die normalerweise höchstens 4kb * (num_cores + 1) wäre, was eigentlich kein Problem ist.

Man könnte argumentieren, dass entweder Speicher- oder Festplattengeschwindigkeit ein Problem waren. Aber die früheren waren vernachlässigbar, wenn Methoden wie richtig konfiguriert sind, was eine Nullkopie-Methode ermöglicht. Letztere würden sich im Laufe der Zeit amortisieren, sobald eine Kopie der Datei in den Speicher geladen wurde.

Schließlich gibt es die Schnittstelle und die CPU (s). Insgesamt ist die CPU-Zeit tendenziell um einiges günstiger als die Netzwerkzeit. Daher würde ich erwarten, dass die NIC lange vor der CPU den Engpass darstellt - wenn überhaupt.

Die Frage ist ein bisschen unspezifisch auf den Standort der Clients. Wenn sie mit demselben GbE-Netzwerk verbunden sind, könnten sie in der Tat die Macht haben, Ihre NIC mit ihren Anfragen zu sättigen. Wenn nicht, könnte ein Vermittler zum begrenzenden Faktor werden.

Nun nehmen wir an, diese Clients waren in unserem Netzwerk und wir hatten eine Single-homed 10GbE NIC hier, verbunden über 8 Lanes (die ziemlich Standard IMHO ist): PCIe 3.0 x8 ist mit 7.877 MB/s angegeben. A Core i7 3770 hat eine Busgeschwindigkeit von 5GT/s, was auf 8 Spuren zu etwa 8 GB/s führt. Unter der Annahme, dass keine andere E/A-intensive Arbeitslast vorliegt, könnte diese CPU die Netzwerkkarte problemlos sättigen.

Also zusammenfassend: Netzwerk/NIC-Sättigung vor der CPU-Sättigung vor allem anderen.

+0

Würde das Netzwerk wegen HTTP-Overhead sättigen? Ich gehe davon aus, dass der Server nach einiger Zeit damit beginnt, eine Not-Modified-Antwort für Clients zu senden, die dieselbe Datei immer wieder anfordern, aber selbst das würde eine HTTP-Antwort erfordern. –

+0

Nein, ich nahm rohen Verkehr an. A 304 würde erfordern, dass die Clients schlau genug sind, die Header "Wenn-nicht-übereinstimmen" oder "Wenn-Modifiziert-seit" zu senden, was meiner Meinung nach nicht im Sinne der Frage war. Ich denke, dass es hauptsächlich um maximalen Durchsatz ohne irgendwelche Anwendungsprotokolle geht. Außerdem könnte die NIC immer noch mit 304 Antworten gesättigt sein. – DaSourcerer