Latency, throughput আর percentile — p99, tail latency আর Little-এর সূত্র

১ · Latency, throughput আর bandwidth — তিনটি আলাদা প্রশ্ন

ঈদের আগের রাত। একটি অনলাইন বাস-টিকিট সেবার (কাল্পনিক) ইঞ্জিনিয়ার রিনা dashboard দেখছেন: সার্ভার প্রতি সেকেন্ডে প্রায় ২,০০০টি অনুরোধ সামলাচ্ছে, গড় response time ১২০ ms — সব সবুজ। অথচ সোশ্যাল মিডিয়ায় অভিযোগ জমছে: “পেমেন্টের পাতা ঘুরছে তো ঘুরছেই।”

কে ঠিক? দুজনেই। গড় ১২০ ms হলেও প্রতি ১০০ জনে কয়েকজন হয়তো পাঁচ সেকেন্ড অপেক্ষা করছেন — গড় সেটি লুকিয়ে রাখে। এই পর্বে শিখবেন কোন সংখ্যা দেখতে হয়, কীভাবে হিসাব করতে হয়, আর ধীরতা আসে কোথা থেকে।

“সিস্টেমটা কত দ্রুত?” — এই প্রশ্নের ভেতরে আসলে তিনটি আলাদা প্রশ্ন আছে:

এই উদাহরণেই পর্বের প্রথম বড় শিক্ষা: বেশি throughput মানেই কম latency নয়। তিনটি সাধারণ কারণে দুটি আলাদা পথে চলে:

• Batching: অনেক কাজ জমিয়ে একসাথে করলে প্রতিটির স্থির খরচ ভাগ হয়ে যায়, throughput বাড়ে — কিন্তু প্রথম কাজটিকে দল ভরার অপেক্ষা করতে হয়। ডাকঘর দিনে একবার বস্তা পাঠালে খরচ কম, কিন্তু সকালে ফেলা চিঠিও রওনা দেয় বিকেলে।
• পুরো ব্যস্ত সার্ভার: সার্ভার ১০০% ব্যস্ত থাকলে throughput সর্বোচ্চ, কিন্তু প্রতিটি নতুন অনুরোধ লম্বা লাইনে দাঁড়ায় (অংশ ৭)।
• Bandwidth বাড়ালেও দূরত্ব কমে না: এক ট্রাক hard disk ঢাকা থেকে চট্টগ্রামে গেলে কয়েকশো terabyte একবারে পৌঁছায়, কিন্তু প্রথম byte পৌঁছাতেই কয়েক ঘণ্টা। সার্ভার যোগ করে throughput বাড়ানো সহজ; latency কমানো কঠিন, কারণ আলোর গতি আর পরপর ধাপের সংখ্যা কোড দিয়ে বদলায় না।

২ · একটি অনুরোধের সময় কোথায় যায় — network, queue আর service

একটি কাল্পনিক mobile banking অ্যাপে ব্যবহারকারী “ব্যালান্স দেখুন” চাপলেন। উত্তর আসতে যে সময় লাগল, তাকে তিন ভাগে ভাগ করা যায়:

• Network time: অনুরোধ যাওয়া আর উত্তর ফেরা — দূরত্ব, connection আর TLS-এর handshake, হারানো packet আবার পাঠানো। Fiber-এ আলো প্রতি ১,০০০ km যেতে এক দিকে প্রায় ৫ ms নেয়; এই সীমা কোনো কোড দিয়ে কমে না, কমে শুধু সার্ভারকে ব্যবহারকারীর কাছে আনলে।
• Queueing time (queueing delay): সার্ভার ব্যস্ত থাকলে অনুরোধ লাইনে দাঁড়ায় — load balancer-এ, worker thread-এর জন্য, database connection-এর জন্য, disk-এর জন্য।
• Service time: আসল কাজ — কোড চালানো, cache আর database থেকে পড়া।

ছবির দুটি দণ্ডই মূল কথা: চাপ বাড়লে network আর service প্রায় একই থাকে, লাফিয়ে বাড়ে queue — তাই সার্ভিস ধীর হলে আগে মেপে দেখুন সময় কোন অংশে যাচ্ছে।

