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

Optimizimi i Linux për përpunimin e 1.2 milion kërkesave JSON në sekondë

Publikuar një udhëzues të detajuar për përshtatjen e ambientit Linux për arritjen e performancës maksimale në përpunimin e kërkesave HTTP. Metodat e propozuara lejuan ngritjen e performancës së handler-it JSON të bazuar në bibliotekën libreactor në ambientin Amazon EC2 (4 vCPU) nga 224 mijë kërkesa API në sekondë me konfigurime standarde të Amazon Linux 2 me bërthamën 4.14 në 1.2 milion kërkesa në sekondë pas optimizimit (rritje prej 436%), si dhe çuan në reduktimin e vonesave gjatë përpunimit të kërkesave me 79%. Metodat e propozuara nuk janë specifike për libreactor dhe funksionojnë me përdorimin e serverëve të tjerë http, përfshirë nginx, Actix, Netty dhe Node.js (libreactor u përdor në testime, pasi zgjidhja e bazuar në të tregoi performancën më të mirë).

Optimizimi i Linux për përpunimin e 1.2 milion kërkesave JSON në sekondë

Optimizimet kryesore:

  • Optimizimi i kodit libreactor. Si bazĂ« Ă«shtĂ« pĂ«rdorur varianti R18 nga seti Techempower, i cili Ă«shtĂ« pĂ«rmirĂ«suar duke eliminuar kodin pĂ«r tĂ« kufizuar numrin e thellimeve tĂ« pĂ«rdorura tĂ« CPU (optimizimi ka lejuar pĂ«rshpejtimin e punĂ«s me 25-27%), ndĂ«rtimi nĂ« GCC me opsionet «-O3» (rritje 5-10%) dhe «-march-native» (5-10%), zĂ«vendĂ«simin e thirrjeve read/write me recv/send (5-10%) dhe uljen e kostove gjatĂ« pĂ«rdorimit tĂ« pthreads (2-3%). Rritja totale e performancĂ«s pas optimizimit tĂ« kodit Ă«shtĂ« 55%, ndĂ«rsa kapaciteti kalimtar Ă«shtĂ« rritur nga 224k req/s nĂ« 347k req/s.
  • Çaktivizimi i mbrojtjes nga dobĂ«sitĂ« qĂ« shkaktohen nga ekzekutimi spekulativ i instrukcioneve. PĂ«rdorimi i parametrave nĂ« ngarkimin e kernelit "nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off" lehtĂ«soi njĂ« rritje tĂ« performancĂ«s prej 28%, me kapacitetin e kĂ«rkesave qĂ« rritet nga 347k req/s nĂ« 446k req/s. NdĂ«rveprimi nga parametri "nospectre_v1" (mbrojtjeje nga Spectre v1 + SWAPGS) ishte 1-2%, "nospectre_v2" (mbrojtje nga Spectre v2) – 15-20%, "pti=off" (Spectre v3/Meltdown) – 6%, "mds=off tsx_async_abort=off" (MDS/Zombieload dhe TSX Asynchronous Abort) – 6%. JanĂ« lĂ«nĂ« tĂ« pandryshuara cilĂ«simet pĂ«r mbrojtjen nga sulmet L1TF/Foreshadow (l1tf=flush), iTLB multihit, Speculative Store Bypass dhe SRBDS, tĂ« cilat nuk ndikonin nĂ« performancĂ«, pasi nuk pĂ«rputheshin me konfigurimin e testuar (p.sh., specifik pĂ«r KVM, virtualizimin e brendshĂ«m dhe modelet e tjera tĂ« CPU).
  • Çaktivizimi i mekanizmave tĂ« auditimit dhe bllokimit tĂ« thirrjeve sistemore pĂ«rmes urdhrit "auditctl -a never,task" dhe caktimin e opsionit "—security-opt seccomp=unconfined" gjatĂ« nisjes sĂ« enĂ«s docker. Rritja totale e performancĂ«s ishte 11%, me kapacitetin e kĂ«rkesave qĂ« u rrit nga 446k req/s nĂ« 495k req/s.
  • Çaktivizimi i iptables/netfilter pĂ«rmes shkarkimit tĂ« moduleve tĂ« lidhura tĂ« bĂ«rthamĂ«s. Ideja pĂ«r tĂ« çaktivizuar firewall-in, i cili nuk pĂ«rdorej nĂ« zgjidhjen specifike tĂ« serverit, u nxit nga rezultatet e profilizimit, sipas tĂ« cilave funksioni nf_hook_slow merrte 18% tĂ« kohĂ«s. Vlen tĂ« theksohet se nftables funksionon mĂ« efektivisht se iptables, por nĂ« Amazon Linux vazhdon tĂ« pĂ«rdoret iptables. Pas çaktivizimit tĂ« iptables, rritja e performancĂ«s ishte 22%, ndĂ«rsa kapaciteti kaloi nga 495k req/s nĂ« 603k req/s.
  • Reduktimi i migrimit tĂ« menaxhuesve midis bĂ«rthamave tĂ« ndryshme CPU pĂ«r tĂ« rritur efikasitetin e pĂ«rdorimit tĂ« caches tĂ« procesorĂ«ve. Optimizimi u krye si nĂ« nivelin e lidhjes sĂ« proceseve libreactor me bĂ«rthamat e CPU (CPU Pinning), ashtu edhe pĂ«rmes fijes sĂ« menaxhuesve tĂ« rrjetit nĂ« bĂ«rthamĂ« (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 procesin libreactor dhe radhĂ«n e paketave hyrĂ«se, u angazhua njĂ« menaxhues BPF i veçantĂ«, i lidhur pĂ«rmes vendosjes sĂ« flamurit SO_ATTACH_REUSEPORT_CBPF gjatĂ« krijimit tĂ« soketit. PĂ«r lidhjen e CPU-sĂ« sĂ« radhĂ«ve tĂ« paketave dalĂ«se, u ndryshuan konfigurimet nĂ« /sys/class/net/eth0/queues/tx-<n>/xps_cpus. Rritja totale e performancĂ«s ishte 38%, ndĂ«rsa kapaciteti kaloi nga 603k req/s nĂ« 834k req/s.
  • Optimizimi i pĂ«rpunimit tĂ« ndĂ«rprerjeve dhe pĂ«rdorimi i polling. Aktivizimi i modit adaptive-rx nĂ« driverin ENA dhe manipulimet me sysctl net.core.busy_read lejuan ngritjen e performancĂ«s me 28% (kapaciteti 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 sistemore qĂ« çojnĂ« nĂ« bllokime tĂ« panevojshme nĂ« strukturĂ«n e rrjetit. Çaktivizimi i dhclient dhe vendosja adresat IP me dorĂ« e rriti performancĂ«n me 6%, ndĂ«rsa kapaciteti kaloi nga 1.06M req/s nĂ« 1.12M req/s. Arsyeja e ndikimit tĂ« dhclient nĂ« performancĂ« Ă«shtĂ« analizuar duke pĂ«rdorur soket tĂ« papĂ«rpunuar.
  • Lufta me Spin Lock. Kalimi i strukturĂ«s sĂ« rrjetit nĂ« modalitetin «noqueue» pĂ«rmes sysctl «net.core.default_qdisc=noqueue» dhe «tc qdisc replace dev eth0 root mq» solli njĂ« rritje tĂ« performancĂ«s me 2%, dhe kapaciteti kaloi nga 1.12M req/s nĂ« 1.15M req/s.
  • Optimizimet pĂ«rfundimtare tĂ« vogla, siç janĂ« ç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 ishte 4%. Kapaciteti kaloi nga 1.15M req/s nĂ« 1.2M req/s.

Përveç optimizimeve të realizuara, artikulli gjithashtu shqyrton metoda që nuk çuan në rritjen e pritur të performancës. Për shembull, ato që u treguan të pasuksesshme ishin:

  • NjĂ« nisje e veçantĂ« e libreactor nuk ndryshoi nĂ« performancĂ« nga nisja nĂ« kontejner. Nuk kishte ndikim zĂ«vendĂ«simi i writev me send, rritja e maxevents nĂ« epoll_wait, eksperimentet me versionet dhe flagjet e GCC (efekti ishte i dukshĂ«m vetĂ«m pĂ«r flagjet «-O3» dhe «-march-native»).
  • Update-i i bĂ«rthamĂ«s Linux nĂ« versionet 4.19 dhe 5.4 nuk ndikoi nĂ« performancĂ«, 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Ă« drejtuesin 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 patĂ«n ndikim.
  • Ndryshimet nĂ« stek-in e rrjetit nuk çuan nĂ« rritjen e performancĂ«s:
    • Çaktivizimi i IPv6: ipv6.disable=1
    • Çaktivizimi i VLAN: modprobe -rv 8021q
    • Çaktivizimi i verifikimit tĂ« burimit tĂ« paketave
      • 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

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