эле көпчүлүк билдирүүлөр, бөлүштүрүлгөн кызматта көйгөй бар, келгиле бул кызматты Элвин деп атайлы. Бул жолу мен көйгөйдү өзүм ачкан жокмун, мага кардар тараптын балдары кабарлашты.

Бир күнү мен Элвин менен узак убакыт бою кечигип жүргөндүктөн нааразы болгон электрондук каттан ойгонуп кеттим, аны биз жакынкы келечекте ишке киргизүүнү пландаштырганбыз. Тактап айтканда, кардар 99 мс чөлкөмдө 50-проценттилдик кечиктиришти, бул биздин күтүү бюджетинен бир топ жогору. Бул таң калыштуу болду, анткени мен кызматты кеңири сынап көрдүм, айрыкча кечигүү боюнча, бул жалпы даттануу.

Элвинди сынаганга чейин мен секундасына 40 миң суроо (QPS) менен көптөгөн эксперименттерди өткөрдүм, алардын бардыгы 10 мсден аз күтүү убактысын көрсөттү. Мен алардын жыйынтыгына макул эмес экенимди билдирүүгө даяр болчумун. Бирок катты дагы бир жолу карап, мен жаңы нерсени байкадым: мен алар айткан шарттарды так текшерген эмесмин, алардын QPS меникиден бир топ төмөн. Мен 40k QPSде сынап көрдүм, бирок алар 1к гана. Мен аларды тынчтандыруу үчүн дагы бир эксперимент жүргүздүм, бул жолу төмөнкү QPS менен.

Мен бул тууралуу блог жазып жаткандыктан, сиз алардын саны туура экенин түшүнгөн чыгарсыз. Мен виртуалдык кардарымды кайра-кайра сынап көрдүм, ошол эле натыйжа менен: сурамдардын аз саны күтүү убактысын гана көбөйтпөстөн, 10 мсден ашык күтүү убактысы менен сурамдардын санын көбөйтөт. Башкача айтканда, 40k QPSде секундасына 50гө жакын суроо 50 мс ашса, 1k QPSде секундасына 100 мсден жогору 50 суроо пайда болгон. Парадокс!

Издөөнү кыскартуу

Көптөгөн компоненттери бар бөлүштүрүлгөн тутумда күтүү көйгөйүнө туш болгондо, биринчи кадам шектүүлөрдүн кыска тизмесин түзүү болуп саналат. Элвиндин архитектурасына бир аз тереңирээк карайлы:

Жакшы башталгыч чекит - бул аяктаган киргизүү/чыгаруу өтүүлөрдүн тизмеси (тармак чалуулары/дисктен издөө ж.б.). Келгиле, кечигүү кайда экенин аныктоого аракет кылалы. Кардар менен ачык киргизүү/чыгаруудан тышкары, Элвин кошумча кадам жасайт: ал маалымат дүкөнүнө кирет. Бирок, бул сактагыч Элвин менен бир кластерде иштейт, андыктан ал жерде күтүү кардар менен караганда азыраак болушу керек. Ошентип, шектүүлөрдүн тизмеси:

1. Кардардан Элвинге тармактык чалуу.
2. Элвинден маалымат дүкөнүнө тармактык чалуу.
3. Маалымат дүкөнүндө дисктен издеңиз.
4. Маалымат кампасынан Элвинге тармактык чалуу.
5. Элвинден кардарга тармактык чалуу.

Келгиле, кээ бир пункттарды чийип салууга аракет кылалы.

Маалымат сактоонун ага эч кандай тиешеси жок

Биринчи кылганым, Элвинди суроо-талаптарды иштебеген пинг-пинг серверине айландырдым. Сурам кабыл алганда, ал бош жооп кайтарат. Эгерде кечигүү азайса, анда Alvin же маалымат кампасын ишке ашырууда ката угулган эмес. Биринчи экспериментте төмөнкү графикти алабыз:

Көрүнүп тургандай, пинг-пинг серверин колдонууда эч кандай жакшыруу жок. Бул маалымат кампасы күтүү убактысын көбөйтпөйт жана шектүүлөрдүн тизмеси экиге кыскарат дегенди билдирет:

1. Кардардан Элвинге тармактык чалуу.
2. Элвинден кардарга тармактык чалуу.

