කාල සීමා අඩුවී ගිය පසු කාර්ය මාලා පසුබැසීමේ අවදානම – දැන්ම පියවර ගන්න

ඔබේ සේවා පද්ධතියේ සම්පත් භාවිතය 60% ඉක්මවා ගිය පසු, සෞඛ්‍ය පරීක්ෂණ සියල්ල හරිත වුවත්, කාර්ය මාලා (queue) ඉක්මනින් එකතු වෙලා, අවසන් වේලාවට පසු ප්‍රතිඵල ලැබෙයි. මෙවැනි අවස්ථා වලදී "utilization" යනු සම්පත් පිරී සිටීම පමණක් පෙන්වයි; ඒකෙන් කාර්ය මාලාවේ වැඩ කාල සීමා තුළ අවසන් කළ හැකිදැයි තේරුම් ගත නොහැක.

මෙම ගැටළුව විසඳීමට, සෑම කාර්යයක් සඳහාම deadline_slack = deadline - now - estimated_service_time ලෙස ගණනය කරයි. Slack අගය අඩු (නැතහොත් අ négative) නම්, එම කාර්යය ආරම්භ කළ පසු කාල සීමාව අඩුවීමට ඉඩ ඇත, ඒ නිසා පළමු අදියරේම එය ප්‍රතික්ෂේප (reject) කිරීම හෝ අඩු ප්‍රමුඛතාවයට (degrade) පත් කිරීම වඩා හොඳයි.

කාර්ය මාලා නිරීක්ෂණයට අවශ්‍ය අවම ක්ෂේත්‍රයන්:

• job_id_hash: 9f2a
• class: interactive
• queued_at: 2026-07-23T09:12:00Z
• deadline_at: 2026-07-23T09:12:08Z
• estimated_service_ms: 1800
• queue_age_ms: 2400
• deadline_slack_ms: 3800

ප්‍රධාන මැනුම් පරාමිතීන් ලෙස queue age (class අනුව), admission Slack, service time, completion lateness, rejection count, retry count, worker saturation වැනි දත්ත රඳවා ගැනීම අත්‍යවශ්‍යයි.

ශ්‍රී ලංකාවට ඇති වැදගත්කම

ශ්‍රී ලංකාවේ තාක්ෂණික ආයතන, startup හා විශ්වවිද්‍යාල සිසුන්ට මෙම පද්ධති කළමනාකරණ සැලැස්මෙන් ලැබෙන ප්‍රයෝජන බහුලයි. පළමුව, කාර්ය මාලාවේ අධික බර නිසා සේවා නතර වීම වළක්වා, පාරිභෝගික තෘප්තිය වැඩි කරයි. දෙවනුව, "deadline slack" මත පදනම් වූ ප්‍රතික්ෂේප නීතිය, සම්පත් ඉතිරි කරමින්, ඉදිරිපත් කරන සේවා ගුණාත්මකභාවය තහවුරු කරයි. තෙවැනි වශයෙන්, පද්ධති මට්ටමේ මොනිතරය (metrics) නිරන්තරයෙන් සලකා බැලීමෙන්, ශ්‍රී ලංකාවේ cloud-native හා DevOps කණ්ඩායම්වලට ස්කේලබල්, විශ්වාසනීය ආකෘති නිර්මාණය කිරීමේ හැකියාව ලැබේ.

ඉතා සරල Python උදාහරණයක් මගින් "admit" නීතිය මෙසේ ලියයි:

def admit(job, now, service_p95_ms, safety_ms=250):
    remaining_ms = (job.deadline - now).total_seconds()*1000
    slack_ms = remaining_ms - service_p95_ms - safety_ms
    if slack_ms < 0:
        return "reject_deadline"
    if job.queue_age_ms > job.max_queue_age_ms:
        return "reject_stale"
    return "admit"

මෙම නීතිය, class අනුව පසුගිය සේවා කාල පර්සෙන්ටයිල් (p95) භාවිතා කරන බැවින්, බර වැඩ සහිත class එකකට අනුව වෙනස් කළ හැකිය. අධික පසුබැසීමක් හෝ අලුත් retry එකක් සීමා නොකළහොත්, පද්ධතියේ slack තවත් අඩු වෙයි.

අවසානයේ, ස්වයංක්‍රීය scaling ක්‍රියාවලිය queue depth මත පමණක් පදනම් කරන්නේ නම්, deadline‑slack‑negative අවස්ථා වැළැක්වීමට ප්‍රයෝජනවත් නොවේ. ඒ නිසා, ප්‍රතික්ෂේප නීතිය ක්‍රියාත්මක කර, telemetry එක පවත්වා, අවශ්‍ය විට rollback කිරීමේ හැකියාව සකස් කරගත යුතුය.

කෙටි සාරාංශය: සම්පත් භාවිතය 60%+ වුවත්, කාර්ය මාලාවේ slack අඩුවීම නිසා deadline‑miss වීමට ඉඩක් ඇත. එය අවලංගු කිරීමට, deadline‑slack‑based admission control හඳුන්වා දීම අත්‍යවශ්‍යයි.