C++ Socket Server – CPU kann nicht ausgelastet werden

Ich habe einen Mini-HTTP-Server in C++ mit boost::asio entwickelt und teste ihn jetzt mit mehreren Clients und konnte die CPU nicht annähernd auslasten. Ich teste auf einer Amazon EC2-Instanz und erhalte etwa 50 % Auslastung einer CPU, 20 % einer anderen, und die verbleibenden zwei sind im Leerlauf (laut htop).

Einzelheiten:

• Der Server startet einen Thread pro Kern
• Anfragen werden empfangen, geparst, verarbeitet und Antworten geschrieben
• Die Anforderungen beziehen sich auf Daten, die aus dem Speicher gelesen werden (schreibgeschützt für diesen Test).
• Ich “lade” den Server mit zwei Maschinen, auf denen jeweils eine Java-Anwendung ausgeführt wird, die 25 Threads ausführt und Anforderungen sendet
• Ich sehe einen Durchsatz von etwa 230 Anfragen/Sek Anwendung Anfragen, die sich aus vielen HTTP-Anfragen zusammensetzen)

Worauf sollte ich also achten, um dieses Ergebnis zu verbessern? Da die CPU größtenteils im Leerlauf ist, möchte ich diese zusätzliche Kapazität nutzen, um einen höheren Durchsatz zu erzielen, sagen wir 800 Anfragen/Sek. oder was auch immer.

Ideen, die ich hatte:

• Die Anfragen sind sehr klein und werden oft in wenigen Millisekunden erfüllt. Ich könnte den Client so ändern, dass er größere Anfragen sendet/verfasst (möglicherweise mithilfe von Batching).
• Ich könnte den HTTP-Server so ändern, dass er das Select-Entwurfsmuster verwendet, ist das hier angemessen?
• Ich könnte einige Profile erstellen, um zu versuchen zu verstehen, was die Engpässe sind/sind

boost::asio ist nicht so Thread-freundlich, wie Sie hoffen würden – es gibt eine große Sperre um den epoll-Code in boost/asio/detail/epoll_reactor.hpp, was bedeutet, dass jeweils nur ein Thread den epoll-Systemaufruf des Kernels aufrufen kann . Und bei sehr kleinen Anforderungen macht dies den Unterschied (was bedeutet, dass Sie nur ungefähr Single-Thread-Leistung sehen werden).

Beachten Sie, dass dies eine Einschränkung dafür ist, wie boost::asio die Linux-Kernel-Einrichtungen verwendet, nicht unbedingt den Linux-Kernel selbst. Der epoll-Systemaufruf unterstützt zwar mehrere Threads, wenn flankengetriggerte Ereignisse verwendet werden, aber es richtig hinzubekommen (ohne übermäßiges Sperren) kann ziemlich schwierig sein.

Übrigens habe ich einige Arbeiten in diesem Bereich durchgeführt (Kombination einer vollständig multithreaded, kantengetriggerten Epoll-Ereignisschleife mit vom Benutzer geplanten Threads/Fasern) und einige Codes unter dem zur Verfügung gestellt nginetd Projekt.

Da Sie EC2 verwenden, sind alle Wetten ungültig.

Probieren Sie es mit echter Hardware aus, und dann können Sie vielleicht sehen, was passiert. Der Versuch, Leistungstests in VMs durchzuführen, ist im Grunde unmöglich.

Ich habe noch nicht herausgefunden, wofür EC2 nützlich ist, wenn jemand es herausfindet, lassen Sie es mich bitte wissen.

Aus Ihren Kommentaren zur Netzwerkauslastung
Sie scheinen nicht viel Netzwerkbewegung zu haben.

3 + 2.5 MiB/sec ist um die 50Mbps Baseballstadion (im Vergleich zu Ihrem 1-Gbit/s-Port).

Ich würde sagen, Sie haben eines der folgenden zwei Probleme:

1. Unzureichende Arbeitsbelastung (niedrige Anfragerate Ihrer Kunden)
   • Blockierung im Server (gestörte Antwortgenerierung)

Anschauen cmeerw‘s Notizen und Ihre CPU-Auslastungszahlen
(Leerlauf bei 50% + 20% + 0% + 0%)
Es scheint höchstwahrscheinlich eine Einschränkung in Ihrer Serverimplementierung zu sein.
Ich stimme zu cmeerwAntwort von (+1).