Абдан жакшы! Тизме тез азайып баратат. Мен анын себебин дээрлик түшүндүм деп ойлодум.

gRPC

Эми сизди жаңы оюнчу менен тааныштыруунун убагы келди: gRPC. Бул процесстеги баарлашуу үчүн Google'дун ачык булак китепканасы RPC... Бирок gRPC жакшы оптималдаштырылган жана кеңири колдонулган, бул мен аны ушундай өлчөмдөгү системада биринчи жолу колдонуп жаткам жана менин ишке ашыруум оптималдуу эмес деп күткөн элем.

болушу gRPC стекте жаңы суроо пайда болду: балким, бул менин ишке ашыруум же өзүм gRPC кечигүү көйгөйүн жаратып жатабы? Тизмеге жаңы шектүүнү кошуу:

1. Кардар китепкананы чакырат gRPC
2. китепкана gRPC кардардагы китепканага тармактык чалуу жасайт gRPC серверде
3. китепкана gRPC контакты Элвин (пинг-понг серверинде операция жок)

Код кандай экени жөнүндө түшүнүк берүү үчүн, менин кардарымдын/Элвиндин ишке ашырылышы кардар-серверден анча деле айырмаланбайт. асинхрондуу мисалдар.

Эскертүү: Жогорудагы тизме бир аз жөнөкөйлөштүрүлгөн, анткени gRPC аткаруу стек чырмалышкан өз (шаблон?) жип моделин колдонууга мүмкүндүк берет. gRPC жана колдонуучу ишке ашыруу. Жөнөкөйлүк үчүн биз бул моделди карманабыз.

Профиль түзүү баарын оңдойт

Маалымат дүкөндөрүн чийип чыгып, мен дээрлик бүтүп калдым деп ойлодум: “Эми бул оңой! Келгиле, профилди колдонуп, кечигүү кайда экенин билели." И так профилдөөнүн чоң күйөрманы, анткени процессорлор абдан тез жана көбүнчө тоскоолдук жаратпайт. Көпчүлүк кечигүү процессор башка нерсени жасоо үчүн иштетүүнү токтотушу керек болгондо пайда болот. Так CPU профили ушуну жасайт: ал баарын так жазат контексттик которгучтар жана кечигүүлөрдүн кайсы жерде болоорун ачыктайт.

Мен төрт профилди алдым: жогорку QPS (төмөн күтүү мөөнөтү) жана төмөнкү QPS (жогорку кечигүү) менен пинг-понг сервери менен, кардар тарабында да, сервер тарабында да. Болбосо, мен дагы үлгү процессор профилин алдым. Профильдерди салыштырганда мен адатта аномалдуу чалуулар стекин издейм. Мисалы, жогорку күтүү менен жаман жагында дагы көптөгөн контексттик которгучтар бар (10 эсе же андан көп). Бирок менин учурда контексттик которгучтардын саны дээрлик бирдей эле. Менин коркунучтуусу, ал жерде маанилүү эч нерсе болгон жок.

Кошумча мүчүлүштүктөрдү оңдоо

Мен айласыз калдым. Мен дагы кандай куралдарды колдоно аларымды билбей калдым жана менин кийинки планым проблеманы так диагноздоонун ордуна эксперименттерди ар кандай вариациялар менен кайталоо болчу.

Эмне болсо

Мен башынан эле 50 мс кечигүү жөнүндө тынчсыздандым. Бул абдан чоң убакыт. Кайсы бөлүк бул катага себеп болгонун так аныктамайынча, коддон бөлүктөрдү кесип салууну чечтим. Андан кийин иштеген эксперимент келди.

Адаттагыдай эле, артка кылчайганда баары ачык эле көрүнүп тургандай. Мен кардарды Элвин менен бир машинага жайгаштырдым жана ага суроо-талап жөнөттүм localhost. Жана кечиктирүүнүн өсүшү жок!

Тармакта бир жерден ката кетти.

Тармак инженеринин көндүмдөрүн үйрөнүү

Моюнга алышым керек: тармактык технологиялар боюнча менин билимим коркунучтуу, айрыкча алар менен күн сайын иштешкенимди эске алсам. Бирок тармак башкы шектүү болгон жана мен аны оңдоону үйрөнүшүм керек болчу.

