Rust භාෂාවේ Tokio රන්ටයිම් එක, ඉතා උසස් සමුහ (concurrent) වැඩසටහන් සකස් කිරීමේ ප්රධාන මෙවලමක්. නමුත් එය කෙලින්ම වැඩ කරනවාද, වැඩේ කොපමණ වේගයෙන් කරගෙන යනවාද යන දෙක අතර වෙනසක් ඇත.
අපේ සේවාව Kafka, Redis Streams, NATS වැනි මැසේජ් කෙව් එකකින් සිදුවන සිදුවීම් (events) කියවා, ඒ සෑම සිදුවීමකටම Tokio ටාස්ක් එකක් පෙන්වා දෙන ආකාරයකි. එක් සිදුවීමකට උපරිම 1,000 පරිශීලක ටෝකන (user tokens) ඇති අතර, ඒ ටෝකනයක් සඳහා බාහිර API එකකට ඇමතුමක් කර, ප්රතිචාරය රැස් කර අවසානයේ සිදුවීමේ ප්රතිඵලයක් සාදයි.
කේතයේ සරල ආකාරය මෙසේය: සිදුවීමක් ලැබුනොත්, එය tokio::spawn මගින් නව async ටාස්ක් එකක් ලෙස ක්රියාත්මක කරයි. එම ටාස්ක් තුළ, සෑම ටෝකනයක් සඳහාම තවත් ටාස්ක් එකක් JoinSet මඟින් සකස් කර, ඒවායේ API ඇමතුම් කරයි. සියලු ප්රතිචාර රැස් කර generate_response_event මගින් අවසාන සිදුවීම නිර්මාණය කරයි.
මෙම සැලැස්මෙන් අපේ ප්රධාන අරමුණ throughput වැඩි කිරීමයි. ටාස්ක් ගණන අසීමිත (unbounded) වුවත්, ඒවා සෙකන්ඩ් කිහිපයක් තුළ අවසන් වන බැවින්, පූර්ව ටාස්ක් පළමුව අවසන් වනු ඇතැයි අපි සිතූවා. නමුත් ලොග් ගොනු පරීක්ෂා කළ විට, පරණ සිදුවීම් වල ටාස්ක් ගණන බොහෝ විට පසුකාලීනව ඇරඹෙන බව දැක්කා.
මෙම අසම්මත වීම Tokio Scheduler එකේ ක්රියාකාරිත්වය හේතුවෙන් සිදු වුණා. බහු-තන්තුව (multi‑threaded) රන්ටයිම් එකේ සෑම වැඩකරු (worker) තන්තුවකටම 256 ටාස්ක් වල පෞද්ගලික කූටයක් (local queue) ඇත. එම කූටය පිරෙන විට, අඩක් කූටය ගෝලීය කූටයට (global queue) ගෙන යයි. වැඩකරු ප්රථමයෙන් තම පෞද්ගලික කූටයෙන් ටාස්ක් ගනී, අවශ්ය විට ගෝලීය කූටය පරීක්ෂා කර, අවශ්ය නම් වෙනත් වැඩකරුවන්ගෙන් (steal) ටාස්ක් ලබා ගනී. එවිට, පරණ සිදුවීම් වලින් උත්පාදනය වූ ටාස්ක් ගණනත්, නව සිදුවීම් වලින් උත්පාදනය වූ ටාස්ක් ගණනත් එකම ගෝලීය පෝලිමේ (queue) මිශ්රව පවතී. ඒ නිසා, පරණ ටාස්ක් ගණන පසුකාලීනව පෝලිමේ ඇතුළත් වීම සාමාන්යය.
ශ්රී ලංකාවට ඇති වැදගත්කම
- අධ්යයනඥයන් – Rust සහ Tokio වැනි නවතම async තාක්ෂණයන් ගැන දැන ගැනීම, විශ්ව විද්යාල පර්යේෂණ වලට ප්රයෝජනවත්.
- සංවර්ධකයින් – වැඩි throughput සහ memory efficiency සම්බන්ධයෙන් හොඳ අවබෝධයක් ගත හැකි, මෙය මයික්රොසර් ව්යාපාරික පද්ධතිවලට අයත්.
- ව්යාපාරිකයන් – ඉහළ concurrent load ගත කළ හැකි සේවාවන් නිර්මාණය කිරීමෙන්, ශ්රී ලංකාවේ fintech, e‑commerce වැනි ක්ෂේත්රවල තරඟශීලීත්වය වැඩිවේ.
අවසන් වශයෙන්, Tokio Scheduler එකේ “progress not ordering” මතකය, වැඩේ වේගවත් කරයි, නමුත් කාර්යයන්ගේ අනුපිළිවෙල ගැන අවධානයක් නොදෙයි. මෙය සැලකිල්ලෙන් භාවිතා කරන්නේ නම්, පද්ධති කාර්ය සාධනය වැඩි කර, මතක (memory) භාවිතය අඩු කළ හැක.
