რა განსხვავებაა latency-ს, bandwidth-სა და throughput-ს შორის?

Question

IT Interview Practice · Accepted Answer

ეს სამი განსხვავებულ რაღაცეებს აღწერს და მუდმივად ერევათ. **Latency** არის *დაყოვნება* — რამდენ ხანს სჭირდება მონაცემის ერთ ერთეულს A-დან B-მდე მისვლა (იზომება დროში, მაგ. ms). **Bandwidth** არის *ტევადობა* — მაქსიმალური მონაცემთა სიჩქარე, რომელიც არხს გადააქვს (მაგ. Gbps). **Throughput** არის *ფაქტობრივი* სიჩქარე, რომელსაც პრაქტიკაში აღწევთ, რაც ჩვეულებრივ bandwidth-ზე დაბალია. მილის ანალოგია ამას ცხადს ხდის:

```text
   ├────────────── length of pipe = LATENCY (how long to traverse) ─────────────┤
   ╔══════════════════════════════════════════════════════════════════════════╗
   ║  width of pipe = BANDWIDTH (max capacity)                                  ║
   ║  water actually flowing = THROUGHPUT (real achieved rate ≤ bandwidth)      ║
   ╚══════════════════════════════════════════════════════════════════════════╝
```

კრიტიკულად, **უფრო ფართო მილი მას უფრო მოკლეს არ ხდის**: bandwidth-ის დამატება latency-ს არ ამცირებს. მსხვილ ტრანსატლანტიკურ არხს ისევ ~80 ms round-trip latency აქვს, ნაკარნახევი მანძილითა და სინათლის სიჩქარით — მის ქვემოთ ვერ ჩახვალთ ფულით. სწორედ ამიტომ latency და არა bandwidth განსაზღვრავს ინტერაქტიული აპლიკაციების შეგრძნებას: თითოეული round trip (DNS, TCP handshake, TLS, შემდეგ request) latency-ის გადასახადს იხდის და ისინი ჯამდება.

latency და throughput ურთიერთქმედებენ **Bandwidth-Delay Product-ის** (BDP = bandwidth × round-trip time) მეშვეობით, ეს არის მონაცემის რაოდენობა "გზაში", რომ მილი სავსე იყოს. მაღალი-bandwidth-ის, მაღალი-latency-ის "გრძელ მსხვილ ქსელზე" ისეთი პროტოკოლი, როგორიც TCP, რომელიც ACK-ებს ელოდება, მილს ვერ ავსებს, თუ მისი ფანჯარა BDP-ს მაინც არ უტოლდება — ასე რომ throughput საბოლოოდ *latency-ით შემოიფარგლება*, და არა bandwidth-ით. სწორედ ამიტომ ერთი TCP ნაკადი შორ მანძილზე ხშირად სუსტად მუშაობს სწრაფ არხზეც კი და ამიტომ ეხმარებიან პარალელიზმი, უფრო დიდი ფანჯრები და CDN-ები (რომლებიც მანძილს ჭრიან და მაშასადამე latency-ს).

## რატომ არის ეს მნიშვნელოვანი

ამ სამის აღრევა ერთ-ერთი ყველაზე გავრცელებული — და ყველაზე შედეგიანი — წარმადობის შეცდომაა: გუნდები მეტ bandwidth-ს ყიდულობენ იმის გამოსასწორებლად, რაც სინამდვილეში latency-ის პრობლემაა და გაუმჯობესებას ვერ ხედავენ. senior-ის შეხედულება ისაა, რომ **latency არის ფიზიკით (მანძილით) დაყენებული იატაკი**, რომელსაც არქიტექტურულად ესხმით თავს — სერვერები/CDN-ები მომხმარებლებთან ახლოს დააყენეთ, round trip-ები შეამცირეთ (კავშირის ხელახალი გამოყენება, HTTP/3, caching) და request-ები დააჯგუფეთ — ხოლო bandwidth ხშირად უბრალოდ დასამატებელია. BDP-ის გაგება ხსნის კონტრ-ინტუიციურ შედეგებს, როგორიც "სწრაფი" არხის მიერ ნელი ერთ-ნაკადიანი გადაცემა, სწორედ ისეთ მსჯელობას, რომელიც მოსალოდნელია, როცა მაღალი წარმადობის, გეოგრაფიულად განაწილებულ სისტემებს აპროექტებთ ან debug-ს უკეთებთ.

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები