NetworkBenchmarkDotNet
1.1.0
Bibliothèques réseau .NET 6 de bas niveau évaluées pour les performances des sockets UDP
NBN est une référence pour les bibliothèques réseau de bas niveau utilisant UDP et peut être utilisé avec Unity et pour les applications serveur autonomes .Net Core. Le benchmark se concentre sur la latence, les performances et l'évolutivité.
VPN Ubuntu
$> hostnamectl
Chassis: vm
Virtualization: kvm
Operating System: Ubuntu 22.04.2 LTS
Kernel: Linux 5.15.0-48-generic
Architecture: x86-64
Hardware Vendor: netcup
Hardware Model: KVM Server
Bureau Ubuntu / Bureau Windows
Pour les deux configurations de bureau, les tests sont exécutés sur un système redémarré avec 5 minutes d'inactivité avant de démarrer le test. Ils sont exécutés avec des privilèges d'administrateur et tous les autres processus inutiles sont supprimés avant d'exécuter les tests de performance. Pour Ubuntu VPS, les tests sont exécutés via une intégration continue sur une configuration de serveur indépendant typique avec d'autres processus en cours d'exécution également. Une fois les tests exécutés, une liste de tous les processus en cours pour les rendre plus reproductibles. Pour reproduire les benchmarks, exécutez sudo sh linux-benchmark.sh ou win-benchmark.bat . Si vous souhaitez exécuter directement à partir du programme compilé, exécutez ./NetworkBenchmarkDotNet -b Essential .
Les données brutes et les fichiers supplémentaires peuvent être téléchargés à partir de la section des versions.
Exécute le benchmark avec 500 clients, qui envoient chacun un message ping-pong au serveur avec une transmission peu fiable . Le benchmark s'exécute jusqu'à ce qu'un total de 500 000 messages soient envoyés au serveur et renvoyés aux clients. La taille du message est de 32 octets .
Ce test permet d'avoir une idée du temps moyen aller-retour (le plus bas est le mieux). 
Exécute le benchmark avec 500 clients, qui envoient chacun un message ping-pong au serveur avec une transmission fiable . Le benchmark s'exécute jusqu'à ce qu'un total de 500 000 messages soient envoyés au serveur et renvoyés aux clients. La taille du message est de 32 octets .
Ce test permet d'avoir une idée du temps moyen aller-retour (le plus bas est le mieux). 
Exécute le benchmark avec 500 clients, qui envoient chacun 10 messages ping-pong au serveur avec une transmission peu fiable . Le benchmark s'exécute jusqu'à ce qu'un total de 500 000 messages soient envoyés au serveur et renvoyés aux clients. La taille du message est de 32 octets .
Ce test concerne les performances de multiplexage/fusion de messages (plus c'est élevé, mieux c'est). 
Exécute le benchmark avec 1 client, qui envoie 10 messages chacun avec le serveur. Le benchmark s'exécute jusqu'à ce qu'un total de 100 000 messages soient envoyés au serveur et renvoyés aux clients. La taille du message est de 128 octets .
Ce test collecte des informations sur les déchets générés et les temps CPU lors de l'exécution du benchmark. Ces résultats peuvent être analysés avec PerfView sous Windows.
Il s'agit d'une comparaison entre tous les tests avec leur débit de messages (plus c'est élevé, mieux c'est).
.nettrace .Thread.Sleep sous Windows crée notamment des retards notables. Pour l'instant il est exclu des benchmarks prédéfinis, en attendant que son exécution et son nettoyage soient améliorés.Assurez-vous que le SDK .Net 6 est installé.
Ensuite, ouvrez simplement le fichier de solution avec Visual Studio/Rider/Visual Studio Code et créez-le. Notez que les résultats des tests de performance peuvent être très différents avec un système d'exploitation et un matériel différents.
En général, il existe deux types différents de benchmarks : les benchmarks personnalisés et prédéfinis. Benchmarks personnalisés et définis via les options de ligne de commande. Les benchmarks prédéfinis sont définis dans le code et sont exécutés via BenchmarkDotNet. Ils sont utilisés pour les statistiques présentées ici et sont plus précis et mieux reproductibles que les benchmarks personnalisés. Cependant, leur réalisation prend également plus de temps. Vous pouvez également exécuter les clients et le serveur sur différentes machines pour tester les bibliothèques sur votre réseau local ou à distance (voir les benchmarks à distance).
Vous pouvez exécuter des tests de performance personnalisés via la ligne de commande. L'utilisation peut tester plusieurs paramètres et leurs combinaisons de manière simple et rapide. Les tests ne seront exécutés qu’une seule fois et ne seront pas aussi précis que l’exécution d’un benchmark prédéfini. Un exemple d'exécution d'un benchmark pourrait être ./NetworkBenchmarkDotNet --library ENet --transmission Unreliable --clients 100 --duration 10
./NetworkBenchmarkDotNet --help ) Usage:
NetworkBenchmarkDotNet [options]
Options:
-b, --benchmark Run predefined benchmarks [default:
<All|Custom|Essential|Performance|Qui Custom]
ck|Sampling>
-m, --execution-mode Control what parts to run [default:
<Client|Complete|Server> Complete]
-t, --test <Manual|PingPong> Test type [default: PingPong]
--transmission <Reliable|Unreliable> Transmission type [default:
Unreliable]
-l, --library Library target [default: ENet]
<ENet|Kcp2k|LiteNetLib|NetCoreServer>
-d, --duration <duration> Test duration in seconds (-1 for
manual stopping) [default: 10]
--address <address> IP Address, can be ipv4 (e.g.
127.0.0.1) or ipv6 (e.g. ::1)
[default: ::1]
--port <port> Socket Port [default: 3330]
--clients <clients> # Simultaneous clients [default: 500]
--parallel-messages #Parallel messages per client
<parallel-messages> [default: 1]
--message-byte-size Message byte size sent by clients
<message-byte-size> [default: 32]
--message-payload <Ones|Random|Zeros> Message load sent by clients
[default: Random]
--verbose Verbose output of test steps and
errors [default: True]
--client-tick-rate <client-tick-rate> Client ticks per second if supported
[default: 60]
--server-tick-rate <server-tick-rate> Server ticks per second if supported
[default: 60]
--use-native-sockets Use native Sockets (LiteNetLib only)
[default: True]
--version Show version information
-?, -h, --help Show help and usage information
Les benchmarks prédéfinis prennent un certain temps à s'exécuter, mais génèrent des nombres reproductibles. Le moyen le plus simple d'exécuter un benchmark prédéfini est d'exécuter win-benchmark.bat sous Windows ou sh linux-benchmark.sh sous Windows.
Pour tester une bibliothèque à distance, vous pouvez utiliser respectivement les paramètres --execution-mode Server et --execution-mode Client . Cette configuration nécessite d'abord de démarrer le serveur avec la bonne bibliothèque (et probablement une durée d'exécution indéfinie) sur votre serveur cible, puis le processus client. Voici un exemple :
Serveur : ./NetworkBenchmarkDotNet --library ENet --transmission Reliable --execution-mode Server --address YOUR_ADDRESS -d -1
Client : ./NetworkBenchmarkDotNet --library ENet --transmission Reliable --execution-mode Client --address YOUR_ADDRESS --clients 100 -d 10
Si vous modifiez l'adresse dans QuickBenchmark.cs , vous pouvez également exécuter un test à distance plus sophistiqué de cette façon.
Votre bibliothèque préférée est manquante ou vous avez l'impression que les benchmarks ne testent pas tout ce qui est pertinent ? Faisons évoluer le benchmark ensemble ! Soit contactez-moi par e-mail pour discuter de votre idée, soit ouvrez un ticket, soit faites une pull request directement. Il existe quelques règles afin de ne pas trop encombrer le benchmark.
Votre nouvelle bibliothèque proposée...
YourLibraryBenchmark.cs qui implémente ANetworkBenchmarkINetworkBenchmark.CreateNetworkBenchmark()-l (ou BenchmarkSetup.Library ) pour tester votre bibliothèque et si tout fonctionne comme prévu.[Params(NetworkLibrary.Kcp2k)] dans QuickBenchmark.cs par votre bibliothèque et exécutez ./NetworkBenchmarkDotNet -b Quick pour voir si votre bibliothèque fonctionne avec un CCU élevé et des benchmarks en boucle avec BenchmarkDotNetMIT
