લેખનો અનુવાદ: એન્વોય થ્રેડીંગ મોડલ - https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310

મને આ લેખ ખૂબ જ રસપ્રદ લાગ્યો, અને કારણ કે રાજદૂતનો ઉપયોગ મોટાભાગે "ઇસ્ટિઓ" ના ભાગ રૂપે અથવા ફક્ત કુબરનેટ્સના "ઇન્ગ્રેસ કંટ્રોલર" તરીકે થાય છે, મોટાભાગના લોકો તેની સાથે સમાન સીધી ક્રિયાપ્રતિક્રિયા ધરાવતા નથી, ઉદાહરણ તરીકે, લાક્ષણિક સાથે. Nginx અથવા Haproxy સ્થાપનો. જો કે, જો કંઈક તૂટી જાય, તો તે અંદરથી કેવી રીતે કાર્ય કરે છે તે સમજવું સારું રહેશે. મેં ખાસ શબ્દો સહિત શક્ય તેટલું લખાણનો રશિયનમાં અનુવાદ કરવાનો પ્રયાસ કર્યો; જેમને આ જોવાનું દુઃખદાયક લાગે છે, મેં મૂળ કૌંસમાં છોડી દીધું છે. બિલાડીમાં આપનું સ્વાગત છે.

એન્વોય કોડબેઝ માટે નિમ્ન-સ્તરના તકનીકી દસ્તાવેજીકરણ હાલમાં ખૂબ ઓછા છે. આના ઉકેલ માટે, હું દૂતની વિવિધ સબસિસ્ટમ્સ વિશે શ્રેણીબદ્ધ બ્લોગ પોસ્ટ્સ કરવાની યોજના ઘડી રહ્યો છું. આ પ્રથમ લેખ હોવાથી, કૃપા કરીને મને જણાવો કે તમે શું વિચારો છો અને તમને ભવિષ્યના લેખોમાં શું રસ હોઈ શકે છે.

દૂત વિશે મને પ્રાપ્ત થયેલ સૌથી સામાન્ય તકનીકી પ્રશ્નો પૈકી એક તે જે થ્રેડીંગ મોડેલનો ઉપયોગ કરે છે તેના નિમ્ન-સ્તરના વર્ણન માટે પૂછે છે. આ પોસ્ટમાં, હું વર્ણન કરીશ કે કેવી રીતે દૂત થ્રેડો સાથે જોડાણો મેપ કરે છે, તેમજ થ્રેડ લોકલ સ્ટોરેજ સિસ્ટમ જે કોડને વધુ સમાંતર અને ઉચ્ચ-પ્રદર્શન બનાવવા માટે આંતરિક રીતે વાપરે છે.

થ્રેડિંગ વિહંગાવલોકન

રાજદૂત ત્રણ અલગ-અલગ પ્રકારના પ્રવાહોનો ઉપયોગ કરે છે:

