Kaya ing paling kiriman, ana masalah karo layanan sing disebarake, ayo nelpon layanan iki Alvin. Wektu iki aku ora nemokake masalah dhewe, wong lanang saka sisih klien ngandhani aku.

Sawijining dina aku tangi karo email sing ora seneng amarga telat karo Alvin, sing bakal diluncurake ing mangsa ngarep. Khususe, klien ngalami latensi persentil kaping 99 ing wilayah 50 ms, luwih saka anggaran latensi. Iki kaget amarga aku nyoba layanan kasebut kanthi ekstensif, utamane babagan latensi, sing minangka keluhan umum.

Sadurunge aku nyoba Alvin, aku nindakake akeh eksperimen kanthi 40k pitakon per detik (QPS), kabeh nuduhake latensi kurang saka 10ms. Aku siap ngumumake yen aku ora setuju karo asile. Nanging njupuk dipikir liyane ing layang, Aku ngeweruhi soko anyar: Aku wis ora persis dites kondisi padha kasebut, QPS padha luwih murah tinimbang mine. Aku dites ing 40k QPS, nanging padha mung ing 1k. Aku mlayu eksperimen liyane, wektu iki karo QPS ngisor, mung kanggo appease wong.

Wiwit aku ngeblog babagan iki, sampeyan bisa uga wis ngerti manawa nomer kasebut bener. Aku nyoba klien virtualku bola-bali, kanthi asil sing padha: jumlah panjaluk sing kurang ora mung nambah latensi, nanging nambah jumlah panjalukan kanthi latensi luwih saka 10 ms. Ing tembung liya, yen ing 40k QPS kira-kira 50 panjalukan per detik ngluwihi 50 ms, banjur ing 1k QPS ana 100 panjalukan ing ndhuwur 50 ms saben detik. Paradoks!

Narrowing mudhun panelusuran

Nalika ngadhepi masalah latensi ing sistem sing disebarake kanthi akeh komponen, langkah pisanan yaiku nggawe dhaptar singkat tersangka. Ayo digali luwih jero babagan arsitektur Alvin:

Titik wiwitan sing apik yaiku dhaptar transisi I / O sing wis rampung (panggilan jaringan / goleki disk, lsp). Ayo dadi nyoba kanggo mangerteni ing ngendi wektu tundha. Saliyane I / O sing jelas karo klien, Alvin njupuk langkah ekstra: dheweke ngakses toko data. Nanging, panyimpenan iki makaryakke ing cluster padha Alvin, supaya latensi ana kudu kurang saka karo klien. Dadi, dhaptar tersangka:

Telpon jaringan saka klien menyang Alvin.
Telpon jaringan saka Alvin menyang toko data.
Telusuri ing disk ing nyimpen data.
Telpon jaringan saka gudang data menyang Alvin.
Telpon jaringan saka Alvin menyang klien.

Ayo nyoba nyabrang sawetara titik.

Panyimpenan data ora ana hubungane

Wangsulan: Bab ingkang pisanan aku nindakake iku Ngonversi Alvin menyang server ping-ping sing ora proses panjalukan. Nalika nampa panjalukan, ngasilake respon kosong. Yen latensi mudhun, bug ing implementasine Alvin utawa gudang data ora ana sing ora dingerteni. Ing eksperimen pisanan kita entuk grafik ing ngisor iki:

Kaya sing sampeyan ngerteni, ora ana perbaikan nalika nggunakake server ping-ping. Iki tegese gudang data ora nambah latensi, lan dhaptar tersangka dipotong setengah:

Telpon jaringan saka klien menyang Alvin.
Telpon jaringan saka Alvin menyang klien.

apik tenan! Daftar kasebut nyusut kanthi cepet. Aku panginten aku wis meh figured metu alesan.

gRPC

Saiki iki wektu kanggo ngenalake sampeyan pemain anyar: gRPC. Iki minangka perpustakaan open source saka Google kanggo komunikasi ing proses CPR... Padahal gRPC uga optimized lan digunakake digunakake, iki pisanan nggunakake ing sistem ukuran iki lan aku samesthine implementasine dadi suboptimal - ngomong paling.

kasedhiyan gRPC ing tumpukan nuwuhake pitakonan anyar: Mungkin iku implementasine utawa aku gRPC nyebabake masalah latensi? Nambahake tersangka anyar menyang dhaptar:

Klien nelpon perpustakaan gRPC
perpustakaan gRPC ndadekake telpon jaringan kanggo perpustakaan ing klien gRPC ing server
perpustakaan gRPC kontak Alvin (ora ana operasi ing kasus server ping-pong)

Kanggo menehi gambaran babagan kaya apa kode kasebut, implementasine klien / Alvin saya ora beda karo klien-server. conto async.

Cathetan: Dhaptar ing ndhuwur rada disederhanakake amarga gRPC ndadekake iku bisa kanggo nggunakake model threading dhewe (template?), kang tumpukan eksekusi intertwined gRPC lan implementasine pangguna. Kanggo kesederhanaan, kita bakal tetep nganggo model iki.

Profiling bakal ndandani kabeh

Sawise nyabrang toko data, aku rumangsa wis meh rampung: "Saiki gampang! Ayo aplikasi profil lan temokake ing ngendi wektu tundha. aku penggemar amba saka profil tliti, amarga CPU cepet banget lan paling asring ora bottleneck. Paling telat kedadeyan nalika prosesor kudu mandheg ngolah kanggo nindakake tindakan liya. Akurat CPU Profiling mung sing: iku kanthi akurat ngrekam kabeh ngalih konteks lan nerangake ngendi telat dumadi.

