Bioyino - බෙදා හරින ලද, පරිමාණය කළ හැකි ප්‍රමිතික එකතු කරන්නා

එබැවින් ඔබ මිනුම් එකතු කරන්න. අපි ඉන්න විදියට. අපි මිනුම් ද එකතු කරමු. ඇත්ත වශයෙන්ම, ව්යාපාර සඳහා අවශ්ය වේ. අද අපි අපගේ අධීක්ෂණ පද්ධතියේ පළමු සබැඳිය ගැන කතා කරමු - statsd-අනුකූල එකතු කිරීමේ සේවාදායකයක් bioyino, ඇයි අපි එය ලිව්වේ සහ ඇයි අපි බෲබෙක් අතහැරියේ.

අපගේ පෙර ලිපි වලින් (1, 2) යම් කාලයක් වන තුරු අපි භාවිතා කරමින් ලකුණු එකතු කළ බව ඔබට දැනගත හැකිය බෲබෙක්. එය C වලින් ලියා ඇත. කේත දෘෂ්ටි කෝණයකින්, එය ප්ලග් එකක් තරම් සරලයි (ඔබට දායක වීමට අවශ්‍ය විට මෙය වැදගත් වේ) සහ, වඩාත්ම වැදගත් දෙය නම්, එය අපගේ තත්පරයට මෙට්‍රික් මිලියන 2 (MPS) උපරිම මට්ටමේදී හසුරුවයි. කිසිදු ගැටළුවක් නොමැතිව. ලේඛනවල තරු ලකුණක් සහිත MPS මිලියන 4ක් සඳහා සහය දක්වයි. මෙයින් අදහස් කරන්නේ ඔබ ලිනක්ස් හි ජාලය නිවැරදිව වින්‍යාස කළහොත් ඔබට ප්‍රකාශිත රූපය ලැබෙනු ඇති බවයි. (ඔබ ජාලයෙන් ඉවත්ව ගියහොත් ඔබට MPS කීයක් ලබා ගත හැකිදැයි අපි නොදනිමු). මෙම වාසි තිබියදීත්, අපට බෲබෙක් ගැන බරපතල පැමිණිලි කිහිපයක් තිබුණි.

හිමිකම් 1. ව්‍යාපෘතියේ සංවර්ධකයා වන ගිතුබ් එයට සහාය දීම නැවැත්වීය: පැච් සහ නිවැරදි කිරීම් ප්‍රකාශ කිරීම, අපගේ සහ (අපගේ පමණක් නොව) PR පිළිගැනීම. පසුගිය මාස කිහිපය තුළ (2018 පෙබරවාරි-මාර්තු සිට කොහේ හරි), ක්‍රියාකාරකම් නැවත ආරම්භ වී ඇත, නමුත් ඊට පෙර වසර 2 කට ආසන්න කාලයක් සම්පූර්ණ සන්සුන් භාවයක් පැවතුනි. මීට අමතරව, ව්යාපෘතිය සංවර්ධනය වෙමින් පවතී අභ්යන්තර Ghub අවශ්යතා සඳහා, නව විශේෂාංග හඳුන්වාදීම සඳහා බරපතල බාධාවක් විය හැකිය.

හිමිකම් 2. ගණනය කිරීම් වල නිරවද්‍යතාවය. Brubeck එකතු කිරීම සඳහා 65536 අගයන් එකතු කරයි. අපගේ නඩුවේදී, සමහර ප්‍රමිතික සඳහා, එකතු කිරීමේ කාල සීමාව තුළ (තත්පර 30), තවත් බොහෝ අගයන් පැමිණිය හැකිය (උච්චයේ දී 1). මෙම නියැදීමේ ප්රතිඵලයක් වශයෙන්, උපරිම සහ අවම අගයන් නිෂ්ඵල බව පෙනේ. උදාහරණයක් ලෙස, මේ වගේ:

එය සිදුවූ ලෙසින් ම

එය කෙසේ විය යුතුව තිබුණි