• મુખ્ય: આ થ્રેડ પ્રોસેસ સ્ટાર્ટઅપ અને ટર્મિનેશનને નિયંત્રિત કરે છે, XDS (xDiscovery Service) API ની તમામ પ્રક્રિયા, જેમાં DNS, હેલ્થ ચેકિંગ, સામાન્ય ક્લસ્ટર અને રનટાઇમ મેનેજમેન્ટ, સ્ટેટિસ્ટિક્સ રીસેટ, એડમિનિસ્ટ્રેશન અને સામાન્ય પ્રોસેસ મેનેજમેન્ટ - Linux સિગ્નલ્સ. હોટ રીસ્ટાર્ટ, વગેરે બધું જ. આ થ્રેડમાં થાય છે તે અસુમેળ અને "નોન-બ્લોકીંગ" છે. સામાન્ય રીતે, મુખ્ય થ્રેડ બધી જટિલ કાર્યક્ષમતા પ્રક્રિયાઓનું સંકલન કરે છે જેને ચલાવવા માટે મોટી માત્રામાં CPU ની જરૂર પડતી નથી. આ મોટાભાગના નિયંત્રણ કોડને લખવાની મંજૂરી આપે છે જાણે કે તે સિંગલ થ્રેડેડ હોય.
• કાર્યકર: મૂળભૂત રીતે, દૂત સિસ્ટમમાં દરેક હાર્ડવેર થ્રેડ માટે વર્કર થ્રેડ બનાવે છે, આ વિકલ્પનો ઉપયોગ કરીને નિયંત્રિત કરી શકાય છે. --concurrency. દરેક વર્કર થ્રેડ "નોન-બ્લોકીંગ" ઇવેન્ટ લૂપ ચલાવે છે, જે દરેક શ્રોતાને સાંભળવા માટે જવાબદાર છે; લખવાના સમયે (જુલાઈ 29, 2017) શ્રોતાનું કોઈ શૉર્ડિંગ નથી, નવા કનેક્શન્સ સ્વીકારવા, ફિલ્ટર સ્ટેકને ઇન્સ્ટન્ટિએટ કરવા માટે કનેક્શન, અને કનેક્શનના જીવનકાળ દરમિયાન તમામ ઇનપુટ/આઉટપુટ (IO) ઓપરેશન્સ પર પ્રક્રિયા કરે છે. ફરીથી, આ મોટાભાગના કનેક્શન હેન્ડલિંગ કોડને સિંગલ થ્રેડેડ હોય તેમ લખવાની મંજૂરી આપે છે.
• ફાઇલ ફ્લશર: દરેક ફાઇલ કે જે દૂત લખે છે, મુખ્યત્વે લોગ ઍક્સેસ કરે છે, હાલમાં સ્વતંત્ર બ્લોકીંગ થ્રેડ ધરાવે છે. આ એ હકીકતને કારણે છે કે ઉપયોગ કરતી વખતે પણ ફાઇલ સિસ્ટમ દ્વારા કેશ કરેલી ફાઇલોને લખવાનું O_NONBLOCK ક્યારેક અવરોધિત થઈ શકે છે (નિસાસો). જ્યારે વર્કર થ્રેડોને ફાઇલ પર લખવાની જરૂર હોય, ત્યારે ડેટાને ખરેખર મેમરીમાં બફરમાં ખસેડવામાં આવે છે જ્યાં તે આખરે થ્રેડ દ્વારા ફ્લશ થાય છે. ફાઇલ ફ્લશ. આ કોડનો એક વિસ્તાર છે જ્યાં તકનીકી રીતે તમામ વર્કર થ્રેડો મેમરી બફર ભરવાનો પ્રયાસ કરતી વખતે સમાન લોકને અવરોધિત કરી શકે છે.

કનેક્શન હેન્ડલિંગ

ઉપર સંક્ષિપ્તમાં ચર્ચા કર્યા મુજબ, બધા વર્કર થ્રેડો કોઈપણ શૉર્ડિંગ વિના બધા શ્રોતાઓને સાંભળે છે. આમ, કર્નલનો ઉપયોગ વર્કર થ્રેડો પર સ્વીકૃત સોકેટોને આકર્ષક રીતે મોકલવા માટે થાય છે. આધુનિક કર્નલો સામાન્ય રીતે આમાં ખૂબ સારા હોય છે, તેઓ સમાન સોકેટ પર સાંભળતા હોય તેવા અને રાઉન્ડ રોબિનનો ઉપયોગ કરતા ન હોય તેવા અન્ય થ્રેડોનો ઉપયોગ શરૂ કરતા પહેલા કામ સાથે થ્રેડ ભરવાનો પ્રયાસ કરવા માટે ઇનપુટ/આઉટપુટ (IO) પ્રાથમિકતા બૂસ્ટિંગ જેવી સુવિધાઓનો ઉપયોગ કરે છે. દરેક વિનંતી પર પ્રક્રિયા કરવા માટે લોકીંગ (સ્પિનલોક).
એકવાર વર્કર થ્રેડ પર કનેક્શન સ્વીકારવામાં આવે, તે તે થ્રેડને ક્યારેય છોડતું નથી. કનેક્શનની આગળની બધી પ્રક્રિયાઓ કોઈપણ ફોરવર્ડિંગ વર્તન સહિત, વર્કર થ્રેડમાં સંપૂર્ણપણે નિયંત્રિત થાય છે.