Aku njupuk papat profil: karo QPS dhuwur (latensi kurang) lan karo server ping-pong karo QPS kurang (latensi dhuwur), loro ing sisih klien lan ing sisih server. Lan mung ing kasus, Aku uga njupuk sampel profil prosesor. Nalika mbandhingaké profil, Aku biasane goleki tumpukan telpon anomali. Contone, ing sisih ala karo latensi dhuwur ana akeh switch konteks liyane (10 kaping utawa luwih). Nanging ing kasusku, jumlah switch konteks meh padha. Kanggo medeni, ora ana sing penting ing kana.

Debugging Tambahan

Aku nekat. Aku ora ngerti alat liyane sing bisa digunakake, lan rencana sabanjure yaiku mbaleni eksperimen kanthi variasi sing beda-beda tinimbang diagnosa masalah kasebut kanthi jelas.

Kepiye yen

Wiwit wiwitan, aku prihatin babagan latensi 50ms tartamtu. Iki wektu gedhe banget. Aku mutusaké sing aku bakal Cut chunks metu saka kode nganti aku bisa tokoh metu persis kang bagean nyebabake kesalahan iki. Banjur teka eksperimen sing makarya.

Kaya biasane, ing mburi katon kabeh katon jelas. Aku diselehake klien ing mesin padha Alvin - lan dikirim panjalukan kanggo localhost. Lan tambah latensi wis ilang!

Ana sing salah karo jaringan.

Sinau katrampilan insinyur jaringan

Aku kudu ngakoni: kawruh babagan teknologi jaringan pancen nggegirisi, utamane yen aku kerja bareng saben dina. Nanging jaringan kasebut minangka tersangka utama, lan aku kudu sinau carane debug.

Untunge, Internet seneng karo wong sing pengin sinau. Kombinasi ping lan tracert katon kaya wiwitan sing cukup apik kanggo debugging masalah transportasi jaringan.

Kaping pisanan, aku miwiti PsPing menyang port TCP Alvin. Aku digunakake setelan gawan - boten khusus. Saka luwih saka sewu ping, ora ana sing ngluwihi 10 ms, kajaba sing pisanan kanggo pemanasan. Iki bertentangan karo kenaikan latensi 50 ms ing persentil kaping 99: ing kono, kanggo saben 100 panjaluk, kita kudu ndeleng babagan siji panyuwunan kanthi latensi 50 ms.

Aku banjur nyoba tracer: Bisa uga ana masalah ing salah sawijining kelenjar ing rute antarane Alvin lan klien. Nanging tracer uga bali karo tangan kosong.

Dadi dudu kodeku, implementasi gRPC, utawa jaringan sing nyebabake wektu tundha. Aku wiwit kuwatir yen aku ora bakal ngerti iki.

Saiki kita nganggo OS apa

gRPC digunakake digunakake ing Linux, nanging endah ing Windows. Aku mutusaké kanggo nyoba eksperimen, kang bisa: Aku nggawe mesin virtual Linux, nyawiji Alvin kanggo Linux, lan disebaraké.

Lan iki kedadeyan: server ping-pong Linux ora duwe wektu tundha sing padha karo host Windows sing padha, sanajan sumber data ora beda. Pranyata masalah kasebut ana ing implementasi gRPC kanggo Windows.

Algoritma Nagle

Kabeh wektu iki aku mikir aku ilang gendera gRPC. Saiki aku ngerti apa sejatine gRPC Gendéra Windows ora ana. Aku nemokake perpustakaan RPC internal sing aku yakin bakal bisa digunakake kanggo kabeh gendéra winsock. Banjur aku nambahake kabeh panji kasebut menyang gRPC lan masang Alvin ing Windows, ing server ping-pong Windows sing ditambal!

Meh Rampung: Aku miwiti mbusak panji sing ditambahake siji-sijine nganti regresi bali supaya aku bisa nemtokake sababe. Iku kondhang TCP_NODELAY, ngalih algoritma Nagle kang.

Algoritma Nagle nyoba nyuda jumlah paket sing dikirim liwat jaringan kanthi nundha transmisi pesen nganti ukuran paket ngluwihi jumlah bita tartamtu. Nalika iki uga becik kanggo pangguna rata-rata, iku ngrusak kanggo server nyata-wektu amarga OS bakal tundha sawetara pesen, nyebabake lags QPS kurang. U gRPC flag iki disetel ing implementasine Linux kanggo soket TCP, nanging ora ing Windows. Aku iki didandani.

kesimpulan

Latensi sing luwih dhuwur ing QPS kurang disebabake optimasi OS. Ing retrospect, profiling ora ndeteksi latensi amarga wis rampung ing mode kernel tinimbang ing mode pangguna. Aku ora ngerti yen algoritma Nagle bisa diamati liwat ETW dijupuk, nanging bakal menarik.

Kanggo eksperimen localhost, mbokmenawa ora ndemek kode jaringan sing nyata lan algoritma Nagle ora mlaku, mula masalah latensi ilang nalika klien tekan Alvin liwat localhost.

Yen sampeyan ndeleng kenaikan latensi amarga jumlah panjaluk saben detik suda, algoritma Nagle kudu ana ing dhaptar tersangka!

Source: www.habr.com

Kadang luwih kurang. Nalika ngurangi beban nyebabake nambah latensi