එකම හේතුව නිසා, මුදල් සාමාන්යයෙන් වැරදි ලෙස ගණනය කරනු ලැබේ. 32-බිට් පාවෙන පිටාර ගැලීමක් සහිත දෝෂයක් මෙහි එක් කරන්න, එය සාමාන්‍යයෙන් අහිංසක ලෙස පෙනෙන මෙට්‍රික් එකක් ලැබෙන විට සේවාදායකය segfault වෙත යවන අතර සියල්ල විශිෂ්ට වේ. දෝෂය, මාර්ගය වන විට, නිවැරදි කර නැත.

අවසානයේ X හිමිකම් කියන්න. ලියන අවස්ථාව වන විට, අපට සොයා ගැනීමට හැකි වූ වැඩි හෝ අඩුවෙන් ක්‍රියාත්මක වන statsd ක්‍රියාත්මක කිරීම් 14ටම එය ඉදිරිපත් කිරීමට අපි සූදානම්. අපි හිතමු සමහර තනි යටිතල පහසුකම් මිලියන 4ක් MPS පිළිගැනීම තවදුරටත් ප්‍රමාණවත් නොවන තරමට වර්ධනය වෙලා කියලා. නැතහොත් එය තවම වර්ධනය වී නොමැති වුවද, ප්‍රමිතික ඔබට දැනටමත් කොතරම් වැදගත්ද යත්, ප්‍රස්ථාරවල කෙටි, මිනිත්තු 2-3 ක ගිල්වීම් පවා දැනටමත් විවේචනාත්මක වී කළමනාකරුවන් අතර දරාගත නොහැකි මානසික අවපීඩනයට හේතු විය හැක. මානසික අවපීඩනයට ප්රතිකාර කිරීම ස්තුතිවන්ත නොවන කාර්යයක් වන බැවින්, තාක්ෂණික විසඳුම් අවශ්ය වේ.

පළමුව, දෝෂ ඉවසීම, එවිට සේවාදායකයේ හදිසි ගැටළුවක් කාර්යාලයේ මනෝචිකිත්සක සොම්බි එළිදරව්වක් ඇති නොකරයි. දෙවනුව, ලිනක්ස් ජාල තොගය ගැඹුරට හාරා නොගෙන, අවශ්‍ය ප්‍රමාණයට “පළල” ලෙස සන්සුන්ව වර්ධනය නොවී, මිලියන 4 කට වඩා MPS පිළිගැනීමට හැකි වන පරිදි පරිමාණය කිරීම.

අපට පරිමාණය සඳහා ඉඩක් තිබූ බැවින්, අපි වැරදි ඉවසීමෙන් ආරම්භ කිරීමට තීරණය කළෙමු. "ගැන! වැරදි ඉවසීම! එය සරලයි, අපට එය කළ හැකිය, ”අපි කල්පනා කර සේවාදායකයන් 2 ක් දියත් කළ අතර, ඒ සෑම එකක් මතම බෲබෙක් පිටපතක් ඉහළ නංවන්නෙමු. මෙය සිදු කිරීම සඳහා, අපට ප්‍රමිතික සමඟ ගමනාගමනය සේවාදායකයන් දෙකටම පිටපත් කිරීමට සහ මේ සඳහා ලිවීමට පවා සිදු විය කුඩා උපයෝගීතාව. අපි මේ සමඟ වැරදි ඉවසීමේ ගැටලුව විසඳා ගත්තෙමු, නමුත් ... ඉතා හොඳින් නොවේ. මුලදී සෑම දෙයක්ම විශිෂ්ට ලෙස පෙනුනි: සෑම බෲබෙක් එකක්ම තමන්ගේම එකතු කිරීමේ අනුවාදයක් එකතු කරයි, සෑම තත්පර 30 කට වරක්ම ග්‍රැෆයිට් වෙත දත්ත ලියයි, පැරණි පරතරය නැවත ලියයි (මෙය ග්‍රැෆයිට් පැත්තෙන් සිදු කෙරේ). එක් සේවාදායකයක් හදිසියේ අසමත් වුවහොත්, අපට සෑම විටම දෙවන එක එහි එකතු කළ දත්තවල පිටපතක් ඇත. නමුත් මෙන්න ගැටළුව: සේවාදායකය අසමත් වුවහොත්, ප්රස්ථාරවල "saw" දිස්වේ. මෙයට හේතුව බෲබෙක්ගේ තත්පර 30 ක කාල පරතරයන් සමමුහුර්ත කර නොමැති අතර, බිඳවැටීමේ මොහොතේදී ඒවායින් එකක් උඩින් ලියා නොතිබීමයි. දෙවන සේවාදායකය ආරම්භ වන විට, එකම දේ සිදු වේ. තරමක් ඉවසිය හැකි, නමුත් මට වඩා හොඳ අවශ්යයි! පරිමාණය පිළිබඳ ගැටළුව ද පහව ගොස් නැත. සියලුම ප්‍රමිතික තවමත් තනි සේවාදායකයකට “පියාසර කරයි”, එබැවින් අපි ජාල මට්ටම මත පදනම්ව එම MPS මිලියන 2-4 කට සීමා වේ.