આના ઘણા મહત્વપૂર્ણ પરિણામો છે:

• એન્વોયમાં તમામ કનેક્શન પૂલ વર્કર થ્રેડને સોંપવામાં આવ્યા છે. તેથી, જો કે HTTP/2 કનેક્શન પૂલ એક સમયે દરેક અપસ્ટ્રીમ હોસ્ટ સાથે માત્ર એક જ જોડાણ બનાવે છે, જો ત્યાં ચાર વર્કર થ્રેડો હોય, તો સ્થિર સ્થિતિમાં અપસ્ટ્રીમ હોસ્ટ દીઠ ચાર HTTP/2 જોડાણો હશે.
• દૂત આ રીતે કામ કરે છે તેનું કારણ એ છે કે દરેક વસ્તુને સિંગલ વર્કર થ્રેડ પર રાખીને, લગભગ તમામ કોડ બ્લોક કર્યા વિના લખી શકાય છે અને જાણે કે તે સિંગલ થ્રેડેડ હોય. આ ડિઝાઇન લગભગ અમર્યાદિત સંખ્યામાં વર્કર થ્રેડો પર ઘણા બધા કોડ અને સ્કેલ અવિશ્વસનીય રીતે લખવાનું સરળ બનાવે છે.
• જો કે, મુખ્ય ઉપાયોમાંની એક એ છે કે મેમરી પૂલ અને કનેક્શન કાર્યક્ષમતાના દૃષ્ટિકોણથી, વાસ્તવમાં રૂપરેખાંકિત કરવું ખૂબ જ મહત્વપૂર્ણ છે. --concurrency. જરૂરી કરતાં વધુ વર્કર થ્રેડો રાખવાથી મેમરીનો બગાડ થશે, વધુ નિષ્ક્રિય કનેક્શન્સ બનશે અને કનેક્શન પૂલિંગનો દર ઘટશે. Lyft ખાતે, અમારા દૂત સાઇડકાર કન્ટેનર ખૂબ જ ઓછી સંમતિ સાથે ચાલે છે જેથી કામગીરી તેઓની બાજુમાં બેઠેલી સેવાઓ સાથે લગભગ મેળ ખાય. અમે દૂતને એજ પ્રોક્સી તરીકે માત્ર મહત્તમ સંમતિ પર ચલાવીએ છીએ.

નોન-બ્લોકિંગનો અર્થ શું છે?

મુખ્ય અને કાર્યકર થ્રેડો કેવી રીતે કાર્ય કરે છે તેની ચર્ચા કરતી વખતે "નોન-બ્લોકીંગ" શબ્દનો અત્યાર સુધી ઘણી વખત ઉપયોગ કરવામાં આવ્યો છે. બધા કોડ એ ધારણા પર લખેલા છે કે કંઈપણ ક્યારેય અવરોધિત નથી. જો કે, આ સંપૂર્ણ રીતે સાચું નથી (શું સંપૂર્ણ રીતે સાચું નથી?).

દૂત ઘણા લાંબા પ્રક્રિયા તાળાઓનો ઉપયોગ કરે છે:

