ਇਹ ਤਿੰਨੇ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹਨ ਅਤੇ ਲਗਾਤਾਰ ਉਲਝਾਏ ਜਾਂਦੇ ਹਨ। Latency ਦੇਰੀ ਹੈ — data ਦੀ ਇੱਕ ਇਕਾਈ ਨੂੰ A ਤੋਂ B ਤੱਕ ਜਾਣ ਵਿੱਚ ਕਿੰਨਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ (ਸਮੇਂ ਵਿੱਚ ਮਾਪਿਆ, ਜਿਵੇਂ ms)। Bandwidth ਸਮਰੱਥਾ ਹੈ — ਇੱਕ link ਵੱਧ ਤੋਂ ਵੱਧ ਕਿੰਨੀ data rate ਲੈ ਜਾ ਸਕਦਾ ਹੈ (ਜਿਵੇਂ Gbps)। ਉਹ rate ਹੈ ਜੋ ਤੁਸੀਂ ਵਿਹਾਰ ਵਿੱਚ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ, ਜੋ ਆਮ ਤੌਰ 'ਤੇ bandwidth ਤੋਂ ਹੇਠਾਂ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਪਾਈਪ ਦੀ ਉਪਮਾ ਇਸਨੂੰ ਸਪੱਸ਼ਟ ਕਰ ਦਿੰਦੀ ਹੈ:
├────────────── length of pipe = LATENCY (how long to traverse) ─────────────┤
╔══════════════════════════════════════════════════════════════════════════╗
║ width of pipe = BANDWIDTH (max capacity) ║
║ water actually flowing = THROUGHPUT (real achieved rate ≤ bandwidth) ║
╚══════════════════════════════════════════════════════════════════════════╝
ਅਹਿਮ ਗੱਲ, ਇੱਕ ਚੌੜਾ ਪਾਈਪ ਇਸਨੂੰ ਛੋਟਾ ਨਹੀਂ ਕਰਦਾ: bandwidth ਜੋੜਨ ਨਾਲ latency ਘੱਟ ਨਹੀਂ ਹੁੰਦੀ। ਇੱਕ ਮੋਟੇ transatlantic link ਦੀ ਵੀ ਦੂਰੀ ਅਤੇ ਰੋਸ਼ਨੀ ਦੀ ਗਤੀ ਦੁਆਰਾ ਤੈਅ ~80 ms ਦੀ round-trip latency ਹੁੰਦੀ ਹੈ — ਤੁਸੀਂ ਇਸ ਦੇ ਹੇਠਾਂ ਜਾਣ ਲਈ ਪੈਸੇ ਨਹੀਂ ਖ਼ਰਚ ਸਕਦੇ। ਇਸੇ ਕਰਕੇ latency, ਨਾ ਕਿ bandwidth, interactive ਐਪਸ ਦੇ ਅਹਿਸਾਸ 'ਤੇ ਹਾਵੀ ਰਹਿੰਦੀ ਹੈ: ਹਰ round trip (DNS, TCP handshake, TLS, ਫਿਰ request) latency ਦਾ ਟੈਕਸ ਭਰਦੀ ਹੈ, ਅਤੇ ਇਹ ਜੁੜਦੇ ਜਾਂਦੇ ਹਨ।
Latency ਅਤੇ throughput Bandwidth-Delay Product (BDP = bandwidth × round-trip time) ਰਾਹੀਂ ਆਪਸ ਵਿੱਚ ਪ੍ਰਭਾਵ ਪਾਉਂਦੇ ਹਨ, ਪਾਈਪ ਨੂੰ ਭਰਿਆ ਰੱਖਣ ਲਈ "ਰਾਹ ਵਿੱਚ" ਮੌਜੂਦ data ਦੀ ਮਾਤਰਾ। ਇੱਕ high-bandwidth, high-latency "long fat network" 'ਤੇ, TCP ਵਰਗਾ protocol ਜੋ ACK ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ ਪਾਈਪ ਨੂੰ ਉਦੋਂ ਤੱਕ ਨਹੀਂ ਭਰ ਸਕਦਾ ਜਦੋਂ ਤੱਕ ਇਸਦੀ window ਘੱਟੋ-ਘੱਟ BDP ਜਿੰਨੀ ਨਾ ਹੋਵੇ — ਇਸ ਲਈ throughput ਅੰਤ ਵਿੱਚ latency ਦੁਆਰਾ ਸੀਮਿਤ ਹੋ ਜਾਂਦਾ ਹੈ, bandwidth ਦੁਆਰਾ ਨਹੀਂ। ਇਸੇ ਕਰਕੇ ਲੰਬੀ ਦੂਰੀ 'ਤੇ ਇੱਕ ਇਕੱਲਾ TCP stream ਇੱਕ ਤੇਜ਼ link 'ਤੇ ਵੀ ਅਕਸਰ ਘੱਟ ਪ੍ਰਦਰਸ਼ਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਿਉਂ parallelism, ਵੱਡੀਆਂ window, ਅਤੇ CDN (ਜੋ ਦੂਰੀ, ਇਸ ਲਈ latency ਘਟਾਉਂਦੇ ਹਨ) ਮਦਦ ਕਰਦੇ ਹਨ।
ਇਹਨਾਂ ਤਿੰਨਾਂ ਨੂੰ ਰਲਗੱਡ ਕਰਨਾ ਸਭ ਤੋਂ ਆਮ — ਅਤੇ ਸਭ ਤੋਂ ਵੱਧ ਨਤੀਜਾ-ਭਰਪੂਰ — ਪ੍ਰਦਰਸ਼ਨ ਗ਼ਲਤੀਆਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ: teams ਉਸ ਚੀਜ਼ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਹੋਰ bandwidth ਖ਼ਰੀਦਦੇ ਹਨ ਜੋ ਅਸਲ ਵਿੱਚ ਇੱਕ latency ਸਮੱਸਿਆ ਹੈ ਅਤੇ ਕੋਈ ਸੁਧਾਰ ਨਹੀਂ ਦੇਖਦੇ। Senior ਸੂਝ ਇਹ ਹੈ ਕਿ latency ਭੌਤਿਕ ਵਿਗਿਆਨ ਦੁਆਰਾ ਤੈਅ ਇੱਕ ਫ਼ਰਸ਼ ਹੈ (ਦੂਰੀ) ਜਿਸ 'ਤੇ ਤੁਸੀਂ architecture ਦੇ ਢੰਗ ਨਾਲ ਹਮਲਾ ਕਰਦੇ ਹੋ — server/CDN ਨੂੰ ਵਰਤੋਂਕਾਰਾਂ ਦੇ ਨੇੜੇ ਰੱਖੋ, round trip ਘਟਾਓ (connection ਦੀ ਮੁੜ-ਵਰਤੋਂ, HTTP/3, caching), request batch ਕਰੋ — ਜਦੋਂ ਕਿ bandwidth ਅਕਸਰ ਸਿਰਫ਼ provision ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। BDP ਨੂੰ ਸਮਝਣਾ ਵਿਰੋਧਾਭਾਸੀ ਨਤੀਜਿਆਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਇੱਕ "ਤੇਜ਼" link ਹੌਲੀ single-stream transfer ਦੇਣਾ, ਜੋ ਠੀਕ ਉਸ ਕਿਸਮ ਦੀ ਸੋਚ ਹੈ ਜਿਸਦੀ ਉਮੀਦ ਉਦੋਂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ high-performance, ਭੂਗੋਲਿਕ ਤੌਰ 'ਤੇ ਵੰਡੇ ਹੋਏ systems ਡਿਜ਼ਾਈਨ ਜਾਂ debug ਕਰਦੇ ਹੋ।
ਵਿਸਤ੍ਰਿਤ ਜਵਾਬਾਂ ਨਾਲ IT ਇੰਟਰਵਿਊ ਸਵਾਲਾਂ ਦੀ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ — ਜੂਨੀਅਰ ਤੋਂ ਸੀਨੀਅਰ ਤੱਕ।
ਦਾਨ ਕਰੋ