230 Anfragen/Sek. scheinen für solch einfache asynchrone Anfragen sehr niedrig zu sein. Daher ist die Verwendung mehrerer Threads wahrscheinlich eine verfrühte Optimierung – sorgen Sie dafür, dass es in einem einzigen Thread richtig funktioniert und optimiert wird, und prüfen Sie, ob Sie sie noch benötigen. Nur die Beseitigung unnötiger Sperren kann die Dinge beschleunigen.

Dieser Beitrag hat einige Details und Diskussionen zu E/A-Strategien für die Leistung im Webserver-Stil um 2003. Hat jemand etwas Neueres?

ASIO eignet sich gut für kleine bis mittlere Aufgaben, aber es ist nicht sehr gut darin, die Leistung des zugrunde liegenden Systems zu nutzen. Weder Raw-Socket-Aufrufe noch IOCP unter Windows, aber wenn Sie erfahren sind, werden Sie immer besser als ASIO sein. In jedem Fall gibt es bei all diesen Methoden eine Menge Overhead, nur mehr bei ASIO.

Für was es wert ist. Die Verwendung von Raw-Socket-Aufrufen auf meinem benutzerdefinierten HTTP kann 800.000 dynamische Anforderungen pro Sekunde mit einem 4-Kern-I7 bedienen. Es wird aus dem RAM bedient, wo Sie für dieses Leistungsniveau sein müssen. Bei diesem Leistungsniveau verbrauchen der Netzwerktreiber und das Betriebssystem etwa 40 % der CPU. Mit ASIO kann ich etwa 50 bis 100.000 Anfragen pro Sekunde erhalten, die Leistung ist ziemlich variabel und hauptsächlich in meiner App gebunden. Der Beitrag von @cmeerw erklärt meistens warum.

Eine Möglichkeit, die Leistung zu verbessern, besteht darin, einen UDP-Proxy zu implementieren. Indem Sie HTTP-Anforderungen abfangen und sie dann über UDP an Ihren Backend-UDP-HTTP-Server weiterleiten, können Sie eine Menge TCP-Overhead in den Betriebssystemstapeln umgehen. Sie können auch Frontends haben, die UDP selbst durchleiten, was selbst nicht allzu schwierig sein sollte. Ein Vorteil eines HTTP-UDP-Proxys besteht darin, dass Sie jedes gute Frontend ohne Änderungen verwenden und nach Belieben ohne Auswirkungen austauschen können. Sie brauchen nur ein paar Server mehr, um es zu implementieren. Diese Änderung an meinem Beispiel senkte die CPU-Auslastung des Betriebssystems auf 10 %, was meine Anfragen pro Sekunde auf etwas mehr als eine Million an diesem einzelnen Backend erhöhte. Und FWIW Sie sollten immer ein Frontend-Backend-Setup für jede performante Site haben, da die Frontends Daten zwischenspeichern können, ohne das wichtigere Backend für dynamische Anforderungen zu verlangsamen.

Die Zukunft scheint darin zu bestehen, einen eigenen Treiber zu schreiben, der einen eigenen Netzwerkstapel implementiert, damit Sie so nah wie möglich an die Anforderungen herankommen und dort Ihr eigenes Protokoll implementieren können. Was die meisten Programmierer wahrscheinlich nicht hören wollen, da es komplizierter ist. In meinem Fall wäre ich in der Lage, 40 % mehr CPU zu verbrauchen und auf über 1 Million dynamische Anfragen pro Sekunde zu kommen. Die UDP-Proxy-Methode kann Sie der optimalen Leistung nahe bringen, ohne dies tun zu müssen, aber Sie benötigen mehr Server – wenn Sie jedoch so viele Anfragen pro Sekunde ausführen, benötigen Sie normalerweise mehrere Netzwerkkarten und mehrere Frontends, um die Bandbreite zu bewältigen Ein paar leichtgewichtige UDP-Proxys darin sind keine so große Sache.

Hoffe, einiges davon kann für Sie nützlich sein.

Wie viele Instanzen von io_service haben Sie? Boost asio hat eine Beispiel die einen io_service pro CPU erstellen und diese in der Art von RoundRobin verwenden.

Sie können immer noch vier Threads erstellen und einen pro CPU zuweisen, aber jeder Thread kann seinen eigenen io_service abfragen.