Solution 1 :
Honnêtement, je n'utiliserais pas Ubuntu pour cela... mais il existe des options qui peuvent être appliquées à n'importe quelle variante de Linux.
Vous voudrez créer vos tampons de pile réseau :
net.core.rmem_default = 10000000
net.core.wmem_default = 10000000
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
Si l'application écrit sur le disque, peut-être qu'un changement de planificateur/élévateur serait nécessaire (par exemple, le deadline
ascenseur).
Au niveau du serveur, vous pouvez modifier le gouverneur du CPU et la gestion de la puissance et de la fréquence du CPU (P-States, C-States).
Au niveau du système d'exploitation, vous pouvez modifier la priorité temps réel de votre application (chrt
), optimisant pour réduire les interruptions, en l'épinglant à un processeur ou à un groupe de processeurs (taskset
), et en arrêtant tous les services ou démons inutiles.
Vous pouvez également voir quelques suggestions sur :Comment résoudre les problèmes de latence entre 2 hôtes Linux
Il est difficile d'être plus précis sans connaître le matériel ou l'équipement réseau impliqué.
Solution 2 :
Si vous optez pour des performances élevées, vous souhaiterez généralement exécuter le moins d'autres processus (planifiés) possible, car ils interféreront avec votre application.
Linux, comme les systèmes d'exploitation UNIX classiques, est conçu pour exécuter plusieurs applications simultanément de manière équitable et essaie d'empêcher la pénurie de ressources et vous viserez le contraire, affamer tout le reste sauf votre application. Des étapes simples au niveau du système d'exploitation changent le niveau de gentillesse et la priorité en temps réel de votre application, changent le planificateur ou optent pour un noyau en temps réel.
TCP/IP est généralement réglé pour empêcher les interruptions de connexion et utiliser efficacement la bande passante disponible. Pour obtenir la latence la plus faible possible à partir d'une liaison très rapide, plutôt que d'obtenir la bande passante la plus élevée possible à partir d'une connexion où certaines liaisons intermédiaires sont plus limitées, vous allez ajuster le réglage de la pile réseau.
sysctl -a
vous montrera une foule de paramètres de noyau que vous pouvez régler. Les paramètres dépendent du fait que vous utilisez ou non IPv4 ou IPv6 et de ce que vous faites exactement déjà dans votre application, mais qui peut vous intéresser :
net.ipv4.tcp_window_scaling=1
RFC 1323 – prise en charge des tailles de fenêtre TCP IPV4 supérieures à 64 Ko – généralement nécessaire sur les réseaux à large bande passantenet.ipv4.tcp_reordering=3
Le nombre maximal de fois qu'un paquet IPV4 peut être réorganisé dans un flux de paquets TCP sans que TCP suppose une perte de paquets et entre en démarrage lent.net.ipv4.tcp_low_latency=1
destiné à donner la préférence à une faible latence plutôt qu'à un débit plus élevé ; paramètre =1désactive le traitement de la pré-file d'attente TCP IPV4net.ipv4.tcp_sack=0
le réglage sur 1 active l'accusé de réception sélectif pour IPV4, ce qui nécessite l'activation de tcp_timestamps et ajoute une surcharge de paquets, dont vous n'avez pas besoin si vous ne subissez pas de perte de paquetsnet.ipv4.tcp_timestamps=0
Conseillé uniquement dans les cas où un sac est nécessaire.net.ipv4.tcp_fastopen=1
Activer pour envoyer des données dans le paquet SYN d'ouverture.
La plupart, sinon tous, sont mieux documentés dans les sources du noyau.
Vous pouvez bien sûr coder des sockets TCP bruts et contourner en grande partie la pile TCP/IP du noyau.
Souvent, les systèmes hautement optimisés fonctionnent dans un réseau de confiance et verront leurs pare-feu locaux (iptables) désactivés.