ඔබ ගැටලුව ගැන මඳක් සිතන්නේ නම් සහ ඒ සමඟම සවලකින් හිම හාරා ඇත්නම්, පහත පැහැදිලි අදහස මතකයට නැඟිය හැකිය: ඔබට බෙදා හරින ලද මාදිලියේ වැඩ කළ හැකි statsd එකක් අවශ්‍ය වේ. එනම්, කාලය සහ මෙට්‍රික් වල නෝඩ් අතර සමමුහුර්තකරණය ක්‍රියාත්මක කරන එකකි. “ඇත්ත වශයෙන්ම, එවැනි විසඳුමක් දැනටමත් පවතිනවා,” අපි කියමින් ගූගල් වෙත ගියෙමු. තවද ඔවුන් කිසිවක් සොයා ගත්තේ නැත. විවිධ statsd සඳහා ලියකියවිලි හරහා ගිය පසු (https://github.com/etsy/statsd/wiki#server-implementations 11.12.2017 දෙසැම්බර් XNUMX වන විට), අපි කිසිවක් සොයා ගත්තේ නැත. පෙනෙන විදිහට, සංවර්ධකයින් හෝ මෙම විසඳුම් භාවිතා කරන්නන් තවමත් බොහෝ ප්‍රමිතික හමු වී නැත, එසේ නොමැතිනම් ඔවුන් අනිවාර්යයෙන්ම යමක් ඉදිරිපත් කරනු ඇත.

ඊට පස්සේ අපි "සෙල්ලම් බඩු" statsd - bioyino ගැන සිහිපත් කළෙමු, එය Just for Fun hackathon හි ලියා ඇත (ව්‍යාපෘතියේ නම හැකතන් ආරම්භ වීමට පෙර පිටපත මගින් ජනනය කරන ලදී) සහ අපට ඉක්මනින් අපගේම සංඛ්‍යාලේඛන අවශ්‍ය බව අවබෝධ විය. කුමක් සඳහා ද?

• ලෝකයේ statsd ක්ලෝන අඩු නිසා,
• මක්නිසාද යත්, අපේක්ෂිත හෝ අපේක්ෂිත දෝෂ ඉවසීම සහ පරිමාණය (සේවාදායකයන් අතර සමමුහුර්ත ප්‍රමිතික සමමුහුර්ත කිරීම සහ ගැටුම් යැවීමේ ගැටළුව විසඳීම ඇතුළුව) ලබා දීමට හැකි වන බැවිනි.
• බෲබෙක්ට වඩා නිවැරදිව ප්‍රමිතික ගණනය කළ හැකි නිසා,
• බෘබෙක් ප්‍රායෝගිකව අපට ලබා නොදුන් වඩාත් සවිස්තරාත්මක සංඛ්‍යාලේඛන ඔබටම එකතු කර ගත හැකි නිසා,
• මක්නිසාද යත්, මගේම අධි ක්‍රියාකාරීත්වය බෙදා හරින ලද පරිමාණ විද්‍යාගාර යෙදුමක් ක්‍රමලේඛනය කිරීමට මට අවස්ථාවක් ලැබුණු නිසා, එය තවත් සමාන හයිපර්ෆෝර් හි ගෘහ නිර්මාණ ශිල්පය සම්පූර්ණයෙන්ම පුනරුච්චාරණය නොකරනු ඇත ... හොඳයි, එයයි.

කුමක් මත ලිවිය යුතුද? ඇත්ත වශයෙන්ම, රස්ට් තුළ. ඇයි?

• මූලාකෘති විසඳුමක් දැනටමත් තිබූ නිසා,
• මක්නිසාද යත් ලිපියේ කතුවරයා ඒ වන විටත් රස්ට් දැන සිටි අතර එය විවෘත මූලාශ්‍රයේ තැබීමට අවස්ථාව ඇතිව නිෂ්පාදනය සඳහා යමක් ලිවීමට උනන්දු වූ බැවිනි.
• මක්නිසාද යත්, ලැබෙන ගමනාගමනයේ ස්වභාවය (තාත්වික පාහේ) සහ GC විරාමයන් ප්‍රායෝගිකව පිළිගත නොහැකි නිසා GC සහිත භාෂා අපට නොගැලපේ,
• ඔබට C හා සැසඳිය හැකි උපරිම කාර්ය සාධනය අවශ්‍ය වන බැවිනි
• මක්නිසාද යත්, රස්ට් අපට නිර්භීත එකඟතාවයක් ලබා දෙන අතර, අපි එය C/C++ වලින් ලිවීමට පටන් ගත්තේ නම්, අපි බෲබෙක්ට වඩා වැඩි අවදානම්, බෆර පිටාර ගැලීම්, ධාවන තත්වයන් සහ වෙනත් බියජනක වචන වලට ගොදුරු වනු ඇත.

රස්ට්ට එරෙහිව තර්කයක් ද විය. සමාගමට රස්ට් හි ව්‍යාපෘති නිර්මාණය කිරීමේ අත්දැකීමක් නොතිබූ අතර දැන් අපි එය ප්‍රධාන ව්‍යාපෘතියේ භාවිතා කිරීමට සැලසුම් නොකරමු. එමනිසා, කිසිවක් සාර්ථක නොවනු ඇතැයි බරපතල බියක් ඇති වූ නමුත් අපි අවස්ථාවක් ගැනීමට තීරණය කර උත්සාහ කළෙමු.

කාලය ගෙවිලා ගියා...

අවසාන වශයෙන්, අසාර්ථක උත්සාහයන් කිහිපයකින් පසුව, පළමු වැඩ කරන අනුවාදය සූදානම් විය. සිදුවුයේ කුමක් ද? සිදු වූයේ මෙයයි.

සෑම නෝඩයකටම තමන්ගේම ප්‍රමිතික කට්ටලයක් ලැබෙන අතර ඒවා සමුච්චය කරයි, අවසාන එකතු කිරීම සඳහා ඒවායේ සම්පූර්ණ කට්ටලය අවශ්‍ය වන එම වර්ග සඳහා ප්‍රමිතික එකතු නොකරයි. යම් ආකාරයක බෙදා හරින ලද අගුළු ප්‍රොටෝකෝලය මගින් නෝඩ් එකිනෙක සම්බන්ධ කර ඇති අතර, එමඟින් ශ්‍රේෂ්ඨ එකට ප්‍රමිතික යැවීමට සුදුසු එකම එක (මෙහි අපි කෑගැසුවෙමු) තෝරා ගැනීමට ඔබට ඉඩ සලසයි. විසින් මෙම ගැටළුව දැනට විසඳා ඇත කොන්සල්, නමුත් අනාගතයේ දී කතුවරයාගේ අභිලාෂයන් දක්වා විහිදේ තමන්ගේ ක්රියාත්මක කිරීම Raft, එහිදී වඩාත් සුදුසු තැනැත්තා, ඇත්ත වශයෙන්ම, සම්මුති නායක නෝඩය වනු ඇත. සම්මුතියට අමතරව, නෝඩ් බොහෝ විට (පෙරනිමියෙන් තත්පරයකට වරක්) ඔවුන්ගේ අසල්වැසියන් වෙත එම තත්පරයේදී රැස් කිරීමට සමත් වූ පූර්ව-එකතු කළ ප්‍රමිතික කොටස් යවයි. පරිමාණය සහ දෝෂ ඉවසීම සංරක්ෂණය කර ඇති බව පෙනේ - සෑම නෝඩයක්ම තවමත් සම්පූර්ණ ප්‍රමිතික කට්ටලයක් දරයි, නමුත් ප්‍රමිතික දැනටමත් එකතු කර, TCP හරහා යවා ද්විමය ප්‍රොටෝකෝලයකට කේතනය කර ඇත, එබැවින් UDP හා සසඳන විට අනුපිටපත් පිරිවැය සැලකිය යුතු ලෙස අඩු වේ. ලැබෙන ප්‍රමිතික තරමක් විශාල සංඛ්‍යාවක් තිබියදීත්, සමුච්චය සඳහා ඉතා කුඩා මතකයක් සහ ඊටත් වඩා අඩු CPU අවශ්‍ය වේ. අපගේ අතිශයින් සංකෝචනය කළ හැකි mertics සඳහා, මෙය මෙගාබයිට් දස දහස් ගණනක් දත්ත පමණි. අමතර ප්‍රසාද දීමනාවක් ලෙස, බර්බෙක් සමඟ සිදු වූවාක් මෙන්, ග්‍රැෆයිට් තුළ අනවශ්‍ය දත්ත නැවත ලිවීම් අපට නොලැබේ.

ප්‍රමිතික සහිත UDP පැකට් සරල රවුන්ඩ් රොබින් හරහා ජාල උපකරණවල නෝඩ් අතර අසමතුලිත වේ. ඇත්ත වශයෙන්ම, ජාල දෘඩාංග පැකට් වල අන්තර්ගතය විග්‍රහ නොකරන අතර එම නිසා තත්පරයට 4M පැකට් වලට වඩා බොහෝ සෙයින් ඇද ගත හැකිය, එය කිසිවක් නොදන්නා ප්‍රමිතික ගැන සඳහන් නොකරන්න. එක් එක් පැකට්ටුවේ ප්‍රමිතික එකින් එක නොපැමිණෙන බව අපි සැලකිල්ලට ගන්නේ නම්, මෙම ස්ථානයේ කාර්ය සාධන ගැටළු කිසිවක් අපි අපේක්ෂා නොකරමු. සේවාදායකයක් බිඳ වැටුණහොත්, ජාල උපාංගය ඉක්මනින් (තත්පර 1-2 ක් ඇතුළත) මෙම කරුණ හඳුනාගෙන බිඳවැටුණු සේවාදායකය භ්‍රමණයෙන් ඉවත් කරයි. මෙහි ප්‍රතිඵලයක් ලෙස, ප්‍රස්ථාරවල අඩුවීම් නොදැන ප්‍රායෝගිකව උදාසීන (එනම් නායක නොවන) නෝඩ් සක්‍රිය සහ අක්‍රිය කළ හැක. අපිට නැතිවෙන උපරිමය අන්තිම තත්පරේ ආපු මෙට්‍රික් වලින් කොටසක්. නායකයෙකුගේ හදිසි අලාභයක් / වසා දැමීමක් / ස්විචයක් තවමත් සුළු විෂමතාවයක් ඇති කරයි (තත්පර 30 ක පරතරය තවමත් සමමුහුර්ත නොවේ), නමුත් නෝඩ් අතර සන්නිවේදනයක් තිබේ නම්, මෙම ගැටළු අවම කර ගත හැකිය, උදාහරණයක් ලෙස, සමමුහුර්ත පැකට් යැවීමෙන් .

අභ්යන්තර ව්යුහය ගැන ටිකක්. යෙදුම, ඇත්ත වශයෙන්ම, බහු නූල්, නමුත් නූල් නිර්මාණ ශිල්පය බෲබෙක්හි භාවිතා කරන ආකාරයට වඩා වෙනස් වේ. බෲබෙක්හි නූල් සමාන වේ - ඒ සෑම එකක්ම තොරතුරු රැස් කිරීම සහ එකතු කිරීම යන දෙකටම වගකිව යුතුය. bioyino හි, කම්කරුවන් කණ්ඩායම් දෙකකට බෙදා ඇත: ජාලයට වගකිව යුතු අය සහ එකතු කිරීම සඳහා වගකිව යුතු අය. ප්‍රමිතික වර්ගය අනුව යෙදුම වඩාත් නම්‍යශීලීව කළමනාකරණය කිරීමට මෙම අංශය ඔබට ඉඩ සලසයි: තීව්‍ර එකතු කිරීමක් අවශ්‍ය විට, ඔබට එකතු කරන්නන් එකතු කළ හැකිය, ජාල තදබදය විශාල ප්‍රමාණයක් ඇති විට, ඔබට ජාල ප්‍රවාහ ගණන එකතු කළ හැකිය. මේ මොහොතේ, අපගේ සේවාදායකයන් මත අපි ජාල 8 ක් තුළ වැඩ කරන අතර එකතු කිරීම් 4 ක් ගලා යයි.

ගණන් කිරීමේ (එකතු කිරීම සඳහා වගකිව යුතු) කොටස තරමක් කම්මැලි ය. ජාල ප්‍රවාහ මගින් පුරවන ලද බෆර් ගණන් කිරීමේ ප්‍රවාහයන් අතර බෙදා හරිනු ලැබේ, එහිදී ඒවා පසුව විග්‍රහ කර එකතු කරනු ලැබේ. ඉල්ලීම මත, වෙනත් නෝඩ් වෙත යැවීම සඳහා මිනුම් ලබා දෙනු ලැබේ. නෝඩ් අතර දත්ත යැවීම සහ කොන්සල් සමඟ වැඩ කිරීම ඇතුළුව මේ සියල්ල රාමුව මත ක්‍රියාත්මක වන අසමමුහුර්තව සිදු කෙරේ. ටෝකියෝව.

ප්‍රමිතික ලබා ගැනීම සඳහා වගකිව යුතු ජාල කොටස නිසා සංවර්ධනයේදී තවත් බොහෝ ගැටලු ඇති විය. ජාල ප්‍රවාහයන් වෙනම ආයතනවලට වෙන් කිරීමේ ප්‍රධාන අරමුණ වූයේ ප්‍රවාහයක් ගත කරන කාලය අඩු කිරීමට ඇති ආශාවයි නෑ සොකට් එකෙන් දත්ත කියවීමට. අසමමුහුර්ත UDP සහ සාමාන්‍ය recvmsg භාවිතා කරන විකල්ප ඉක්මනින් අතුරුදහන් විය: පළමුවැන්න සිදුවීම් සැකසීම සඳහා පරිශීලක-අවකාශ CPU අධික ලෙස පරිභෝජනය කරයි, දෙවැන්නට බොහෝ සන්දර්භ ස්විචයන් අවශ්‍ය වේ. එබැවින් එය දැන් භාවිතා වේ recvmmsg විශාල බෆර සමඟ (සහ බෆර, මහත්වරුනි නිලධාරීන්, ඔබට කිසිවක් නොවේ!). recvmmsg අවශ්‍ය නොවන සැහැල්ලු අවස්ථා සඳහා සාමාන්‍ය UDP සඳහා සහය වෙන් කර ඇත. බහු පණිවිඩ ප්‍රකාරයේදී, ප්‍රධාන දෙය සාක්ෂාත් කර ගත හැකිය: බොහෝ විට, ජාල නූල් OS පෝලිම අවුස්සයි - සොකට් එකෙන් දත්ත කියවා එය පරිශීලක අවකාශයේ බෆරයට මාරු කරයි, ඉඳහිට පමණක් පිරවූ බෆරය ලබා දීමට මාරු වේ. එකතුකරන්නන්. සොකට් එකේ පෝලිම ප්‍රායෝගිකව එකතු නොවේ, අතහැර දැමූ පැකට් ගණන ප්‍රායෝගිකව වර්ධනය නොවේ.

අදහස් දැක්වීම්

පෙරනිමි සැකසුම් තුළ, බෆරයේ ප්‍රමාණය තරමක් විශාල ලෙස සකසා ඇත. ඔබ හදිසියේම සේවාදායකය ඔබම උත්සාහ කිරීමට තීරණය කරන්නේ නම්, ප්‍රමිතික කුඩා සංඛ්‍යාවක් යැවීමෙන් පසු ඒවා ග්‍රැෆයිට් වෙත නොපැමිණෙන අතර ජාල ප්‍රවාහ බෆරයේ ඉතිරිව ඇති බව ඔබට හමුවිය හැකිය. ප්‍රමිතික කුඩා සංඛ්‍යාවක් සමඟ වැඩ කිරීමට, ඔබ වින්‍යාසය තුළ කුඩා අගයන් වෙත bufsize සහ task-queue-size සැකසිය යුතුය.

අවසාන වශයෙන්, ප්‍රස්ථාර ලෝලීන් සඳහා ප්‍රස්ථාර කිහිපයක්.

එක් එක් සේවාදායකය සඳහා එන මෙට්‍රික් සංඛ්‍යාව පිළිබඳ සංඛ්‍යාලේඛන: MPS මිලියන 2 කට වඩා.

නෝඩ් වලින් එකක් අක්‍රිය කිරීම සහ එන ප්‍රමිතික නැවත බෙදා හැරීම.

පිටතට යන ප්‍රමිතික පිළිබඳ සංඛ්‍යාලේඛන: සෑම විටම යවන්නේ එක් නෝඩයක් පමණි - වැටලීම් ලොක්කා.

විවිධ පද්ධති මොඩියුලවල දෝෂ සැලකිල්ලට ගනිමින් එක් එක් නෝඩයේ ක්රියාකාරිත්වය පිළිබඳ සංඛ්යා ලේඛන.

එන ප්‍රමිතික පිළිබඳ විස්තර (මෙට්‍රික් නම් සඟවා ඇත).

මේ සියල්ල සමඟ අපි ඊළඟට කිරීමට සැලසුම් කරන්නේ කුමක්ද? හැබයි කෝඩ් එක ලියන්න අපොයි...! මෙම ව්‍යාපෘතිය මුලින් සැලසුම් කර තිබුණේ විවෘත මූලාශ්‍රයක් ලෙස වන අතර එය එහි ජීවිත කාලය පුරාවටම පවතිනු ඇත. අපගේ ක්ෂණික සැලසුම් අතරට අපගේම Raft අනුවාදයට මාරුවීම, සම වයසේ ප්‍රොටෝකෝලය වඩා එහා මෙහා ගෙන යා හැකි එකකට වෙනස් කිරීම, අතිරේක අභ්‍යන්තර සංඛ්‍යාලේඛන හඳුන්වාදීම, නව ප්‍රමිතික, දෝෂ නිවැරදි කිරීම් සහ වෙනත් වැඩිදියුණු කිරීම් ඇතුළත් වේ.

ඇත්ත වශයෙන්ම, ව්‍යාපෘතියේ සංවර්ධනයට උදව් කිරීමට සියලු දෙනා සාදරයෙන් පිළිගනිමු: PR, ගැටළු නිර්මාණය කරන්න, හැකි නම් අපි ප්‍රතිචාර දක්වන්නෙමු, වැඩිදියුණු කරන්නෙමු.

එහෙම කිව්වම, එච්චරයි කට්ටිය, අපේ අලි ටික ගන්න!

මූලාශ්රය: www.habr.com