• જેમ જેમ ચર્ચા કરવામાં આવી છે, એક્સેસ લોગ લખતી વખતે, ઇન-મેમરી લોગ બફર ભરાય તે પહેલા બધા વર્કર થ્રેડો સમાન લોક મેળવે છે. લૉક હોલ્ડિંગનો સમય ઘણો ઓછો હોવો જોઈએ, પરંતુ ઉચ્ચ સંમતિ અને ઉચ્ચ થ્રુપુટ પર લૉક માટે સ્પર્ધા કરવી શક્ય છે.
• દૂત આંકડાઓને હેન્ડલ કરવા માટે ખૂબ જ જટિલ સિસ્ટમનો ઉપયોગ કરે છે જે થ્રેડ માટે સ્થાનિક છે. આ એક અલગ પોસ્ટનો વિષય હશે. જો કે, હું સંક્ષિપ્તમાં ઉલ્લેખ કરીશ કે સ્થાનિક સ્તરે થ્રેડના આંકડા પર પ્રક્રિયા કરવાના ભાગરૂપે, કેટલીકવાર કેન્દ્રીય "આંકડા સ્ટોર" પર લૉક મેળવવું જરૂરી છે. આ લોકીંગ ક્યારેય જરૂરી ન હોવું જોઈએ.
• મુખ્ય થ્રેડને સમયાંતરે બધા વર્કર થ્રેડો સાથે સંકલન કરવાની જરૂર છે. આ મુખ્ય થ્રેડમાંથી વર્કર થ્રેડ પર "પ્રકાશિત" દ્વારા કરવામાં આવે છે, અને કેટલીકવાર વર્કર થ્રેડમાંથી મુખ્ય થ્રેડ પર પાછા ફરે છે. મોકલવા માટે લૉકની આવશ્યકતા છે જેથી પ્રકાશિત સંદેશને પછીથી ડિલિવરી માટે કતારબદ્ધ કરી શકાય. આ તાળાઓ ક્યારેય ગંભીરતાથી લડવા જોઈએ નહીં, પરંતુ તે હજી પણ તકનીકી રીતે અવરોધિત થઈ શકે છે.
• જ્યારે દૂત સિસ્ટમ એરર સ્ટ્રીમ (સ્ટાન્ડર્ડ એરર) પર લોગ લખે છે, ત્યારે તે સમગ્ર પ્રક્રિયા પર લોક મેળવે છે. સામાન્ય રીતે, દૂતનું સ્થાનિક લોગિંગ કામગીરીના દૃષ્ટિકોણથી ભયંકર માનવામાં આવે છે, તેથી તેને સુધારવા પર વધુ ધ્યાન આપવામાં આવ્યું નથી.
• ત્યાં કેટલાક અન્ય રેન્ડમ તાળાઓ છે, પરંતુ તેમાંથી કોઈ પણ કામગીરી જટિલ નથી અને તેને ક્યારેય પડકારવામાં આવવી જોઈએ નહીં.

થ્રેડ સ્થાનિક સંગ્રહ

દૂત જે રીતે મુખ્ય થ્રેડની જવાબદારીઓને વર્કર થ્રેડની જવાબદારીઓથી અલગ કરે છે તેના કારણે, મુખ્ય થ્રેડ પર જટિલ પ્રક્રિયા કરી શકાય અને તે પછી દરેક વર્કર થ્રેડને અત્યંત સહવર્તી રીતે પૂરી પાડવામાં આવે તેવી આવશ્યકતા છે. આ વિભાગ ઉચ્ચ સ્તરે એન્વોય થ્રેડ લોકલ સ્ટોરેજ (TLS)નું વર્ણન કરે છે. આગળના વિભાગમાં હું વર્ણન કરીશ કે ક્લસ્ટરનું સંચાલન કરવા માટે તેનો ઉપયોગ કેવી રીતે થાય છે.


પહેલેથી જ વર્ણવ્યા મુજબ, મુખ્ય થ્રેડ દૂત પ્રક્રિયામાં વર્ચ્યુઅલ રીતે તમામ સંચાલન અને નિયંત્રણ પ્લેન કાર્યક્ષમતાને સંભાળે છે. કંટ્રોલ પ્લેન અહીં થોડું ઓવરલોડેડ છે, પરંતુ જ્યારે તમે તેને એન્વોય પ્રક્રિયામાં જ જુઓ છો અને વર્કર થ્રેડો જે ફોરવર્ડિંગ કરે છે તેની સાથે તેની તુલના કરો છો, તે અર્થપૂર્ણ છે. સામાન્ય નિયમ એ છે કે મુખ્ય થ્રેડ પ્રક્રિયા અમુક કાર્ય કરે છે, અને પછી તે કાર્યના પરિણામ અનુસાર દરેક વર્કર થ્રેડને અપડેટ કરવાની જરૂર છે. આ કિસ્સામાં, વર્કર થ્રેડને દરેક એક્સેસ પર લોક મેળવવાની જરૂર નથી.

