![\"Ottimizzazione](\"\/wp-content\/uploads\/2021\/05\/908fb8d92e84a3e7557af7f6c622298e.png\")
<\/center> <\/p>\nOttimizzazioni principali: <\/p>\n
- \n
- Ottimizzazione del codice libreactor. \u00c8 stata utilizzata come base la versione R18 del set Techempower, migliorata rimuovendo il codice per limitare il numero di core CPU utilizzati (l'ottimizzazione ha permesso un incremento delle prestazioni del 25-27%), compilazione in GCC con le opzioni \u00ab-O3\u00bb (incremento del 5-10%) e \u00ab-march-native\u00bb (5-10%), sostituzione delle chiamate read\/write con recv\/send (5-10%) e riduzione delle spese generali nell'uso di pthreads (2-3%). L'incremento complessivo delle prestazioni dopo l'ottimizzazione del codice \u00e8 stato del 55%, mentre la capacit\u00e0 di elaborazione \u00e8 aumentata da 224k req\/s a 347k req\/s.\n
- Disattivazione della protezione contro vulnerabilit\u00e0 causate dall'esecuzione speculativa delle istruzioni. L'uso dei parametri di avvio del kernel \u00abnospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off\u00bb ha consentito di aumentare le prestazioni del 28%, mentre la capacit\u00e0 di elaborazione \u00e8 passata da 347k req\/s a 446k req\/s. In particolare, l'incremento dal parametro \u00abnospectre_v1\u00bb (protezione contro Spectre v1 + SWAPGS) \u00e8 stato dell'1-2%, \u00abnospectre_v2\u00bb (protezione contro Spectre v2) \u2014 15-20%, \u00abpti=off\u00bb (Spectre v3\/Meltdown) \u2014 6%, \u00abmds=off tsx_async_abort=off\u00bb (MDS\/Zombieload e TSX Asynchronous Abort) \u2014 6%. Le impostazioni per la protezione contro attacchi L1TF\/Foreshadow (l1tf=flush), iTLB multihit, Speculative Store Bypass e SRBDS sono rimaste invariate, in quanto non influivano sulle prestazioni essendo specifiche per la configurazione testata (ad esempio, specifiche per KVM<\/a>, la virtualizzazione nidificata e altri modelli di CPU).\n
- Disattivazione dei meccanismi di audit e blocco delle chiamate di sistema utilizzando il comando \u00abauditctl -a never,task\u00bb e specificando l'opzione \u00ab--security-opt seccomp=unconfined\u00bb all'avvio del contenitore docker. L'incremento complessivo delle prestazioni \u00e8 stato dell'11%, mentre la capacit\u00e0 di elaborazione \u00e8 aumentata da 446k req\/s a 495k req\/s.\n
- Disabilitare iptables\/netfilter scaricando i relativi moduli del kernel. L'idea di disattivare il firewall, non utilizzato in una soluzione server specifica, \u00e8 stata motivata dai risultati del profiling, da cui si evince che la funzione nf_hook_slow richiedeva il 18% del tempo. Si segnala che nftables \u00e8 pi\u00f9 efficiente di iptables, ma su Amazon Linux resta in uso iptables. Dopo la disattivazione di iptables, si \u00e8 registrato un aumento delle prestazioni del 22% e la capacit\u00e0 di elaborazione \u00e8 aumentata da 495k req\/s a 603k req\/s.\n
- Riduzione della migrazione dei gestori tra core CPU diversi per migliorare l'efficienza dell'uso della cache della CPU. L'ottimizzazione \u00e8 stata effettuata sia a livello di binding dei processi libreactor ai core CPU (CPU Pinning), sia mediante il fissaggio dei gestori di rete del kernel (Receive Side Scaling). Ad esempio, \u00e8 stata disattivata l'irqbalance e sono state impostate esplicitamente le affinit\u00e0 delle code a CPU in \/proc\/irq\/$IRQ\/smp_affinity_list. Per utilizzare lo stesso core CPU per elaborare il processo libreactor e la coda di rete dei pacchetti in entrata \u00e8 stato impiegato un gestore BPF personalizzato, connesso tramite l'impostazione del flag SO_ATTACH_REUSEPORT_CBPF durante la creazione del socket. Per il binding a CPU delle code dei pacchetti in uscita sono state modificate le impostazioni in \/sys\/class\/net\/eth0\/queues\/tx-<n>\/xps_cpus. Il guadagno totale di prestazioni \u00e8 stato del 38%, mentre la larghezza di banda \u00e8 aumentata da 603k req\/s a 834k req\/s.\n
- Ottimizzazione della gestione delle interruzioni e utilizzo del polling. L'attivazione della modalit\u00e0 adaptive-rx nel driver ENA e le manipolazioni con sysctl net.core.busy_read hanno consentito di aumentare le prestazioni del 28% (la capacit\u00e0 di elaborazione \u00e8 passata da 834k req\/s a 1.06M req\/s, mentre i ritardi sono diminuiti da 361\u00b5s a 292\u00b5s).\n
- Disattivazione dei servizi di sistema che causano blocchi eccessivi nello stack di rete. Disattivare dhclient e installare Indirizzi IP<\/a> manualmente ha portato a un aumento delle prestazioni del 6%, mentre la capacit\u00e0 di trasmissione \u00e8 aumentata da 1,06M req\/s a 1,12M req\/s. La ragione dell'impatto di dhclient sulle prestazioni nell'analisi del traffico utilizzando socket raw.\n
- Combattimento contro Spin Lock. La modifica dello stack di rete in modalit\u00e0 \u00abnoqueue\u00bb tramite sysctl \u00abnet.core.default_qdisc=noqueue\u00bb e \u00abtc qdisc replace dev eth0 root mq\u00bb ha portato a un incremento delle prestazioni del 2%, mentre la capacit\u00e0 di elaborazione \u00e8 aumentata da 1.12M req\/s a 1.15M req\/s.\n
- Ottimizzazioni finali minori, come la disattivazione di GRO (Generic Receive Offload) tramite il comando \u00abethtool -K eth0 gro off\u00bb e la sostituzione dell'algoritmo di controllo del congestionamento da cubic a reno tramite sysctl \u00abnet.ipv4.tcp_congestion_control=reno\u00bb. L'incremento complessivo delle prestazioni \u00e8 stato del 4%. La capacit\u00e0 di elaborazione \u00e8 aumentata da 1.15M req\/s a 1.2M req\/s. <\/ul>\n
Oltre alle ottimizzazioni implementate, l'articolo discute anche metodi che non hanno portato al aumento delle prestazioni previsto. Ad esempio, si sono rivelati inefficaci: <\/p>\n
- \n
- L'esecuzione separata di libreactor non ha mostrato differenze di prestazioni rispetto all'esecuzione in contenitore. Non hanno avuto effetto la sostituzione di writev con send, l'aumento di maxevents in epoll_wait, gli esperimenti con versioni e flag GCC (l'effetto \u00e8 stato evidente solo per i flag \u00ab-O3\u00bb e \u00ab-march-native\u00bb).\n
- L'aggiornamento del kernel Linux a versioni 4.19 e 5.4, l'uso dei pianificatori SCHED_FIFO e SCHED_RR, la manipolazione di sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=never, skew_tick=1 e clocksource=tsc non hanno influito sulle prestazioni.\n
- Nei driver ENA, l'attivazione delle modalit\u00e0 Offload (segmentazione, scatter-gather, rx\/tx checksum), la compilazione con il flag \u00ab-O3\u00bb e l'applicazione dei parametri ena.rx_queue_size e ena.force_large_llq_header non hanno influenzato le prestazioni.\n
- Le modifiche nello stack di rete non hanno portato a un aumento delle prestazioni:\n