কিছু অনুরোধ হঠাৎ অনেক ধীর হয় garbage collection-এর বিরতি, পেছনের কাজ (backup), অন্য প্রোগ্রামের সাথে CPU বা disk ভাগাভাগি, হারানো packet বা cache miss-এর কারণে। বড় সিস্টেমে এগুলো কখনো পুরো দূর হয় না।

৩ · গড় কেন ঠকায় — percentile আর nearest-rank হিসাব

ধরুন ১০০টি অনুরোধের ৯৮টি শেষ হলো ২০ ms-এ, আর ২টি আটকে গেল ২,০০০ ms (২ সেকেন্ড)। গড় = (৯৮ × ২০ + ২ × ২,০০০) ÷ ১০০ = ৫৯.৬ ms. এই সংখ্যাটি কারও অভিজ্ঞতা নয়: ৯৮ জন পেয়েছেন ২০ ms, আর ২ জন পেয়েছেন ২ সেকেন্ড। গড় দুই দলকেই ভুলভাবে বর্ণনা করে।

তাই latency মাপা হয় percentile দিয়ে। p99 = ৩০০ ms মানে ৯৯% অনুরোধ ৩০০ ms বা তার কম সময়ে শেষ হয় — প্রতি ১০০টিতে প্রায় ১টি এর চেয়ে ধীর। প্রচলিত কয়েকটি:

• p50 (median): অর্ধেক অনুরোধ এর চেয়ে দ্রুত — “সাধারণ” অভিজ্ঞতা।
• p90, p95: প্রতি ১০ বা ২০টিতে একটি এর চেয়ে ধীর — ভিড়ের সময়ের অভিজ্ঞতা।
• p99, p99.9: প্রতি ১০০ বা ১,০০০টিতে একটি — বণ্টনের লম্বা লেজ, ইংরেজিতে tail.

প্রতি ১,০০০টিতে একটি নিয়ে মাথাব্যথা কেন? প্রথমত, একজন ব্যবহারকারী অনেক অনুরোধ করেন: একটি পাতা খুলতে ৩০টি অনুরোধ লাগলে আর প্রতিটি ১% সময় ধীর হলে, পাতাটি অন্তত একটিতে আটকে যাওয়ার সম্ভাবনা ১ − ০.৯৯^৩০ ≈ ২৬% (অঙ্কটি অংশ ৪-এ)। দ্বিতীয়ত, ধীর অনুরোধ প্রায়ই সবচেয়ে মূল্যবান গ্রাহকের, যাঁর ডেটা বেশি; তাই Amazon-এর Dynamo paper (২০০৭) অনুযায়ী তাদের service-এর প্রতিশ্রুতি বা SLA মাপা হতো 99.9th percentile-এ (ভাবনার প্রশ্ন ১)।

নিচের stepper-এ ২০টি মাপ থেকে হাতে গড়, p50, p90 আর p99 বের করা হলো; প্রতিটি ঘরের নিচে লেখা তার rank.

সত্যিকারের ছবি পেতে লাখো মাপ লাগে। নিচের প্রোগ্রাম একটি নির্দিষ্ট seed থেকে ১,০০,০০০টি কৃত্রিম latency বানায়, তিনটি পথের মিশ্রণে: ৯৬.৫% স্বাভাবিক (median ২০ ms), ৩% ধীর মুহূর্তে — queue-র ভিড় বা ব্যস্ত disk (median ১২০ ms), আর ০.৫% খুব ধীর — GC-র বিরতি বা হারানো packet (median ৮০০ ms). প্রতিটি পথের সময় আসে lognormal বণ্টন থেকে, যার ডান দিকে লম্বা লেজ — বাস্তব latency-র খুব পরিচিত আকার।