રાજદૂતની TLS (થ્રેડ લોકલ સ્ટોરેજ) સિસ્ટમ નીચે મુજબ કામ કરે છે:

• મુખ્ય થ્રેડ પર ચાલતો કોડ સમગ્ર પ્રક્રિયા માટે TLS સ્લોટ ફાળવી શકે છે. જો કે આ અમૂર્ત છે, વ્યવહારમાં તે વેક્ટરમાં ઇન્ડેક્સ છે, જે O(1) ઍક્સેસ પ્રદાન કરે છે.
• મુખ્ય થ્રેડ તેના સ્લોટમાં મનસ્વી ડેટા ઇન્સ્ટોલ કરી શકે છે. જ્યારે આ થઈ જાય છે, ત્યારે ડેટા દરેક વર્કર થ્રેડ પર સામાન્ય ઇવેન્ટ લૂપ ઇવેન્ટ તરીકે પ્રકાશિત થાય છે.
• વર્કર થ્રેડો તેમના TLS સ્લોટમાંથી વાંચી શકે છે અને ત્યાં ઉપલબ્ધ કોઈપણ થ્રેડ-સ્થાનિક ડેટાને પુનઃપ્રાપ્ત કરી શકે છે.

જો કે તે ખૂબ જ સરળ અને અવિશ્વસનીય રીતે શક્તિશાળી દૃષ્ટાંત છે, તે RCU (રીડ-કોપી-અપડેટ) બ્લોકિંગના ખ્યાલ સાથે ખૂબ જ સમાન છે. અનિવાર્યપણે, વર્કર થ્રેડો જ્યારે કામ ચાલી રહ્યું હોય ત્યારે TLS સ્લોટમાં ડેટામાં કોઈ ફેરફાર જોતા નથી. ફેરફાર ફક્ત કામની ઘટનાઓ વચ્ચેના બાકીના સમયગાળા દરમિયાન થાય છે.

રાજદૂત આનો ઉપયોગ બે અલગ અલગ રીતે કરે છે:

• દરેક વર્કર થ્રેડ પર અલગ-અલગ ડેટા સ્ટોર કરીને, કોઈપણ અવરોધ વિના ડેટા એક્સેસ કરી શકાય છે.
• દરેક વર્કર થ્રેડ પર ફક્ત વાંચવા માટેના મોડમાં વૈશ્વિક ડેટા માટે શેર કરેલ પોઇન્ટરને જાળવી રાખીને. આમ, દરેક વર્કર થ્રેડમાં ડેટા રેફરન્સ કાઉન્ટ હોય છે જે કામ ચાલુ હોય ત્યારે ઘટાડી શકાતું નથી. જ્યારે બધા કામદારો શાંત થઈ જશે અને શેર કરેલ નવો ડેટા અપલોડ કરશે ત્યારે જ જૂનો ડેટા નાશ પામશે. આ RCU સમાન છે.

ક્લસ્ટર અપડેટ થ્રેડીંગ

આ વિભાગમાં, હું વર્ણન કરીશ કે ક્લસ્ટરનું સંચાલન કરવા માટે TLS (થ્રેડ લોકલ સ્ટોરેજ) નો ઉપયોગ કેવી રીતે થાય છે. ક્લસ્ટર મેનેજમેન્ટમાં xDS API અને/અથવા DNS પ્રોસેસિંગ તેમજ આરોગ્ય તપાસનો સમાવેશ થાય છે.


ક્લસ્ટર ફ્લો મેનેજમેન્ટમાં નીચેના ઘટકો અને પગલાં શામેલ છે:

1. ક્લસ્ટર મેનેજર એ એન્વોયની અંદર એક ઘટક છે જે તમામ જાણીતા ક્લસ્ટર અપસ્ટ્રીમ્સ, ક્લસ્ટર ડિસ્કવરી સર્વિસ (CDS) API, સિક્રેટ ડિસ્કવરી સર્વિસ (SDS) અને એન્ડપોઇન્ટ ડિસ્કવરી સર્વિસ (EDS) API, DNS અને સક્રિય બાહ્ય તપાસનું સંચાલન કરે છે. તે દરેક અપસ્ટ્રીમ ક્લસ્ટરનું "આખરે સુસંગત" દૃશ્ય બનાવવા માટે જવાબદાર છે, જેમાં શોધાયેલ યજમાનો તેમજ આરોગ્ય સ્થિતિનો સમાવેશ થાય છે.
2. આરોગ્ય તપાસનાર સક્રિય આરોગ્ય તપાસ કરે છે અને ક્લસ્ટર મેનેજરને આરોગ્યની સ્થિતિના ફેરફારોની જાણ કરે છે.
3. CDS (ક્લસ્ટર ડિસ્કવરી સર્વિસ) / SDS (સિક્રેટ ડિસ્કવરી સર્વિસ) / EDS (એન્ડપોઇન્ટ ડિસ્કવરી સર્વિસ) / DNS ક્લસ્ટર સભ્યપદ નક્કી કરવા માટે કરવામાં આવે છે. રાજ્ય ફેરફાર ક્લસ્ટર મેનેજરને પરત કરવામાં આવે છે.
4. દરેક વર્કર થ્રેડ સતત ઇવેન્ટ લૂપ ચલાવે છે.
5. જ્યારે ક્લસ્ટર મેનેજર નિર્ધારિત કરે છે કે ક્લસ્ટર માટેની સ્થિતિ બદલાઈ ગઈ છે, ત્યારે તે ક્લસ્ટરની સ્થિતિનો એક નવો ફક્ત વાંચવા માટેનો સ્નેપશોટ બનાવે છે અને તેને દરેક વર્કર થ્રેડને મોકલે છે.
6. આગામી શાંત સમયગાળા દરમિયાન, વર્કર થ્રેડ ફાળવેલ TLS સ્લોટમાં સ્નેપશોટ અપડેટ કરશે.
7. I/O ઇવેન્ટ દરમિયાન જે બેલેન્સ લોડ કરવા માટે હોસ્ટને નિર્ધારિત કરવાનું માનવામાં આવે છે, લોડ બેલેન્સર હોસ્ટ વિશે માહિતી મેળવવા માટે TLS (થ્રેડ લોકલ સ્ટોરેજ) સ્લોટની વિનંતી કરશે. આને તાળાઓની જરૂર નથી. એ પણ નોંધ કરો કે TLS અપડેટ ઇવેન્ટ્સને પણ ટ્રિગર કરી શકે છે જેથી કરીને લોડ બેલેન્સર્સ અને અન્ય ઘટકો કેશ, ડેટા સ્ટ્રક્ચર વગેરેની પુનઃ ગણતરી કરી શકે. આ આ પોસ્ટના અવકાશની બહાર છે, પરંતુ કોડમાં વિવિધ સ્થળોએ તેનો ઉપયોગ થાય છે.

ઉપરોક્ત પ્રક્રિયાનો ઉપયોગ કરીને, રાજદૂત કોઈપણ અવરોધ વિના દરેક વિનંતી પર પ્રક્રિયા કરી શકે છે (અગાઉ વર્ણવ્યા મુજબ સિવાય). TLS કોડની જટિલતા સિવાય, મોટાભાગના કોડને મલ્ટિથ્રેડિંગ કેવી રીતે કાર્ય કરે છે અને સિંગલ-થ્રેડેડ લખી શકાય તે સમજવાની જરૂર નથી. આ બહેતર પ્રદર્શન ઉપરાંત મોટાભાગના કોડને લખવાનું સરળ બનાવે છે.

