NCache Leistungsbenchmarks
2 Millionen Operationen/Sek
(5-Knoten-Cluster)
Executive Summary
NCache kann Ihnen helfen, die Leistung einfach und kosteneffizient linear zu skalieren und zu verbessern. Fortune 500-Unternehmen auf der ganzen Welt vertrauen NCache seit über 13 Jahren, um Leistungsengpässe im Zusammenhang mit Datenspeicherung und Datenbanken zu beseitigen und .NET-Anwendungen auf Extreme Transaction Processing (XTP) zu skalieren.
Dieses Dokument verwendet NCache 5.0 mit modernen APIs und einigen neuen Funktionen, um die lineare Skalierbarkeit und extreme Leistung zu demonstrieren, die Sie für Ihre .NET-Anwendungen erreichen können. In diesem Experiment haben wir ein Modem gebündelt NCache API mit partitionierter Cache-Topologie und aktiviertem Pipelining. Die Daten werden vollständig auf allen Caching-Servern verteilt und Clients stellen für Lese- und Schreibanforderungen eine Verbindung zu allen Servern her.
In diesem Benchmark zeigen wir, dass die NCache Cluster kann linear skaliert werden und das haben wir erreicht 2 Millionen Transaktionen pro Sekunde mit nur 5 Cache-Serverknoten. Auch das werden wir demonstrieren NCache kann selbst in einem großen Cluster eine Latenzzeit von weniger als einer Mikrosekunde liefern. In diesem Whitepaper behandeln wir Benchmark-Einstellungen, Schritte zur Durchführung von Benchmarks, Testkonfigurationen, Lastkonfigurationen und Ergebnisse. Hier können Sie das Benchmark-Experiment in Aktion sehen Video.
Benchmark-Setup-Übersicht
Lassen Sie uns unser Benchmark-Setup überprüfen. Wir werden für diesen Test AWS m4.10xlarge Server verwenden. Wir haben fünf davon NCache Server, auf denen wir unseren Cache-Cluster konfigurieren. Wir werden 15 Client-Server haben, von denen aus wir Anwendungen ausführen, um eine Verbindung zu diesem Cache-Cluster herzustellen.
Als Betriebssystem verwenden wir Windows Server 2016 – Data Center Edition, 64-Bit. Die NCache Die verwendete Version ist 5.0 Enterprise. In diesem Benchmark-Setup verwenden wir eine Partitionierte Cache-TopologieIn einer partitionierten Cache-Topologie werden alle Daten vollständig in Partitionen auf allen Caching-Servern verteilt. Alle Clients sind mit allen Servern verbunden, um Lese- und Schreibanfragen gleichzeitig zu verarbeiten. Für diese Topologie ist die Replikation nicht aktiviert, es gibt jedoch andere Topologien wie die Partitionierte Replikattopologie das mit Replikationsunterstützung ausgestattet ist.
Wir werden haben Pipelining aktiviert, was eine neue Funktion in NCache 5.0. Es funktioniert so, dass auf der Clientseite alle zur Laufzeit eingehenden Anfragen gesammelt und sofort auf der Serverseite ausgeführt werden. Die Ansammlung erfolgt in Mikrosekunden, ist also optimal optimiert und die empfohlene Konfiguration bei hohen Transaktionslastanforderungen.
Hier ist ein kurzer Überblick über unser Benchmark-Setup, einschließlich Hardware-, Software- und Lastkonfigurationen.
Hardware-Konfiguration:
| Client- und Serverdetails (Virtuelle Maschine) |
AWS m4.10xlarge: 40 Kerne, 160 GB Speicher, Netzwerk – 10 Gbit/s Ethernet |
| Anzahl der Serverknoten | 5 |
| Anzahl der Clientknoten | 15 |
Softwarekonfiguration:
| Betriebssystem | Windows Server 2016 Data Center Edition – x64 |
| NCache Version | 5.0 |
| Cluster-Topologie | Partitionierte Cache-Konfiguration |
Konfiguration laden:
| Cache-Größe | 4 GB |
| Datengröße | Byte-Array der Größe 100 |
| Gesamtanzahl | 1,000,000 |
| Pipelining | Nutzer der Smart‑Spaces‑App mit Google Wallet erhalten berührungslosen Mobile‑Zutritt an jedem NFC‑fähigen HID® Signo™‑Leser. |
| Get/Update-Verhältnis | 80:20 |
| Threads | 1280 |
| Anwendungsinstanzen | 2 Instanzen pro Client-Rechner, insgesamt 30 Instanzen |
Datenpopulation
Nach der Einrichtung unserer Benchmark-Umgebung starten wir mit einer Datenpopulation von 1 Million Elementen im Cache-Cluster. Wir führen die Client-Anwendung (Cache Item Loader) aus, die eine Verbindung herstellt und 1 Million Elemente zum Cache hinzufügt. Ein Client verbindet sich mit allen Caching-Servern und fügt 1 Million Elemente zum Cache-Cluster hinzu. Anschließend können wir mit Lese- und Schreibanfragen beginnen.
Sie können diese Nuget-Paket – NCache SDK um das SDK auf dem Client-Rechner zu installieren, das Pipelining zwischen Client und Server zu konfigurieren und die Load Generation Application (GitHub) bereitzustellen, um 1 Million Cache-Elemente im Cache-Cluster zu füllen.
Build-Transaktionslast
Wir führen nun die Anwendung aus, um eine gewisse Transaktionslast auf diesem Cache-Cluster mit 80 % Lese- und 20 % Schreibvorgängen aufzubauen. Sie können alle Aktivitäten mit Perfmon-Zählern überwachen. Zunächst verbinden wir 10 Client-Instanzen mit jedem NCache Server mit Aktivität bei Abrufen und Aktualisierungen pro Sekunde.
Stufe 1 1 Million Ops/Sek. Transaktionslast
Sie können im Screenshot sehen, dass wir bei 10 Client-Instanzen, die sich mit einem 5-Knoten-Cluster verbinden, Anfragen pro Sekunde zwischen 180,000 und 190,000 haben. Und da wir 5 NCache Server, die parallel arbeiten. Durch die Ansammlung dieser Anfragen erreichen wir mit diesem Cache-Cluster eine Million Anfragen pro Sekunde.
Wir nutzen Speicher und CPU effizient und die durchschnittliche Mikrosekunden-/Cache-Operation dauert etwas weniger als 10 Mikrosekunden pro Operation. Unsere erste Phase ist abgeschlossen, und wir haben mit unserem Cache-Cluster eine Million Operationen pro Sekunde erreicht.
| Phase 1 – Zusammenfassendes Datenblatt | |
| Gesamtzahl der Cache-Server im Cluster | 5 |
| Gesamtzahl der verbundenen Client-Instanzen | 10 |
| Anfragen pro Sekunde/Knoten | 180,0000 ~ 190,000 |
| Gesamtanforderungen – Cache-Cluster | 950,000 ~ 1,000,000 |
| % Prozessorzeit (max.) | 20% |
| System Memory | 4.2 GB |
| Latenz (Mikrosekunde/Cache-Vorgang) | 10 Mikrosekunden/Operation |
Stufe 2 1.5 Million Ops/Sek. Transaktionslast
Nachdem wir nun 1 Million TPS erreicht haben, ist es an der Zeit, die Last durch zusätzliche Anwendungsinstanzen zu erhöhen, um die Transaktionslast zu steigern. Sobald diese Anwendungen laufen, werden Sie einen Anstieg der Anfragen pro Sekunde feststellen. Wir erhöhen die Anzahl der Clients auf 20. Mit dieser Konfiguration, wie im Screenshot unten zu sehen ist, werden wir nun 300,000 Anfragen pro Sekunde pro Instanz anzeigen. Wir haben erfolgreich 1.5 Millionen Anfragen pro Sekunde von diesem Cache-Cluster erreicht.
Sie sehen, dass die Anzahl der Anfragen pro Sekunde von jedem Server 300,000 beträgt. Die Abrufe liegen bei etwas über 200,000 pro Sekunde und die Aktualisierungen zwischen 50,000 und 100,000. Sie sehen, dass die durchschnittliche Mikrosekunde pro Cache-Operation weniger als 4 Mikrosekunden beträgt. Das ist erstaunlich, da wir neben dem Pipelining auch eine sehr geringe Latenz haben. Bei hoher Transaktionslast auf der Clientseite ist Pipelining eine echte Hilfe, da es die Latenz reduziert und den Durchsatz erhöht. Deshalb empfehlen wir, es zu aktivieren. Darüber hinaus liegt die durchschnittliche Mikrosekunde pro Cache-Operation jetzt bei etwa 3-4 Mikrosekunden pro Cache-Operation.
| Phase 2 – Zusammenfassendes Datenblatt | |
| Gesamtzahl der Cache-Server im Cluster | 5 |
| Gesamtzahl der verbundenen Client-Instanzen | 20 |
| Durchschnittliche Anfragen pro Sekunde/Knoten | 300,000 |
| Gesamtanforderungen – Cache-Cluster | 1,500,000 |
| % Prozessorzeit (max.) | 30% |
| System Memory | 6 GB |
| Latenz (Mikrosekunde/Cache-Vorgang) | 3 ~ 4 Mikrosekunden/Operation |
Stufe 3 2 Million Ops/Sek. Transaktionslast
Lassen Sie uns die Last weiter erhöhen, indem wir einige weitere Anwendungsinstanzen ausführen, was auch eine weitere Erhöhung der Anfragen pro Sekunde zeigen wird. Wir werden nun 30 Client-Instanzen mit allen verbinden NCache Servers
Wie Sie im Screenshot unten sehen können, haben wir nun erfolgreich 400,000 Anfragen pro Sekunde erreicht, die wir von jedem erhalten NCache Server; wir haben 5 NCache Server, sodass die Zahl bis zu diesem Zeitpunkt auf zwei Millionen Transaktionen pro Sekunde ansteigt. NCache Cache-Cluster. Die durchschnittliche Mikrosekundenzahl pro Cache-Operation liegt bei weniger als 3 Mikrosekunden. Auch der Systemspeicher und die Prozessorzeit liegen mit 40 - 50 % Auslastung an beiden Fronten deutlich unter den Grenzwerten.
Wir haben jetzt eine Latenz von 2 bis 3 us/Operation, eine Verbesserung gegenüber dem vorherigen Ergebnis. Sie sehen erneut eine Mischung aus Abrufen, Aktualisierungen und einer effizienten Nutzung der CPU- und Speicherressourcen. Wir können daraus schließen, dass NCache ist linear skalierbar. Sehen wir uns nun unsere Skalierbarkeitszahlen an.
| Phase 3 – Zusammenfassendes Datenblatt | |
| Gesamtzahl der Cache-Server im Cluster | 5 |
| Gesamtzahl der verbundenen Client-Instanzen | 30 |
| Durchschnittliche Anfragen pro Sekunde/Knoten | 400,000 |
| Gesamtanforderungen – Cache-Cluster | 2,000,000 |
| % Prozessorzeit (max.) | 60% |
| System Memory | 6 GB |
| Latenz (Mikrosekunde/Cache-Vorgang) | 2 ~ 3 Mikrosekunden/Operation |
Benchmark-Ergebnisse
Wir konnten zeigen, dass NCache ist linear skalierbar und wir konnten nach der Durchführung der Benchmarks folgende Ergebnisse erzielen:
Schlussfolgerungen
- Lineare Skalierbarkeit: Mit 5 NCache Servern konnten wir 2 Millionen Anfragen pro Sekunde erreichen. Das Hinzufügen von immer mehr Servern bedeutet mehr Möglichkeiten zur Anfragebearbeitung von NCache.
- Geringe Latenz und hoher Durchsatz: NCache liefert selbst bei einer großen Clustergröße eine Latenz von weniger als einer Mikrosekunde (2.5 bis 3 Mikrosekunden). NCache hilft, Anforderungen an geringe Latenz und hohen Durchsatz auch im großen Maßstab zu erfüllen. Wir haben eine sehr geringe Latenz, ein Effekt, der durch Pipelining entsteht. Bei hohen Transaktionslasten auf der Clientseite ist Pipelining eine echte Hilfe, da es die Latenz reduziert und den Durchsatz erhöht.