// 100,000 simulated request latencies with a long tail; nearest-rank percentiles.
function rng(seed) {                          // mulberry32: small seeded PRNG
  return () => {
    seed = (seed + 0x6D2B79F5) | 0;
    let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}
const rand = rng(42);
const normal = () => Math.sqrt(-2 * Math.log(1 - rand())) * Math.cos(2 * Math.PI * rand());
const logn = (median, spread) => median * Math.exp(spread * normal());
function latency() {                          // one request, in ms
  const u = rand();
  if (u < 0.005) return logn(800, 0.4);       // 0.5%: GC pause, lost packet + retry
  if (u < 0.035) return logn(120, 0.5);       // 3%: queue spike, busy disk
  return logn(20, 0.3);                       // 96.5%: the normal fast path
}
const n = 100000;
const xs = Float64Array.from({ length: n }, latency).sort();   // ascending
const mean = xs.reduce((s, x) => s + x, 0) / n;
const pct = (q) => xs[Math.ceil(q * n) - 1];  // nearest-rank: value at rank ceil(q*n)
console.log("samples: " + n);
console.log("mean   = " + mean.toFixed(1) + " ms");
for (const [name, q] of [["p50", 0.5], ["p90", 0.9], ["p99", 0.99], ["p99.9", 0.999]])
  console.log(name.padEnd(6) + " = " + pct(q).toFixed(1) + " ms");
console.log("max    = " + xs[n - 1].toFixed(1) + " ms");
const slower = xs.filter((x) => x > mean).length;
console.log("requests slower than the mean: " + (100 * slower / n).toFixed(1) + "%");

samples: 100000
mean   = 28.9 ms
p50    = 20.3 ms
p90    = 31.4 ms
p99    = 199.7 ms
p99.9  = 1115.0 ms
max    = 2452.5 ms
requests slower than the mean: 14.4%

৪ · Tail latency আর fan-out — সবচেয়ে ধীরজনই সময় ঠিক করে

বড় সিস্টেমে একটি অনুরোধ প্রায়ই একা চলে না: search-এর প্রশ্ন একসাথে যায় ডেটার প্রতিটি ভাগে বা shard-এ, হোম পাতা বানাতে একসাথে ডাকা হয় প্রোফাইল, অফার আর সুপারিশের সার্ভিস। একটি অনুরোধ থেকে এভাবে অনেক অনুরোধ ছড়িয়ে পড়াকে বলে fan-out. সবার উত্তর মিলিয়ে তবেই ফল দিলে মোট সময় = সবচেয়ে ধীর উত্তরের সময়। Latency বণ্টনের এই ধীর প্রান্তের নাম tail latency.

হিসাবটি বিখ্যাত হয় Google-এর Jeffrey Dean ও Luiz André Barroso-র লেখা “The Tail at Scale” (Communications of the ACM, ২০১৩) থেকে। তাঁদের উদাহরণ: একটি সার্ভারের p99 এক সেকেন্ড হলে, আর একটি অনুরোধকে এমন ১০০টি সার্ভারের উত্তরের অপেক্ষা করতে হলে, প্রায় ৬৩% অনুরোধ এক সেকেন্ডের বেশি সময় নেবে। যে ধীরতা একটি সার্ভারে “বিরল”, fan-out-এ সেটিই সাধারণ।

উল্টো দিকের প্রশ্ন: পুরো অনুরোধের p99 ঠিক রাখতে প্রতিটি backend-কে কতটা ভালো হতে হবে? (1 − p)^N = ০.৯৯ হলে প্রতিটির দ্রুত হওয়ার সম্ভাবনা ০.৯৯^1/N; N = ১০০-এ সেটি প্রায় ০.৯৯৯৯ — অর্থাৎ backend-এর p99.99-ই ঠিক করে পুরো অনুরোধের p99. নিচের প্রোগ্রাম দুটোই হিসাব করে, আর simulation দিয়ে সূত্রটি যাচাই করে।

// Fan-out: one user request waits for ALL N backends (parallel calls).
// Each backend is "slow" with probability p, independently of the others.
// P(user request sees at least one slow reply) = 1 - (1 - p)^N
const slowAny = (p, N) => 1 - Math.pow(1 - p, N);
const pc = (x, d) => (100 * x).toFixed(d) + "%";
console.log("N     p=1%    p=0.1%   each backend needs");
for (const N of [1, 2, 5, 10, 20, 50, 100, 200]) {
  const need = Math.pow(0.99, 1 / N);        // for the whole request's p99
  console.log(String(N).padEnd(6) + pc(slowAny(0.01, N), 1).padEnd(8) +
              pc(slowAny(0.001, N), 2).padEnd(9) + "p" + (100 * need).toFixed(3));
}
// Check the formula by simulation (seeded, so the same every run)
function rng(seed) {                          // mulberry32
  return () => {
    seed = (seed + 0x6D2B79F5) | 0;
    let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}
const rand = rng(2013), users = 20000, N = 100, p = 0.01;
let hit = 0;
for (let u = 0; u < users; u++) {
  let slow = false;
  for (let b = 0; b < N; b++) if (rand() < p) slow = true;
  if (slow) hit++;
}
console.log("simulated: N = 100, p = 1% -> " + pc(hit / users, 1) +
            " of " + users + " user requests slow");

N     p=1%    p=0.1%   each backend needs
1     1.0%    0.10%    p99.000
2     2.0%    0.20%    p99.499
5     4.9%    0.50%    p99.799
10    9.6%    1.00%    p99.900
20    18.2%   1.98%    p99.950
50    39.5%   4.88%    p99.980
100   63.4%   9.52%    p99.990
200   86.6%   18.14%   p99.995
simulated: N = 100, p = 1% -> 62.9% of 20000 user requests slow

৫ · Tail ছোট করার কৌশল — hedged request, timeout, কম fan-out আর cache

সব ধীরতা দূর করা যায় না, কিন্তু নকশা এমন করা যায় যাতে কিছু অংশ ধীর হলেও ব্যবহারকারী কম টের পান — Dean ও Barroso-র ভাষায় tail-tolerant নকশা। প্রধান চারটি কৌশল:

খুব ছোট timeout দিলে স্বাভাবিক ধীর উত্তরও ব্যর্থ ধরা হয় আর retry বাড়ে; খুব বড় দিলে thread আর connection আটকে থাকে। একটি ভালো শুরু: নিচের সার্ভিসের p99.9-এর একটু ওপরে, কিন্তু পুরো অনুরোধের বাজেটের ভেতরে (অংশ ৮)। সবচেয়ে কাজের অভ্যাস deadline propagation — “আর ১৮০ ms বাকি” তথ্যটি প্রতিটি call-এর সাথে নিচে পাঠানো, যাতে সময় ফুরালে নিচের সার্ভিসগুলোও অকারণ খাটুনি থামায়।

Hedging কতটা কাজ করে, নিচের simulation-এ দেখুন। এখানে অংশ ৩-এর একই latency মডেল; একটি call তার p95-এর মধ্যে উত্তর না দিলে দ্বিতীয় replica-তে কপি যায়, আর যে উত্তর আগে আসে সেটিই নেওয়া হয়।

// Hedged request: if no reply after d ms, send a copy to a second replica and
// use whichever reply comes first. Same long-tail latency model as before.
function rng(seed) {                          // mulberry32
  return () => {
    seed = (seed + 0x6D2B79F5) | 0;
    let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}
const rand = rng(42);
const normal = () => Math.sqrt(-2 * Math.log(1 - rand())) * Math.cos(2 * Math.PI * rand());
const logn = (median, spread) => median * Math.exp(spread * normal());
function latency() {                          // one call to one replica, in ms
  const u = rand();
  if (u < 0.005) return logn(800, 0.4);       // 0.5%: GC pause, lost packet + retry
  if (u < 0.035) return logn(120, 0.5);       // 3%: queue spike, busy disk
  return logn(20, 0.3);                       // 96.5%: the normal fast path
}
const n = 100000;
const plain = Float64Array.from({ length: n }, latency).sort();
const pct = (xs, q) => xs[Math.ceil(q * n) - 1].toFixed(1).padStart(8);
const d = plain[Math.ceil(0.95 * n) - 1];     // hedge delay = p95 of a single call
let extra = 0;
const hedged = Float64Array.from({ length: n }, () => {
  const first = latency();
  if (first <= d) return first;               // answered in time: no copy sent
  extra++;
  return Math.min(first, d + latency());      // copy sent at time d
}).sort();
console.log("hedge after d = " + d.toFixed(1) + " ms (p95 of one call)");
console.log("           p50      p99      p99.9   (ms)");
console.log("plain  " + pct(plain, 0.5) + " " + pct(plain, 0.99) + " " + pct(plain, 0.999));
console.log("hedged " + pct(hedged, 0.5) + " " + pct(hedged, 0.99) + " " + pct(hedged, 0.999));
console.log("extra requests sent: " + (100 * extra / n).toFixed(1) + "%");

hedge after d = 38.3 ms (p95 of one call)
           p50      p99      p99.9   (ms)
plain      20.3    199.7   1115.0
hedged     20.3     61.7     82.7
extra requests sent: 4.9%

৬ · Little-এর সূত্র — L = λW

এবার queue-র সবচেয়ে কাজের সূত্রটি। যেকোনো স্থিতিশীল সিস্টেমে — একটি ব্যাংকের শাখা, একটি web server, একটি database connection pool — তিনটি গড়ের মধ্যে একটি সরল সম্পর্ক থাকে। একে বলে Little-এর সূত্র:

• L — গড়ে একসাথে ভেতরে কতগুলো (অনুরোধ, গ্রাহক, message)
• λ (lambda) — গড় আগমনের হার; স্থিতিশীল অবস্থায় যত আসে তত বেরোয়, তাই এটিই throughput
• W — প্রতিটির ভেতরে থাকার গড় সময়, অর্থাৎ latency

সূত্রটির শক্তি হলো, তিনটির যেকোনো দুটি জানলে তৃতীয়টি পাওয়া যায় — কোনো বণ্টন না জেনেই। System design-এ চারটি প্রচলিত প্রয়োগ:

শেষ সারিটির শিক্ষা: concurrency-র সীমা থাকলে throughput ≤ concurrency ÷ latency. Database ধীর হয়ে W দ্বিগুণ হলে একই thread-সংখ্যায় throughput অর্ধেক, আর বাকি অনুরোধ জমে queue লম্বা হয় — একটি ধীর dependency এভাবেই পুরো সার্ভিস বসিয়ে দেয়।

৭ · Utilisation আর queue — ব্যস্ততা বাড়লে অপেক্ষা কেন বিস্ফোরিত হয়

একটি সার্ভার গড়ে S সময়ে একটি অনুরোধ শেষ করে; তাহলে সে সেকেন্ডে সর্বোচ্চ μ = 1/S টি অনুরোধ শেষ করতে পারে — μ-কে বলে service rate. অনুরোধ আসে সেকেন্ডে λ-টি। সার্ভার মোট সময়ের যত ভাগ ব্যস্ত থাকে, তা-ই তার utilisation:

যেমন S = ১০ ms হলে μ = সেকেন্ডে ১০০; সেকেন্ডে ৮০টি অনুরোধ এলে ρ = ০.৮, অর্থাৎ সার্ভার ৮০% সময় ব্যস্ত।

গড়ে সামলানো গেলেও অপেক্ষা কেন? কারণ অনুরোধ সমান তালে আসে না — কখনো পরপর পাঁচটি, কখনো কিছুক্ষণ একটিও না। ভিড় জমলে তা সরে কেবল বাড়তি ক্ষমতা μ − λ দিয়ে। ρ যত ১-এর কাছে যায়, বাড়তি ক্ষমতা তত ছোট, আর ছোট একটি ভিড়ও তত দীর্ঘ সময় টিকে থাকে। নিচে একটি বাস কাউন্টারে দেখুন।

M/M/1 — সবচেয়ে সরল queue-র সূত্র

Stepper-এর সংখ্যাগুলো এসেছে M/M/1 মডেল থেকে (David Kendall-এর ১৯৫৩ সালের নামকরণে প্রথম M = স্মৃতিহীন এলোমেলো আগমন, দ্বিতীয় M = এলোমেলো service, 1 = একজন সেবাদাতা)। অনুমানগুলো: আগমন এলোমেলো আর একে অন্যের ওপর নির্ভরহীন (Poisson আগমন), service time-ও এলোমেলো (exponential বণ্টন), যে আগে আসে সে আগে সেবা পায়, আর লাইনের দৈর্ঘ্যের সীমা নেই। ফল:

S = ১০ ms ধরে টেবিলটি দেখুন। শেষ কলাম p99: M/M/1-এ response time-এর বণ্টন exponential, তাই p99 = ln(100) × W ≈ ৪.৬ × W.

তত্ত্ব কি সত্যিই খাটে? নিচের প্রোগ্রাম একটি M/M/1 queue চালায় — প্রতিটি অনুরোধের আগমন, অপেক্ষা আর বিদায় ধরে ধরে (discrete-event simulation), নির্দিষ্ট seed-এ। Little-এর সূত্রও এখানে যাচাই হয়: λ গোনা হয় দরজায়, W প্রতিটি অনুরোধের stopwatch-এ, আর L আলাদাভাবে — ১,০০,০০০টি সমান ফাঁকের মুহূর্তে ভেতরে কতজন, গুনে।

// M/M/1: one server, first-come-first-served, random (Poisson) arrivals and
// random (exponential) service times. Mean service time S = 10 ms.
function rng(seed) {                          // mulberry32: seeded, repeatable
  return () => {
    seed = (seed + 0x6D2B79F5) | 0;
    let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}
const S = 10, mu = 1 / S, N = 200000;        // mu = 0.1 requests per ms
console.log("rho      W sim  1/(mu-lam)  L counted  lam*W");
for (const rho of [0.5, 0.8, 0.9, 0.95]) {
  const rand = rng(2026), lam = rho * mu;
  const gap = (rate) => -Math.log(1 - rand()) / rate;   // exponential
  const arr = new Float64Array(N), dep = new Float64Array(N);
  let t = 0, free = 0;                       // free = when the server is next idle
  for (let i = 0; i < N; i++) {              // event by event: arrive, wait, leave
    t += gap(lam); arr[i] = t;
    free = Math.max(free, t) + gap(mu); dep[i] = free;
  }
  let sumW = 0;
  for (let i = 0; i < N; i++) sumW += dep[i] - arr[i];
  const W = sumW / N, lamHat = N / arr[N - 1]; // measured mean time, arrival rate
  let a = 0, d = 0, inside = 0, K = 100000;  // head count: how many are inside
  for (let k = 1; k <= K; k++) {             // at K evenly spaced moments
    const when = arr[N - 1] * k / K;
    while (a < N && arr[a] <= when) a++;
    while (d < N && dep[d] <= when) d++;
    inside += a - d;
  }
  console.log(rho.toFixed(2) + (W.toFixed(1) + " ms").padStart(11) +
    ((1 / (mu - lam)).toFixed(1) + " ms").padStart(12) +
    (inside / K).toFixed(2).padStart(11) + (lamHat * W).toFixed(2).padStart(7));
}

rho      W sim  1/(mu-lam)  L counted  lam*W
0.50    20.0 ms     20.0 ms       1.00   1.00
0.80    49.7 ms     50.0 ms       3.99   3.99
0.90   103.0 ms    100.0 ms       9.29   9.29
0.95   219.7 ms    200.0 ms      20.91  20.91

৮ · Bottleneck আর latency budget — সবচেয়ে সরু ধাপ আর সময়ের বাজেট

একটি অনুরোধ যখন পরপর কয়েকটি ধাপ পার হয়, তখন দুটি সরল নিয়ম খাটে: latency যোগ হয় — প্রতিটি ধাপের সময় মিলিয়ে মোট; আর throughput হয় সবচেয়ে ছোটটি — যে ধাপ সবচেয়ে কম পারে, পুরো ব্যবস্থা তার বেশি পারে না। সেই ধাপের নাম bottleneck.

ধরা যাক একটি কাল্পনিক অনলাইন দোকানের checkout-এ প্রতিটি অনুরোধে লাগে app server-এর একবার কাজ, cache-এ ৩টি পড়া আর database-এ ২টি লেখা। প্রতিটি ধাপের ক্ষমতা নিচে ধরে নেওয়া হলো:

পুরো ব্যবস্থা সেকেন্ডে ১,৫০০-এর বেশি checkout পারবে না — app server দ্বিগুণ করলেও না। Database-এর কাজ কমালে বা database ভাগ করলে (পর্ব ২৩) সীমা ওঠে, আর তখন সামনে আসে পরের সরু ধাপ — app tier-এর ৪,৮০০; bottleneck শুধু জায়গা বদলায়।

Latency budget — সময়ও বাজেট করে খরচ করতে হয়

Throughput-এর যেমন সীমা, সময়েরও তেমনি বাজেট। ধরা যাক একটি কাল্পনিক mobile banking সেবার লক্ষ্য: “ব্যালান্স দেখুন”-এর p99 থাকবে ৩০০ ms-এর মধ্যে (এমন লক্ষ্য আসে non-functional requirement থেকে — পর্ব ২)। এমন মাপযোগ্য লক্ষ্যকে বলে SLO; SLI, SLO আর error budget-এর বিস্তারিত পর্ব ৫০-এ। লক্ষ্যটি স্তরগুলোর মধ্যে ভাগ করে দেওয়াই latency budget:

বাজেট নিয়ে দুটি সতর্কতা:

• Percentile সরাসরি যোগ হয় না। স্তরগুলোর p99 যোগ করলে মোটের p99-এর একটি রক্ষণশীল আন্দাজ মেলে (সাধারণত আসলের চেয়ে বেশি), নিশ্চিত হিসাব নয় — সব স্তর একই অনুরোধে একসাথে ধীর হয় না।
• Timeout আসে বাজেট থেকে। লেনদেন-সার্ভিসের বাজেট ৫০ ms হলে timeout-ও মোটামুটি সেখানে, আর বাকি সময় (deadline) নিচের call-এ যায় (অংশ ৫)।

৯ · ঠিকভাবে মাপা — histogram, load test আর warm-up

ভুল মাপ থেকে ভুল নকশা আসে। Latency মাপার তিনটি নিয়ম:

১. গড় নয়, histogram রাখুন

প্রতিটি অনুরোধের সময় আলাদা জমা রাখা ব্যয়বহুল, তাই সার্ভিসগুলো সময়কে খোপে গোনে — ০–৫ ms-এ কতটি, ৫–১০-এ কতটি …। এই গণনাই histogram. খোপ থেকে percentile আন্দাজ করা যায়, আর দুই সার্ভারের খোপগুলো যোগ করলেই পুরো সার্ভিসের histogram. ১,০০০টি নমুনায় p99.9-এর ওপরে মাত্র একটি মান থাকে — tail দেখতে লাখের ঘরের নমুনা লাগে।

২. কোথায় মাপছেন, জানুন

সার্ভারের ভেতরে মাপা সময়ে network আর দরজার বাইরের queue বাদ পড়ে; ব্যবহারকারীর ফোনে মাপা সময় (real user monitoring) আসল অভিজ্ঞতা দেখায়, কিন্তু দোষ কোন অংশের, তা বলা কঠিন। দুটোই রাখুন।

৩. Load test — বাস্তবের মতো করে

Load test-এ কৃত্রিম অনুরোধ পাঠিয়ে দেখা হয় কোন চাপে latency কেমন থাকে। ফল বিশ্বাসযোগ্য করতে:

• বাস্তবের মতো অনুরোধের মিশ্রণ আর ডেটার আকার রাখুন — শুধু একটি URL বারবার নয়।
• Warm-up বাদ দিন: শুরুর কয়েক মিনিট cache খালি, JIT compile চলছে, connection নতুন — সেই মাপ স্থির অবস্থার নয়।
• যথেষ্ট লম্বা সময় চালান, যাতে GC, পর্যায়ক্রমিক কাজ আর log rotation ধরা পড়ে।
• চাপ ধাপে ধাপে বাড়ান আর দেখুন কোথায় p99 হঠাৎ খাড়া হয়ে ওঠে — সেই “হাঁটু” (knee)-ই বাস্তব ক্ষমতা, গড় CPU নয়।
• বাস্তবের ব্যবহারকারী অন্যদের উত্তরের অপেক্ষা না করেই আসেন (open loop); অনেক টুল একটি উত্তর পেলে তবে পরের অনুরোধ পাঠায় (closed loop), তাই সার্ভার ধীর হলে টুল নিজেই কম পাঠায়।

১০ · AI-এর যুগে — latency আর capacity-র হিসাবে AI-কে যাচাই

“আমাদের সার্ভিসে কয়টি সার্ভার লাগবে?” — AI কয়েক সেকেন্ডে গোছানো উত্তর দেয়, প্রায়ই সাথে “Redis বসান, Kafka যোগ করুন, microservice-এ ভাগ করুন”। এই বিষয়ে তার ভুলগুলো খুব নির্দিষ্ট:

AI-এর capacity plan হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি সংখ্যার একক মিলিয়ে নিজে আবার হিসাব করেছি
• আলোচনা গড়ে নয়, p99/p99.9-এ হয়েছে; কোথাও percentile-এর গড় নেওয়া হয়নি
• ρ কত ধরা হলো দেখেছি — ০.৮-এর বেশি হলে queueing-এর ঝুঁকি simulator চালিয়ে যাচাই করেছি
• Fan-out থাকলে 1 − (1 − p)^N দিয়ে tail হিসাব করেছি
• পণ্যের সীমা আর দাম অফিসিয়াল documentation-এ মিলিয়েছি, আর একটি ছোট load test চালিয়েছি
• Failure mode ভেবেছি: একটি সার্ভার বিকল বা dependency ধীর হলে কী হয়