અન્ય સબસિસ્ટમ જે TLS નો ઉપયોગ કરે છે

TLS (થ્રેડ લોકલ સ્ટોરેજ) અને RCU (રીડ કોપી અપડેટ) નો ઉપયોગ એન્વોયમાં વ્યાપકપણે થાય છે.

ઉપયોગના ઉદાહરણો:

• અમલ દરમિયાન કાર્યક્ષમતા બદલવા માટેની પદ્ધતિ: સક્ષમ કાર્યક્ષમતાની વર્તમાન સૂચિ મુખ્ય થ્રેડમાં ગણવામાં આવે છે. પછી દરેક વર્કર થ્રેડને RCU સિમેન્ટિક્સનો ઉપયોગ કરીને ફક્ત વાંચવા માટેનો સ્નેપશોટ આપવામાં આવે છે.
• રૂટ કોષ્ટકો બદલી રહ્યા છીએ: RDS (રૂટ ડિસ્કવરી સર્વિસ) દ્વારા પ્રદાન કરાયેલ રૂટ કોષ્ટકો માટે, મુખ્ય થ્રેડ પર રૂટ કોષ્ટકો બનાવવામાં આવે છે. આરસીયુ (રીડ કોપી અપડેટ) સિમેન્ટિક્સનો ઉપયોગ કરીને દરેક વર્કર થ્રેડને પછીથી ફક્ત વાંચવા માટેનો સ્નેપશોટ પૂરો પાડવામાં આવશે. આ બદલાતા રૂટ કોષ્ટકોને પરમાણુ કાર્યક્ષમ બનાવે છે.
• HTTP હેડર કેશીંગ: તે બહાર આવ્યું તેમ, દરેક વિનંતી માટે HTTP હેડરની ગણતરી કરવી (જ્યારે ~25K+ RPS પ્રતિ કોર ચાલી રહી હોય) ખૂબ ખર્ચાળ છે. દૂત કેન્દ્રીય રીતે લગભગ દર અડધા સેકન્ડે હેડરની ગણતરી કરે છે અને TLS અને RCU દ્વારા દરેક કાર્યકરને તે પ્રદાન કરે છે.

અન્ય કિસ્સાઓ છે, પરંતુ અગાઉના ઉદાહરણોએ TLS નો ઉપયોગ શા માટે થાય છે તેની સારી સમજ આપવી જોઈએ.

જાણીતા પ્રદર્શન મુશ્કેલીઓ

જ્યારે રાજદૂત એકંદરે ખૂબ સારું પ્રદર્શન કરે છે, ત્યારે કેટલાક નોંધપાત્ર ક્ષેત્રો છે કે જેને ધ્યાન આપવાની જરૂર છે જ્યારે તેનો ઉપયોગ ખૂબ જ ઉચ્ચ સંમતિ અને થ્રુપુટ સાથે થાય છે:

• આ લેખમાં વર્ણવ્યા મુજબ, હાલમાં એક્સેસ લોગ મેમરી બફર પર લખતી વખતે તમામ વર્કર થ્રેડો લોક મેળવે છે. ઉચ્ચ સંમતિ અને ઉચ્ચ થ્રુપુટ પર, તમારે અંતિમ ફાઇલ પર લખતી વખતે આઉટ-ઓફ-ઓર્ડર ડિલિવરીના ખર્ચે દરેક વર્કર થ્રેડ માટે એક્સેસ લોગને બેચ કરવાની જરૂર પડશે. વૈકલ્પિક રીતે, તમે દરેક વર્કર થ્રેડ માટે અલગ એક્સેસ લોગ બનાવી શકો છો.
• જોકે આંકડાઓ ખૂબ જ ઑપ્ટિમાઇઝ કરવામાં આવ્યા છે, ખૂબ જ ઉચ્ચ સંમતિ અને થ્રુપુટ પર વ્યક્તિગત આંકડાઓ પર અણુ વિવાદ થવાની સંભાવના છે. આ સમસ્યાનો ઉકેલ કેન્દ્રીય કાઉન્ટર્સના સામયિક રીસેટ સાથે કામદાર થ્રેડ દીઠ કાઉન્ટર્સ છે. આની પછીની પોસ્ટમાં ચર્ચા કરવામાં આવશે.
• વર્તમાન આર્કિટેક્ચર સારી રીતે કામ કરશે નહીં જો રાજદૂતને એવા સંજોગોમાં તૈનાત કરવામાં આવે કે જ્યાં નોંધપાત્ર પ્રક્રિયા સંસાધનોની જરૂર હોય તેવા બહુ ઓછા જોડાણો છે. ત્યાં કોઈ ગેરેંટી નથી કે કનેક્શન્સ વર્કર થ્રેડો વચ્ચે સમાનરૂપે વિતરિત કરવામાં આવશે. વર્કર કનેક્શન બેલેન્સિંગના અમલીકરણ દ્વારા આને ઉકેલી શકાય છે, જે વર્કર થ્રેડો વચ્ચેના જોડાણોના વિનિમયને મંજૂરી આપશે.

નિષ્કર્ષ

દૂતનું થ્રેડીંગ મોડલ યોગ્ય રીતે ગોઠવેલ ન હોય તો સંભવિત વ્યર્થ મેમરી અને જોડાણોના ભોગે પ્રોગ્રામિંગની સરળતા અને મોટા પાયે સમાનતા પ્રદાન કરવા માટે રચાયેલ છે. આ મોડેલ તેને ખૂબ જ ઉચ્ચ થ્રેડ કાઉન્ટ્સ અને થ્રુપુટ પર ખૂબ જ સારી રીતે પ્રદર્શન કરવાની મંજૂરી આપે છે.
જેમ મેં Twitter પર સંક્ષિપ્તમાં ઉલ્લેખ કર્યો છે તેમ, ડિઝાઇન DPDK (ડેટા પ્લેન ડેવલપમેન્ટ કિટ) જેવા સંપૂર્ણ વપરાશકર્તા-મોડ નેટવર્કિંગ સ્ટેકની ટોચ પર પણ ચાલી શકે છે, જેના પરિણામે પરંપરાગત સર્વર્સ સંપૂર્ણ L7 પ્રક્રિયા સાથે પ્રતિ સેકન્ડ લાખો વિનંતીઓનું સંચાલન કરી શકે છે. આગામી થોડા વર્ષોમાં શું બને છે તે જોવું ખૂબ જ રસપ્રદ રહેશે.
એક છેલ્લી ઝડપી ટિપ્પણી: મને ઘણી વખત પૂછવામાં આવ્યું છે કે શા માટે અમે દૂત માટે C++ પસંદ કર્યું. કારણ એ છે કે તે હજી પણ વ્યાપકપણે ઉપયોગમાં લેવાતી એકમાત્ર ઔદ્યોગિક ગ્રેડ ભાષા છે જેમાં આ પોસ્ટમાં વર્ણવેલ આર્કિટેક્ચરનું નિર્માણ કરી શકાય છે. C++ ચોક્કસપણે બધા અથવા તો ઘણા પ્રોજેક્ટ્સ માટે યોગ્ય નથી, પરંતુ અમુક ચોક્કસ ઉપયોગના કિસ્સાઓ માટે તે હજુ પણ કામ પૂર્ણ કરવા માટેનું એકમાત્ર સાધન છે.

કોડની લિંક્સ

આ પોસ્ટમાં ચર્ચા કરેલ ઇન્ટરફેસ અને હેડર અમલીકરણ સાથેની ફાઇલોની લિંક્સ:

• github.com/lyft/envoy/blob/master/include/envoy/thread_local/thread_local.h
• github.com/lyft/envoy/blob/master/source/common/thread_local/thread_local_impl.h
• github.com/lyft/envoy/blob/master/include/envoy/upstream/cluster_manager.h
• github.com/lyft/envoy/blob/master/source/common/upstream/cluster_manager_impl.h

સોર્સ: www.habr.com