Latency বনাম throughput: সিস্টেম ডিজাইনের দুই সংখ্যা
Latency আর throughput এক জিনিস নয়, একটি বাড়াতে গিয়ে অন্যটি খারাপ হতে পারে। p50, p95, p99 এবং average-এর ফাঁদ বুঝে নিন।
Latency হলো একটি request পাঠানো থেকে উত্তর আসা পর্যন্ত সময়। Throughput হলো নির্দিষ্ট সময়ে সিস্টেম কতগুলো request শেষ করে, যেমন প্রতি সেকেন্ডে কত request।
রাস্তার উদাহরণ ভাবুন: latency হলো একটি গাড়ি রাস্তাটা পার হতে কত সময় নেয়, throughput হলো মিনিটে কতগুলো গাড়ি পার হয়। লেন বাড়ালে throughput বাড়ে, কিন্তু একটি গাড়ি আগে পৌঁছায় না।
দুটো একে অপরের বিপরীতে টানে
Batching এর ভালো উদাহরণ। ১০০টি write একসাথে একটি database call-এ পাঠালে throughput বাড়ে, কিন্তু প্রথম write-কে বাকি ৯৯টির জন্য অপেক্ষা করতে হয়, তাই তার latency বাড়ে।
Average নয়, percentile দেখুন
Average কষ্ট লুকায়। ৯৯টি request ৫০ ms নিলে আর একটি ৫ সেকেন্ড নিলে average ঠিক দেখায়, অথচ প্রতি একশো জনে একজন বিরক্ত।
- p50 (median): অর্ধেক request এর চেয়ে দ্রুত।
- p95 / p99: ৫% বা ১% request এর চেয়ে ধীর।
User অভিজ্ঞতার জন্য p99 দেখুন। একে tail latency বলে। অনেকগুলো service ডাকলে এটি আরও গুরুত্বপূর্ণ, কারণ সবচেয়ে ধীর call-ই মোট সময় ঠিক করে।
কাজের একটি নিয়ম
Little's Law: একসাথে চলমান request = আসার হার x গড় সময়। প্রতি সেকেন্ডে ২০০ request আর প্রতিটি ০.৫ সেকেন্ড নিলে একসাথে প্রায় ১০০টি চলছে। এ থেকে বোঝা যায় কতগুলো worker বা connection লাগবে।
কীভাবে উন্নতি করবেন
- Latency কমাতে: cache, user-এর কাছে data নেওয়া (CDN), network hop কমানো, index দেওয়া, প্রতি request-এ কম কাজ করা।
- Throughput বাড়াতে: server বাড়ানো, async processing ও queue, batching, connection pooling।
মূল কথা: শুরুতেই দুটো লক্ষ্য লিখুন, যেমন "p99 ৩০০ ms-এর নিচে, প্রতি সেকেন্ডে ২,০০০ request", আর average নয়, percentile মাপুন।
System Design সিরিজের 2 নম্বর পর্ব (মোট ১৫)। আগের পর্ব: Scalability: vertical বনাম horizontal scaling.