Бактыга жараша, Интернет үйрөнүүнү каалагандарды жакшы көрөт. Ping жана tracert айкалышы тармактык транспорт көйгөйлөрүн оңдоо үчүн жетиштүү жакшы башталыш сыяктуу көрүндү.

Биринчиден, мен ишке киргиздим PsPing Элвиндин TCP портуна. Мен демейки жөндөөлөрдү колдондум - өзгөчө эч нерсе жок. Миңден ашык пингдин бири да 10 мс ашкан жок, биринчиси жылытуу үчүн. Бул 50-проценттилде байкалган 99 мс кечигүүнүн көбөйүшүнө карама-каршы келет: ал жерде ар бир 100 сурам үчүн биз 50 мс кечигүү менен бир суроону көрүшүбүз керек болчу.

Анан аракет кылдым издоочу: Элвин менен кардар ортосундагы каттамдагы түйүндөрдүн биринде көйгөй болушу мүмкүн. Бирок из салуучу да куру кол кайтты.

Демек, кечигүүгө менин кодум, gRPC ишке ашыруусу же тармак себеп болгон эмес. Мен муну эч качан түшүнбөйм деп тынчсыздана баштадым.

Эми биз кандай ОС менен иштейбиз

gRPC Linuxта кеңири колдонулат, бирок Windowsта экзотикалык. Мен эксперимент жасап көрүүнү чечтим, ал иштеген: мен Linux виртуалдык машинасын түзүп, Linux үчүн Alvin компиляциялап, аны жайгаштырдым.

Мына ушундай болду: Linux пинг-понг серверинде Windowsтун окшош хосту сыяктуу кечигүү болгон эмес, бирок маалымат булагы эч кандай айырмаланбайт. Көйгөй Windows үчүн gRPC ишке ашырууда экени көрүнүп турат.

Наглдын алгоритми

Ушул убакыттын ичинде мен желек жок болуп калдым деп ойлодум gRPC. Эми анын чындыгында эмне экенин түшүндүм gRPC Windows желеги жок. Мен бардык желекчелер үчүн жакшы иштей турган ички RPC китепканасын таптым WinSock. Анан мен бул желектердин баарын gRPCге кошуп, Elvinди Windows'тун жаңыланган Windows пинг-понг серверинде жайгаштырдым!

дээрлик Бүттү: Мен регрессия кайтып келгенге чейин, себебин так аныктоо үчүн кошулган желектерди бирден алып сала баштадым. Бул атактуу болгон TCP_NODELAY, Наглдын алгоритмин алмаштыргыч.

Наглдын алгоритми пакеттин көлөмү белгилүү бир байт санынан ашканга чейин билдирүүлөрдү берүүнү кечеңдетүү аркылуу тармак аркылуу жөнөтүлгөн пакеттердин санын кыскартууга аракет кылат. Бул жөнөкөй колдонуучу үчүн жагымдуу болушу мүмкүн, бирок бул реалдуу убакыт серверлери үчүн кыйратуучу, анткени OS кээ бир билдирүүлөрдү кечеңдетип, QPSтин төмөндүгүнөн артта калууларды жаратат. У gRPC бул желек TCP розеткалары үчүн Linux ишке ашырууда коюлган, бирок Windows эмес. мен булмын оңдолду.

жыйынтыктоо

Төмөн QPSдеги жогорку күтүү OS оптималдаштыруудан улам келип чыккан. Кийинчерээк, профилдештирүү кечиктирүүнү аныктаган жок, анткени ал өзөк режиминде эмес, ядро ​​​​режиминде жасалган колдонуучу режими. Мен Наглдын алгоритмин ETW тартуу аркылуу байкоого болобу, билбейм, бирок бул кызыктуу болмок.

Localhost экспериментине келсек, ал чыныгы тармактык кодго тийген жок жана Наглдын алгоритми иштебей калды, ошондуктан кардар localhost аркылуу Элвинге жеткенде күтүү маселеси жоюлду.

Кийинки жолу секундасына сурамдардын саны азайган сайын күтүү убактысынын көбөйгөнүн көргөндө, Наглдын алгоритми шектүүлөрдүн тизмесинде болушу керек!

Source: www.habr.com