ProHoster > Blog > Lajmet e internetit > Optimizimi i Linuxit për trajtimin e 1.2 milion JSON kërkesave në sekondë

Optimizimi i Linuxit për trajtimin e 1.2 milion JSON kërkesave në sekondë

Published a detailed guide on tuning the Linux environment for maximum HTTP request processing performance. The proposed methods allowed increasing the performance of the JSON handler based on the libreactor library in the Amazon EC2 environment (4 vCPU) from 224 thousand API requests per second with the standard settings of Amazon Linux 2 with a 4.14 kernel to 1.2 million requests per second after optimization (an increase of 436%), and also led to a 79% reduction in request processing latency. The proposed methods are not specific to libreactor and work when using other HTTP servers, including nginx, Actix, Netty, and Node.js (libreactor was used in the tests because the solution based on it showed the best performance).

Optimizimi i Linuxit për trajtimin e 1.2 milion JSON kërkesave në sekondë

Optimizations principale:

  • Optimizimi i kodit libreactor. Si bazĂ« u pĂ«rdor varianti R18 nga grupe Techempower, i cili u pĂ«rmirĂ«sua pĂ«rmes eliminimit tĂ« kodit pĂ«r tĂ« kufizuar numrin e bĂ«rjes pĂ«rdoruesve tĂ« CPU (optimizimi lehtĂ«soi punĂ«n me 25-27%), ndĂ«rtimit nĂ« GCC me opsionet "-O3" (rritje 5-10%) dhe "-march-native" (5-10%), zĂ«vendĂ«simit tĂ« thirrjeve read/write me recv/send (5-10%) dhe uljes sĂ« kostove operuese kur pĂ«rdoren pthreads (2-3%). Rritja totale e performancĂ«s pas optimizimit tĂ« kodit ishte 55%, ndĂ«rsa kapaciteti u rrit nga 224k req/s nĂ« 347k req/s.
  • Çaktivizimi i mbrojtjes nga cenueshmĂ«ritĂ« tĂ« shkaktuar nga ekzekutimi spekulator i instrukcioneve. PĂ«rdorimi i parametrave gjatĂ« ngarkimit tĂ« kernelit "nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off" lehtĂ«soi performancĂ«n me 28%, ndĂ«rsa kapaciteti u rrit nga 347k req/s nĂ« 446k req/s. Veçmas, rritja nga parametri "nospectre_v1" (mbrojtja nga Spectre v1 + SWAPGS) ishte 1-2%, "nospectre_v2" (mbrojtja nga Spectre v2) - 15-20%, "pti=off" (Spectre v3/Meltdown) - 6%, "mds=off tsx_async_abort=off" (MDS/Zombieload dhe TSX Asynchronous Abort) - 6%. Parametrat pĂ«r mbrojtjen nga sulmet L1TF/Foreshadow (l1tf=flush), iTLB multihit, Speculative Store Bypass dhe SRBDS mbetĂ«n pa ndryshime, pasi nuk kishin ndikim nĂ« performancĂ«, duke mos u ndĂ«rthurrur me konfigurimin e testuar (pĂ«r shembull, specifik pĂ«r KVM, virtualizimin e ndodhur dhe modelet e tjera tĂ« CPU).
  • Çaktivizimi i mekanizmave tĂ« auditi dhe bllokimit tĂ« thirrjeve sistemike me komandĂ«n «auditctl -a never,task» dhe caktimin e opsionit «—security-opt seccomp=unconfined» gjatĂ« nisjes sĂ« kontejnerit docker. Rritja totale e performancĂ«s ishte 11%, dhe kapaciteti i kalimit u rrit nga 446k req/s nĂ« 495k req/s.
  • Çaktivizimi i iptables/netfilter pĂ«rmes shkarkimit tĂ« modulave tĂ« lidhura me ta nga bĂ«rthama. Ideja pĂ«r tĂ« çaktivizuar firewalla, i cili nuk u pĂ«rdor nĂ« zgjidhjen specifike tĂ« serverit, u nxit nga rezultatet e profilizimit, sipas tĂ« cilave fuksioni nf_hook_slow merrte 18% tĂ« kohĂ«s. Vihet nĂ« dukje se nftables funksionon mĂ« efikashem se iptables, por nĂ« Amazon Linux vazhdon tĂ« pĂ«rdoret iptables. Pas çaktivizimit tĂ« iptables, rritja e performancĂ«s ishte 22%, dhe kapaciteti i kalimit u rrit nga 495k req/s nĂ« 603k req/s.
  • PĂ«rmirĂ«simi i migrimit tĂ« pĂ«rpunuesve mes bĂ«rthamave tĂ« ndryshme CPU pĂ«r tĂ« rritur efikasitetin e pĂ«rdorimit tĂ« caches tĂ« procesorĂ«ve. Optimizimi u realizua si nĂ« nivelin e lidhjes sĂ« proceseve libreactor me bĂ«rthama CPU (CPU Pinning), ashtu edhe pĂ«rmes ngjitjes sĂ« pĂ«rpunuesve tĂ« rrjetit tĂ« bĂ«rthamĂ«s (Receive Side Scaling). PĂ«r shembull, u çaktivizua irqbalance dhe u vendosĂ«n qartĂ« lidhjet e radhĂ«ve me CPU nĂ« /proc/irq/$IRQ/smp_affinity_list. PĂ«r tĂ« pĂ«rdorur tĂ« njĂ«jtĂ«n bĂ«rthamĂ« CPU pĂ«r pĂ«rpunimin e procesit libreactor dhe rendin e paketave hyrĂ«se, u angazhua njĂ« pĂ«rpunues BPF i personalizuar, i lidhur pĂ«rmes vendosjes sĂ« flamurit SO_ATTACH_REUSEPORT_CBPF gjatĂ« krijimit tĂ« soketit. PĂ«r lidhjen me CPU tĂ« radhĂ«ve tĂ« paketave dalĂ«se, u ndryshuan parametrat nĂ« /sys/class/net/eth0/queues/tx-<n>/xps_cpus. Rritja totale e performancĂ«s ishte 38%, dhe kapaciteti i kalimit u rrit nga 603k req/s nĂ« 834k req/s.
  • Optimizimi i pĂ«rpunimit tĂ« ndĂ«rprerjeve dhe pĂ«rdorimi i polingut (polling). Aktivizimi i modit adaptive-rx nĂ« drivere ENA dhe manipulimet me sysctl net.core.busy_read lejojnĂ« njĂ« rritje tĂ« performancĂ«s prej 28% (kapaciteti i kalimit u rrit nga 834k req/s nĂ« 1.06M req/s, ndĂ«rsa vonesat u ulĂ«n nga 361ÎŒs nĂ« 292ÎŒs).
  • Çaktivizimi i shĂ«rbimeve sistemike qĂ« çojnĂ« nĂ« bllokime shtesĂ« nĂ« stakun e rrjetit. Çaktivizimi i dhclient dhe vendosja Adresa IP duke e bĂ«rĂ« atĂ« manualisht çoi nĂ« njĂ« rritje tĂ« performancĂ«s prej 6%, dhe kapaciteti i kalimit u rrit nga 1.06M req/s nĂ« 1.12M req/s. Arsyeja e ndikimit tĂ« dhclient nĂ« performancĂ« nĂ« analizĂ«n e trafikut duke pĂ«rdorur raw-soketin.
  • Luftimi mbi Spin Lock. Kalimi i stakĂ«s rrjetore nĂ« modalitetin "noqueue" pĂ«rmes sysctl "net.core.default_qdisc=noqueue" dhe "tc qdisc replace dev eth0 root mq" rezultoi nĂ« njĂ« rritje tĂ« performancĂ«s prej 2%, ndĂ«rsa kapaciteti kaloi nga 1.12M req/s nĂ« 1.15M req/s.
  • Optimizimet pĂ«rfundimtare, siç Ă«shtĂ« çaktivizimi i GRO (Generic Receive Offload) me komandĂ«n "ethtool -K eth0 gro off" dhe zĂ«vendĂ«simi i algoritmit tĂ« kontrollit tĂ« ngarkesĂ«s cubic me reno pĂ«rmes sysctl "net.ipv4.tcp_congestion_control=reno". Rritja totale e performancĂ«s arriti 4%. Kapaciteti kaloi nga 1.15M req/s nĂ« 1.2M req/s.

