![\"Optimisation](\"\/wp-content\/uploads\/2021\/05\/908fb8d92e84a3e7557af7f6c622298e.png\")
<\/center> <\/p>\nOptimisations principales : <\/p>\n
- \n
- Optimisation du code libreactor. Une version R18 du framework Techempower a \u00e9t\u00e9 utilis\u00e9e comme base, am\u00e9lior\u00e9e par la suppression du code limitant le nombre de c\u0153urs CPU utilis\u00e9s (l'optimisation a permis d'acc\u00e9l\u00e9rer le fonctionnement de 25 \u00e0 27 %), des compilations avec GCC avec les options \u00ab -O3 \u00bb (gain de 5 \u00e0 10 %) et \u00ab -march-native \u00bb (5 \u00e0 10 %), le remplacement des appels read\/write par recv\/send (5 \u00e0 10 %) et la r\u00e9duction des frais g\u00e9n\u00e9raux lors de l'utilisation de pthreads (2 \u00e0 3 %). Le gain de performance total apr\u00e8s l'optimisation du code a \u00e9t\u00e9 de 55 %, et la bande passante a augment\u00e9 de 224k req\/s \u00e0 347k req\/s.\n
- D\u00e9sactivation des protections contre les vuln\u00e9rabilit\u00e9s caus\u00e9es par l'ex\u00e9cution sp\u00e9culative des instructions. L'utilisation des param\u00e8tres lors du chargement du noyau \u00ab nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off \u00bb a permis d'augmenter la performance de 28 %, et la bande passante est pass\u00e9e de 347k req\/s \u00e0 446k req\/s. Gain isol\u00e9 du param\u00e8tre \u00ab nospectre_v1 \u00bb (protection contre Spectre v1 + SWAPGS) de 1 \u00e0 2 %, \u00ab nospectre_v2 \u00bb (protection contre Spectre v2) \u2014 15 \u00e0 20 %, \u00ab pti=off \u00bb (Spectre v3\/Meltdown) \u2014 6 %, \u00ab mds=off tsx_async_abort=off \u00bb (MDS\/Zombieload et TSX Asynchronous Abort) \u2014 6 %. Les param\u00e8tres pour prot\u00e9ger contre les attaques L1TF\/Foreshadow (l1tf=flush), iTLB multihit, Speculative Store Bypass et SRBDS ont \u00e9t\u00e9 conserv\u00e9s, car ils n'influaient pas sur la performance \u00e9tant donn\u00e9 qu'ils ne touchaient pas la configuration test\u00e9e (par exemple, sp\u00e9cifiques pour KVM<\/a>, la virtualisation imbriqu\u00e9e et d'autres mod\u00e8les de CPU).\n
- D\u00e9sactivation des m\u00e9canismes d'audit et de verrouillage des appels syst\u00e8me \u00e0 l'aide de la commande \u00ab auditctl -a never,task \u00bb et en sp\u00e9cifiant l'option \u00ab --security-opt seccomp=unconfined \u00bb lors du lancement du conteneur docker. Le gain de performance total a \u00e9t\u00e9 de 11 %, et la bande passante est pass\u00e9e de 446k req\/s \u00e0 495k req\/s.\n
- D\u00e9sactivation d'iptables\/netfilter en t\u00e9l\u00e9chargeant les modules du noyau qui leur sont associ\u00e9s. L'id\u00e9e de d\u00e9sactiver le pare-feu, qui n'\u00e9tait pas utilis\u00e9 dans une solution serveur sp\u00e9cifique, a \u00e9t\u00e9 motiv\u00e9e par les r\u00e9sultats du profilage, selon lesquels l'ex\u00e9cution de la fonction nf_hook_slow prenait 18 % du temps. Il est not\u00e9 que nftables fonctionne plus efficacement qu'iptables, mais qu'Amazon Linux continue d'utiliser iptables. Apr\u00e8s la d\u00e9sactivation d'iptables, le gain de performance a \u00e9t\u00e9 de 22 %, et le d\u00e9bit est pass\u00e9 de 495k req\/s \u00e0 603k req\/s.\n
- R\u00e9duction de la migration des gestionnaires entre les diff\u00e9rents c\u0153urs CPU pour am\u00e9liorer l'efficacit\u00e9 de l'utilisation du cache processeur. L'optimisation a \u00e9t\u00e9 r\u00e9alis\u00e9e \u00e0 la fois au niveau du couplage des processus libreactor aux c\u0153urs CPU (CPU Pinning) et par le biais de l'affectation des gestionnaires r\u00e9seau du noyau (Receive Side Scaling). Par exemple, irqbalance a \u00e9t\u00e9 d\u00e9sactiv\u00e9 et des liaisons explicites des files d'attente aux CPU ont \u00e9t\u00e9 \u00e9tablies dans \/proc\/irq\/$IRQ\/smp_affinity_list. Pour utiliser un m\u00eame c\u0153ur CPU pour le traitement du processus libreactor et de la file d'attente r\u00e9seau des paquets entrants, un gestionnaire BPF d\u00e9di\u00e9 a \u00e9t\u00e9 utilis\u00e9, connect\u00e9 via le drapeau SO_ATTACH_REUSEPORT_CBPF lors de la cr\u00e9ation du socket. Pour lier les files d'attente des paquets sortants au CPU, les param\u00e8tres dans \/sys\/class\/net\/eth0\/queues\/tx-\/xps_cpus ont \u00e9t\u00e9 modifi\u00e9s. Le gain de performance total a \u00e9t\u00e9 de 38 %, et le d\u00e9bit est pass\u00e9 de 603k req\/s \u00e0 834k req\/s.\n
- Optimisation du traitement des interruptions et utilisation du polling. L'activation du mode adaptive-rx dans le pilote ENA et les manipulations avec sysctl net.core.busy_read ont permis d'augmenter la performance de 28 % (la bande passante est pass\u00e9e de 834k req\/s \u00e0 1.06M req\/s, et les latences ont diminu\u00e9 de 361\u00b5s \u00e0 292\u00b5s).\n
- D\u00e9sactivation des services syst\u00e8me entra\u00eenant des blocages inutiles dans la pile r\u00e9seau. La d\u00e9sactivation de dhclient et la configuration adresses IP<\/a> manuelle ont conduit \u00e0 une augmentation de la performance de 6 %, et le d\u00e9bit est pass\u00e9 de 1,06M req\/s \u00e0 1,12M req\/s. La raison de l'impact de dhclient sur la performance a \u00e9t\u00e9 analys\u00e9e par un trafic \u00e0 l'aide de socket brut.\n
- Lutte contre le Spin Lock. Le passage de la pile r\u00e9seau en mode \u00ab noqueue \u00bb via sysctl \u00ab net.core.default_qdisc=noqueue \u00bb et \u00ab tc qdisc replace dev eth0 root mq \u00bb a entra\u00een\u00e9 un gain de performance de 2 %, et la bande passante est pass\u00e9e de 1.12M req\/s \u00e0 1.15M req\/s.\n
- Les optimisations finales mineures, telles que la d\u00e9sactivation de GRO (Generic Receive Offload) avec la commande «ethtool -K eth0 gro off» et le remplacement de l'algorithme de contr\u00f4le de congestion cubic par reno \u00e0 l'aide de sysctl «net.ipv4.tcp_congestion_control=reno», ont permis d'augmenter la performance de 4 %. La capacit\u00e9 de traitement est pass\u00e9e de 1,15 M req\/s \u00e0 1,2 M req\/s. <\/ul>\n
En plus des optimisations r\u00e9ussies, l'article examine \u00e9galement les m\u00e9thodes qui n'ont pas conduit \u00e0 l'augmentation de performance attendue. Par exemple, les suivantes se sont r\u00e9v\u00e9l\u00e9es inefficaces : <\/p>\n
- \n
- Le d\u00e9marrage s\u00e9par\u00e9 de libreactor n'a pas montr\u00e9 de diff\u00e9rence de performance par rapport au d\u00e9marrage dans un conteneur. Le remplacement de writev par send, l'augmentation de maxevents dans epoll_wait, et les exp\u00e9rimentations avec les versions et les flags GCC n'ont eu aucun impact (l'effet n'\u00e9tait perceptible que pour les flags «-O3» et «-march-native»).\n
- La mise \u00e0 jour du noyau Linux vers les versions 4.19 et 5.4, l'utilisation des planificateurs SCHED_FIFO et SCHED_RR, les manipulations de sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=never, skew_tick=1 et clocksource=tsc n'ont pas eu d'effet sur la performance.\n
- Dans le pilote ENA, l'activation des modes Offload (segmentation, scatter-gather, rx\/tx checksum), la compilation avec le flag «-O3» et l'application des param\u00e8tres ena.rx_queue_size et ena.force_large_llq_header n'ont eu aucun effet.\n
- Les modifications apport\u00e9es \u00e0 la pile r\u00e9seau n'ont pas entra\u00een\u00e9 une augmentation de performance :\n