Latency vs Throughput
- ●Latency হলো একটা request-এর উত্তর পেতে কত সময় লাগে (যেমন ৫০ ms), আর throughput হলো প্রতি সেকেন্ডে কতগুলো request সামলানো যায় (যেমন ১০০০ RPS)।
- ●দুটো আলাদা জিনিস — কম latency মানেই বেশি throughput নয়, আবার উল্টোটাও সত্যি।
- ●Latency মাপতে গড় নয়, p50/p95/p99 percentile দেখাই বেশি নির্ভরযোগ্য।
সমস্যাটা কী?
ধরো তোমার e-commerce সাইটে কেউ একটা product পেজে ক্লিক করল। দুটো প্রশ্ন আলাদা:
১. একজন user-কে পেজটা দেখাতে কত সময় লাগল? — হতে পারে ৮০ মিলিসেকেন্ড। ২. একই সময়ে কতজন user-কে তুমি সামলাতে পারবে? — হতে পারে সেকেন্ডে ৫০০০ জন।
মানুষ প্রায়ই এই দুটোকে গুলিয়ে ফেলে। "আমার সিস্টেম দ্রুত" বলতে কী বোঝাচ্ছ — একজনের জন্য দ্রুত, নাকি অনেকের জন্য একসাথে? Eid sale-এর দিন হাজার হাজার মানুষ একসাথে এলে এই পার্থক্য বোঝা না থাকলে সিস্টেম মুখ থুবড়ে পড়বে।
মূল ধারণা
Latency হলো একটা একক request পাঠানো থেকে তার উত্তর পাওয়া পর্যন্ত সময় — মাপা হয় millisecond-এ। Throughput হলো একটা নির্দিষ্ট সময়ে সিস্টেম কতগুলো request সামলাতে পারে — মাপা হয় RPS (requests per second) বা TPS (transactions per second)-এ।
সহজ কথায়: Latency = "কত দ্রুত?", Throughput = "কতটা একসাথে?"। এ দুটো সম্পর্কিত, কিন্তু এক নয়।
কীভাবে কাজ করে
Water-pipe analogy
একটা পানির পাইপ কল্পনা করো:
- Latency = পাইপের এক মাথা থেকে এক ফোঁটা পানি অন্য মাথায় পৌঁছাতে কত সময় লাগে (পাইপের দৈর্ঘ্য)।
- Throughput = প্রতি সেকেন্ডে পাইপ দিয়ে কত লিটার পানি বের হয় (পাইপের চওড়া)।
একটা পাইপ লম্বা হলেও মোটা হতে পারে (বেশি latency, বেশি throughput); আবার ছোট কিন্তু সরু হতে পারে (কম latency, কম throughput)। এই দুটো আলাদা মাত্রা।
একক ও সংখ্যা
| পরিমাপ | একক | সাধারণ মান |
|---|---|---|
| Latency | ms (millisecond) | ভালো API: ৫০–২০০ ms |
| Throughput | RPS / TPS | মাঝারি সার্ভিস: হাজার–লাখ RPS |
| Memory access | nanosecond | ~১০০ ns |
| SSD read | microsecond | ~১৫০ µs |
| একই data center-এ network round-trip | ms | ~০.৫ ms |
| মহাদেশ পেরিয়ে network round-trip | ms | ~১৫০ ms |
এই সংখ্যাগুলো (যা "latency numbers every programmer should know" নামে বিখ্যাত) মাথায় থাকলে কোথায় সময় খরচ হচ্ছে তা আন্দাজ করা যায়।
কীভাবে trade off হয়
দুটো প্রায়ই একে অপরের সাথে টানাপোড়েনে থাকে। ধরো তুমি অনেকগুলো request একসাথে জড়ো করে (batching) প্রসেস করলে — এতে throughput বাড়ে (কম overhead-এ বেশি কাজ), কিন্তু প্রতিটা request-কে অপেক্ষা করতে হয় বলে latency বাড়ে। উল্টোদিকে, প্রতিটা request সাথে সাথে আলাদা করে প্রসেস করলে latency কমে, কিন্তু throughput কমে যেতে পারে।
ঢাকার বাস ভাবো। Latency = তুমি একা একটা CNG নিলে দ্রুত পৌঁছাবে। Throughput = একটা বড় বাস একসাথে ৫০ জন নিয়ে যায়। বাস ধীর (বেশি latency — থামতে থামতে যায়), কিন্তু ঘণ্টায় অনেক বেশি মানুষ পার করে (বেশি throughput)। CNG দ্রুত (কম latency), কিন্তু একসাথে অল্প মানুষ (কম throughput)। কোনটা ভালো? সেটা নির্ভর করে তুমি কী চাও।
কৌশল — percentile দিয়ে latency মাপা
Latency মাপতে গিয়ে শুধু average দেখলে বড় ভুল হয়। ধরো ৯৯টা request ৫০ ms-এ শেষ হলো, কিন্তু ১টা ৫ সেকেন্ড নিল। গড় হয়তো ১০০ ms দেখাবে — কিন্তু একজন user তো ৫ সেকেন্ড অপেক্ষা করল! তাই আমরা Percentile ব্যবহার করি:
- p50 (median) — ৫০% request এই সময়ের মধ্যে শেষ। সাধারণ অভিজ্ঞতা।
- p95 — ৯৫% request এর মধ্যে শেষ। কিছুটা খারাপ ক্ষেত্র।
- p99 — ৯৯% request এর মধ্যে শেষ। সবচেয়ে ধীর ১% (tail latency)।
বড় সিস্টেমে p99-ই আসল গল্প বলে, কারণ একজন user একই সেশনে অনেকগুলো request পাঠায় — তার মধ্যে অন্তত একটা সেই ধীর ১%-এ পড়ার সম্ভাবনা অনেক বেশি।
| Percentile | মানে | কেন গুরুত্বপূর্ণ |
|---|---|---|
| p50 | মাঝারি user-এর অভিজ্ঞতা | সাধারণ অবস্থা বোঝে |
| p95 | মোটামুটি খারাপ ক্ষেত্র | SLA-তে অনেক সময় ব্যবহার হয় |
| p99 | সবচেয়ে ধীর tail | বড় সিস্টেমে আসল user-pain এখানে |
কখন ব্যবহার করবে / করবে না
Real-time অভিজ্ঞতার জন্য (গেম, চ্যাট, পেমেন্ট confirmation) latency-কে অগ্রাধিকার দাও। বড় ব্যাকগ্রাউন্ড কাজের জন্য (লগ প্রসেসিং, ব্যাচ রিপোর্ট, ভিডিও এনকোডিং) throughput-কে অগ্রাধিকার দাও।
সবচেয়ে বড় ভুল: শুধু average latency দিয়ে dashboard বানানো। Average দেখে মনে হবে সব ঠিক, অথচ তোমার p99 user-রা ভয়াবহ অভিজ্ঞতা পাচ্ছে আর চুপচাপ অ্যাপ ছেড়ে যাচ্ছে। সবসময় p95/p99 monitor করো।
বাস্তব উদাহরণ
Amazon একটা বিখ্যাত গবেষণায় দেখায় যে প্রতি ১০০ ms অতিরিক্ত latency-তে তাদের বিক্রি প্রায় ১% কমে যায়। তাই তারা latency-কে p99/p99.9 পর্যন্ত track করে। অন্যদিকে তাদের বিশাল order-প্রসেসিং বা সুপারিশ (recommendation) সিস্টেম latency-এর চেয়ে throughput-এ বেশি মনোযোগ দেয় — কারণ সেগুলো ব্যাকগ্রাউন্ডে বিপুল পরিমাণ ডেটা সামলায়, একটু দেরি হলেও user টের পায় না।
যখন কেউ বলে "সিস্টেমটা fast হতে হবে", পাল্টা জিজ্ঞেস করো — "fast মানে কম latency, নাকি বেশি throughput?" আর "কোন percentile target — p50 না p99?"। এই দুটো প্রশ্নই দেখায় তুমি performance নিয়ে গভীরভাবে ভাবো।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. Throughput মাপা হয় কোন এককে?
2. p99 latency 200ms মানে কী?
3. Latency মাপতে শুধু average কেন যথেষ্ট নয়?