Përveç optimizimeve që funksionuan, në artikull shqyrtohen gjithashtu metoda që nuk çuan në rritjen e pritur të performancës. Për shembull, këto u dëshmuan si të paefektshme:

  • Ekzekutimi i veçantĂ« i libreactor nuk e ndryshoi performancĂ«n nga ekzekutimi nĂ« kontejner. ZĂ«vendĂ«simi i writev me send, rritja e maxevents nĂ« epoll_wait, eksperimentet me versionet dhe flagjet e GCC (efekti u vu re vetĂ«m pĂ«r flagjet "-O3" dhe "-march-native").
  • PĂ«rmirĂ«simi nĂ« performancĂ« nuk u ndikua nga pĂ«rditĂ«simi i bĂ«rthamĂ«s Linux nĂ« versionet 4.19 dhe 5.4, pĂ«rdorimi i planifikuesve SCHED_FIFO dhe SCHED_RR, manipulimet me sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=never, skew_tick=1 dhe clocksource=tsc.
  • NĂ« drivĂ«rin ENA, aktivizimi i mĂ«nyrave Offload (segmentation, scatter-gather, rx/tx checksum), ndĂ«rtimi me flagun "-O3" dhe aplikimi i parametrave ena.rx_queue_size dhe ena.force_large_llq_header nuk kishin ndikim mbi performancĂ«n.
  • Ndryshimet nĂ« stakĂ«n rrjetore nuk çuan nĂ« njĂ« rritje tĂ« performancĂ«s:
    • Çaktivizimi i IPv6: ipv6.disable=1
    • Çaktivizimi i VLAN: modprobe -rv 8021q
    • Çaktivizimi i verifikimit tĂ« burimit tĂ« paketĂ«s
      • net.ipv4.conf.all.rp_filter=0
      • net.ipv4.conf.eth0.rp_filter=0
      • net.ipv4.conf.all.accept_local=1 (efekti negativ)
    • net.ipv4.tcp_sack=0
    • net.ipv4.tcp_dsack=0
    • net.ipv4.tcp_mem/tcp_wmem/tcp_rmem
    • net.core.netdev_budget
    • net.core.dev_weight
    • net.core.netdev_max_backlog
    • net.ipv4.tcp_slow_start_after_idle=0
    • net.ipv4.tcp_moderate_rcvbuf=0
    • net.ipv4.tcp_timestamps=0
    • net.ipv4.tcp_low_latency=1
    • SO_PRIORITY
    • TCP_NODELAY

    Burimi: opennet.ru

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster