આ ત્રણ અલગ વસ્તુઓ વર્ણવે છે અને સતત ગૂંચવાય છે. Latency એ વિલંબ છે — data નું એક એકમ A થી B સુધી મુસાફરી કરવામાં કેટલો સમય લે છે (સમયમાં માપાય, દા.ત. ms). Bandwidth એ ક્ષમતા છે — એક link વહન કરી શકે તે મહત્તમ data rate (દા.ત. Gbps). Throughput એ rate છે જે તમે વ્યવહારમાં પ્રાપ્ત કરો છો, જે સામાન્ય રીતે bandwidth થી નીચે હોય છે. એક pipe ની ઉપમા તેને સ્પષ્ટ કરે છે:
├────────────── length of pipe = LATENCY (how long to traverse) ─────────────┤
╔══════════════════════════════════════════════════════════════════════════╗
║ width of pipe = BANDWIDTH (max capacity) ║
║ water actually flowing = THROUGHPUT (real achieved rate ≤ bandwidth) ║
╚══════════════════════════════════════════════════════════════════════════╝
નિર્ણાયક રીતે, પહોળો pipe તેને ટૂંકો બનાવતો નથી: bandwidth ઉમેરવાથી latency ઘટતું નથી. એક જાડી transatlantic link ને હજુ ~80 ms round-trip latency હોય છે જે અંતર અને પ્રકાશની ગતિ દ્વારા નક્કી થાય છે — તમે તેની નીચે જવા માટે ખરીદી શકતા નથી. આ જ કારણ છે કે latency, bandwidth નહીં, interactive apps ના અનુભવ પર પ્રભુત્વ ધરાવે છે: દરેક round trip (DNS, TCP handshake, TLS, પછી request) latency નો કર ચૂકવે છે, અને તે ઉમેરાય છે.
Latency અને throughput Bandwidth-Delay Product (BDP = bandwidth × round-trip time) દ્વારા સંવાદ કરે છે, જે pipe ને ભરેલો રાખવા "ઉડાનમાં" રહેલા data ની માત્રા છે. ઊંચી-bandwidth, ઊંચી-latency "long fat network" પર, TCP જેવો protocol જે ACKs ની રાહ જુએ છે તે pipe ને ભરી શકતો નથી સિવાય કે તેની window ઓછામાં ઓછી BDP જેટલી હોય — તેથી throughput છેવટે bandwidth થી નહીં, પણ latency દ્વારા મર્યાદિત થાય છે. એ જ કારણ છે કે લાંબા અંતર પર એક TCP stream ઝડપી link પર પણ ઘણી વાર underperform કરે છે, અને એ જ કારણ છે કે parallelism, મોટી windows, અને CDNs (જે અંતર, એટલે latency, ઘટાડે છે) મદદ કરે છે.
આ ત્રણને ગૂંચવવું એ સૌથી સામાન્ય — અને સૌથી પરિણામકારક — performance ભૂલોમાંની એક છે: teams ખરેખર latency ની સમસ્યાને ઠીક કરવા વધુ bandwidth ખરીદે છે અને કોઈ સુધારો જોતાં નથી. senior સૂઝ એ છે કે latency એ physics દ્વારા નક્કી થયેલો ફ્લોર છે (અંતર) જેને તમે architecturally હુમલો કરો છો — servers/CDNs ને users ની નજીક મૂકો, round trips ઘટાડો (connection reuse, HTTP/3, caching), અને requests ને batch કરો — જ્યારે bandwidth એ ઘણી વાર માત્ર provision કરવાની વસ્તુ છે. BDP સમજવું "ઝડપી" link ધીમા single-stream transfers આપે તેવા વિપરીત-સાહજિક પરિણામો સમજાવે છે, જે બરાબર એ પ્રકારનું reasoning છે જેની અપેક્ષા હોય છે જ્યારે તમે high-performance, ભૌગોલિક રીતે distributed systems ડિઝાઇન કે debug કરો છો.
વિગતવાર જવાબો સાથે IT ઇન્ટરવ્યૂ પ્રશ્નોની લાઇબ્રેરી — જુનિયરથી સિનિયર સુધી.
દાન કરો