Latency چیست؟

وقتی یک کاربر روی یک دکمه کلیک می‌کند، یک API درخواست می‌فرستد یا یک سرویس Microservice اطلاعاتی را از سرویس دیگری دریافت می‌کند، داده باید از یک نقطه شبکه به نقطه دیگری منتقل شود. فاصله جغرافیایی، مسیر شبکه، تجهیزات میانی، شلوغی شبکه و حتی نحوه طراحی Application می‌توانند باعث شوند این انتقال مقداری زمان ببرد.

این تأخیر را Network Latency می‌نامیم.

Latency یکی از مهم‌ترین شاخص‌های Performance در زیرساخت‌های مدرن است. یک شبکه ممکن است Bandwidth بسیار بالایی داشته باشد، اما اگر Latency آن زیاد باشد، Application همچنان کند و غیرپاسخ‌گو به نظر برسد. این مسئله به‌خصوص برای سرویس‌های Interactive، APIهای زنجیره‌ای، Databaseها، Microservices، VoIP، Gaming و سیستم‌های Distributed اهمیت زیادی دارد.

در این مقاله بررسی می‌کنیم Network Latency چیست، چگونه اندازه‌گیری می‌شود، RTT چه تفاوتی با Latency دارد، چه عواملی باعث افزایش تأخیر شبکه می‌شوند، تفاوت Latency با Bandwidth و Throughput چیست و چگونه می‌توان Latency را در معماری‌های Production کاهش داد.

Network Latency چیست؟

Network Latency به مدت زمانی گفته می‌شود که طول می‌کشد داده از یک نقطه شبکه به نقطه دیگری منتقل شود.

Latency معمولاً با Millisecond یا ms اندازه‌گیری می‌شود. هرچه این مقدار کمتر باشد، پاسخ شبکه سریع‌تر خواهد بود.

برای مثال، فرض کنید یک Application در تهران قرار دارد و کاربر درخواست خود را به Server دیگری در یک دیتاسنتر اروپایی ارسال می‌کند. Packet باید از چندین شبکه، Router و لینک ارتباطی عبور کند تا به مقصد برسد. این مسیر زمان مشخصی نیاز دارد.

بنابراین اگر یک سرویس از نظر Application بسیار سریع باشد اما Server آن در فاصله جغرافیایی زیادی از کاربران قرار گرفته باشد، بخشی از زمان پاسخ همچنان به دلیل Network Latency مصرف خواهد شد.

Cloudflare نیز Latency را زمان لازم برای عبور یک Packet از یک نقطه شبکه به نقطه دیگر تعریف می‌کند و فاصله جغرافیایی و تجهیزات شبکه را از عوامل مهم آن می‌داند. 

یک مثال ساده از Latency

فرض کنید کاربر یک درخواست به Server ارسال می‌کند:

Client
   │
   │ Request
   ↓
Network
   │
   ↓
Server

اگر انتقال Packet از Client به Server حدود ۵۰ میلی‌ثانیه طول بکشد، می‌توان گفت One-Way Latency تقریباً ۵۰ms است.

اما در بسیاری از سناریوهای واقعی، چیزی که اندازه‌گیری می‌کنیم Round Trip Time یا RTT است؛ یعنی مدت زمانی که درخواست به مقصد می‌رود و پاسخ به مبدأ بازمی‌گردد.

Client
   │
   │ 50 ms
   ↓
Server
   │
   │ 50 ms
   ↓
Client

RTT ≈ 100 ms

RTT معمولاً به عنوان یک شاخص عملی برای بررسی Latency شبکه استفاده می‌شود. 

RTT چیست؟

RTT یا Round Trip Time مدت زمانی است که یک Packet یا Request برای رفتن از مبدأ به مقصد و بازگشت پاسخ به مبدأ نیاز دارد.

برای مثال:

Client → Server = 40 ms
Server → Client = 40 ms

RTT ≈ 80 ms

ابزارهایی مانند ping معمولاً برای اندازه‌گیری تقریبی RTT استفاده می‌شوند. traceroute و mtr نیز می‌توانند برای بررسی مسیر و رفتار Latency در طول مسیر مفید باشند. 

البته RTT لزوماً دقیقاً دو برابر One-Way Latency نیست؛ مسیر رفت و برگشت ممکن است متفاوت باشد و شرایط شبکه نیز در طول زمان تغییر کند.

تفاوت Latency و RTT چیست؟

در محیط‌های عملی، RTT یکی از رایج‌ترین معیارهای قابل‌اندازه‌گیری برای ارزیابی Latency شبکه است، در حالی که TTFB علاوه بر شبکه، زمان پردازش Server را نیز در بر می‌گیرد. 

چه عواملی باعث Network Latency می‌شوند؟

Latency نتیجه یک عامل واحد نیست. معمولاً چندین نوع تأخیر در مسیر یک Packet جمع می‌شوند.

مهم‌ترین عوامل عبارت‌اند از:

• Distance یا فاصله جغرافیایی
• Propagation Delay
• Transmission Delay
• Processing Delay
• Queuing Delay
• تعداد Network Hopها
• Congestion
• نوع Transmission Medium
• Packet Loss و Retransmission
• Server Processing Time

۱. فاصله جغرافیایی

یکی از بنیادی‌ترین عوامل Latency، فاصله بین دو Endpoint است.

سیگنال در شبکه‌های فیبر نوری با سرعت بسیار بالایی حرکت می‌کند، اما این سرعت بی‌نهایت نیست. بنابراین هرچه فاصله بین Client و Server بیشتر باشد، حداقل تأخیر فیزیکی نیز بیشتر می‌شود.

به همین دلیل یک کاربر معمولاً به Server نزدیک‌تر، RTT کمتری خواهد داشت.

این محدودیت فیزیکی یکی از دلایل مهم استفاده از CDN و Edge Infrastructure است؛ زیرا می‌توان محتوا و بخشی از پردازش را به کاربران نزدیک‌تر کرد. 

۲. Network Hop چیست؟

هر بار که Packet از یک Router یا Network Node عبور می‌کند، یک Hop در مسیر ایجاد می‌شود.

برای مثال:

Client
  ↓
Router 1
  ↓
Router 2
  ↓
Router 3
  ↓
ISP
  ↓
Data Center
  ↓
Server

هر Node باید Packet را دریافت، پردازش و برای مقصد بعدی Forward کند. تعداد بیشتر Hopها می‌تواند به افزایش زمان کلی انتقال کمک کند. 

البته صرفاً زیاد بودن تعداد Hopها به معنی وجود مشکل نیست. کیفیت مسیر، نوع لینک، Congestion و رفتار تجهیزات نیز اهمیت دارند.

۳. Transmission Delay

Transmission Delay زمانی است که برای قرار دادن تمام بیت‌های یک Packet روی لینک ارتباطی نیاز است.

این مقدار به اندازه Packet و نرخ انتقال لینک وابسته است.

به صورت مفهومی:

Transmission Delay
≈ Packet Size / Link Rate

بنابراین اندازه Packet و ظرفیت لینک می‌توانند در این نوع تأخیر مؤثر باشند.

۴. Propagation Delay

Propagation Delay مدت زمانی است که سیگنال برای طی کردن مسیر فیزیکی بین دو نقطه نیاز دارد.

این نوع Delay بیشتر به فاصله و نوع Medium وابسته است.

برای مثال، Fiber، Copper، Wireless و Satellite رفتار یکسانی ندارند.

به همین دلیل حتی اگر یک لینک Bandwidth بسیار بالایی داشته باشد، فاصله فیزیکی همچنان یک محدودیت بنیادی برای Latency باقی می‌ماند. 

۵. Processing Delay

Routerها، Switchها، Firewallها و سایر تجهیزات شبکه باید Packetها را پردازش و Forward کنند.

این پردازش می‌تواند شامل مواردی مانند:

• بررسی Header
• Routing Lookup
• Firewall Rules
• NAT
• Packet Inspection
• Queue Management

باشد.

در شبکه‌های معمولی این تأخیر ممکن است بسیار کوچک باشد، اما در مسیرهای طولانی یا معماری‌هایی با تجهیزات و سرویس‌های متعدد، مجموع این تأخیرها اهمیت پیدا می‌کند.

۶. Queuing Delay و Network Congestion

یکی از مهم‌ترین عوامل افزایش Latency، Congestion یا شلوغی شبکه است.

وقتی Packetها سریع‌تر از ظرفیت پردازش یا انتقال یک لینک وارد شوند، در Queue قرار می‌گیرند.

Packets
 ↓ ↓ ↓ ↓ ↓
┌──────────────┐
│    Queue     │
│ ▪ ▪ ▪ ▪ ▪ ▪ │
└──────────────┘
       ↓
     Link

هرچه Queue طولانی‌تر شود، Packet مدت بیشتری منتظر می‌ماند و Latency افزایش پیدا می‌کند.

Cloudflare این تفاوت میان Latency در حالت Idle و Latency تحت Load را نیز مطرح می‌کند؛ رشد بیش از حد Queueها می‌تواند به پدیده‌ای مانند Bufferbloat منجر شود که باعث افزایش محسوس تأخیر در زمان بار شبکه می‌شود. 

Latency در حالت Idle و تحت Load

گاهی یک شبکه در تست ساده بسیار سریع به نظر می‌رسد، اما هنگام استفاده واقعی و افزایش Traffic، Latency به شکل قابل‌توجهی افزایش پیدا می‌کند.

برای مثال:

بنابراین فقط اندازه‌گیری Ping در شرایط Idle نمی‌تواند تمام کیفیت واقعی یک شبکه را نشان دهد.

Latency با Bandwidth چه تفاوتی دارد؟

یکی از رایج‌ترین اشتباهات این است که Bandwidth بالا را معادل Latency پایین بدانیم.

این دو معیار متفاوت هستند.

برای مثال یک لینک ۱Gbps می‌تواند Latency بیشتری از یک لینک ۱۰۰Mbps داشته باشد. ظرفیت انتقال داده و مدت زمان رسیدن Packet دو ویژگی متفاوت شبکه هستند. AWS نیز Bandwidth، Throughput، Latency، Jitter و Packet Loss را به عنوان شاخص‌های متفاوت Network Performance معرفی می‌کند. 

یک مثال ساده برای تفاوت Bandwidth و Latency

شبکه را مانند یک بزرگراه تصور کنید.

• Bandwidth شبیه تعداد خطوط بزرگراه است.
• Latency شبیه مدت زمان رسیدن خودرو از مبدأ به مقصد است.
• Throughput مقدار واقعی خودروهایی است که در یک بازه زمانی به مقصد می‌رسند.
• Congestion همان ترافیک بزرگراه است.

بنابراین ممکن است بزرگراه بسیار عریض باشد اما به دلیل فاصله زیاد، مسیر طولانی یا ترافیک، زمان رسیدن همچنان زیاد باشد.

Latency و Throughput

Throughput مقدار واقعی داده‌ای است که در یک بازه زمانی از شبکه عبور می‌کند.

ممکن است یک شبکه Bandwidth اسمی بسیار بالایی داشته باشد، اما به دلیل Latency، Packet Loss، Congestion یا محدودیت‌های دیگر، Throughput واقعی پایین‌تر باشد. 

این موضوع در انتقال فایل، Database Replication و ارتباط بین Data Centerها اهمیت ویژه‌ای پیدا می‌کند.

Jitter چیست؟

Jitter به تغییرات Latency در طول زمان گفته می‌شود.

فرض کنید Latency یک Connection به صورت زیر باشد:

20ms
21ms
19ms
20ms
22ms
21ms

این Connection رفتار نسبتاً پایدار دارد.

اما اگر مقادیر به شکل زیر تغییر کنند:

20ms
90ms
25ms
180ms
35ms
120ms

شبکه Jitter بالایی دارد.

Jitter برای Applicationهای Real-Time مانند Voice و Video، Gaming و برخی سیستم‌های Interactive اهمیت زیادی دارد. 

Packet Loss چیست و چه ارتباطی با Latency دارد؟

Packet Loss یعنی بخشی از Packetهای ارسال‌شده به مقصد نمی‌رسند.

Packet Loss می‌تواند به دلایلی مانند:

• Congestion
• مشکلات تجهیزات شبکه
• خرابی لینک
• مشکلات Wireless
• خطاهای نرم‌افزاری یا سخت‌افزاری

اتفاق بیفتد.

در پروتکل‌هایی مانند TCP، از دست رفتن Packet می‌تواند باعث Retransmission شود و در نتیجه زمان لازم برای تکمیل ارتباط افزایش پیدا کند. 

بنابراین ممکن است چیزی که کاربر به شکل «کند شدن شبکه» تجربه می‌کند، ترکیبی از Latency، Packet Loss و Retransmission باشد.

Latency در TCP

Latency در ارتباطات TCP اهمیت زیادی دارد، زیرا TCP برای برقراری Connection و تبادل داده به رفت‌وبرگشت پیام‌ها وابسته است.

در یک Connection جدید، TCP باید فرآیند Three-Way Handshake را انجام دهد:

Client                Server

  SYN  ────────────────→
       ←──────── SYN-ACK
  ACK  ────────────────→

وقتی RTT زیاد باشد، زمان لازم برای این رفت‌وبرگشت نیز افزایش پیدا می‌کند.

این مسئله به‌خصوص برای Applicationهایی که Connectionهای زیادی ایجاد می‌کنند اهمیت دارد. AWS نیز اشاره می‌کند که RTT بالا می‌تواند زمان TCP Three-Way Handshake را افزایش دهد و روی Responsiveness اثر بگذارد. 

Latency و TLS

در Connectionهای HTTPS علاوه بر TCP، فرآیند TLS نیز باید در نظر گرفته شود.

در صورتی که Connection جدید برای هر Request ایجاد شود، رفت‌وبرگشت‌های اضافی می‌توانند در شبکه‌های High-Latency اثر قابل‌توجهی داشته باشند.

به همین دلیل تکنیک‌هایی مانند:

• Connection Reuse
• Keep-Alive
• Persistent Connections
• HTTP/2
• HTTP/3

می‌توانند در شرایط مناسب به کاهش اثر Round Tripهای اضافی کمک کنند.

TTFB چیست و چه ارتباطی با Latency دارد؟

TTFB یا Time To First Byte مدت زمانی است که از ارسال Request تا دریافت اولین Byte از Response طول می‌کشد.

TTFB فقط Network Latency نیست؛ بلکه می‌تواند شامل زمان پردازش Server نیز باشد.

به صورت ساده:

TTFB
=
Network Delay
+
Server Processing
+
Response Network Delay

بنابراین اگر TTFB بالا باشد، نباید بلافاصله نتیجه بگیریم که مشکل شبکه است. ممکن است Application، Database یا Backend زمان زیادی برای تولید Response مصرف کرده باشد. AWS نیز TTFB را ترکیبی از زمان پردازش Server و زمان بازگشت Response در شبکه توصیف می‌کند. 

تفاوت Network Latency و Application Latency

فرض کنید کاربر یک API را صدا می‌زند:

Client
  ↓
Network
  ↓
API
  ↓
Database
  ↓
API
  ↓
Network
  ↓
Client

اگر API برای Query کردن Database پنج ثانیه منتظر بماند، ممکن است کاربر Latency بالایی تجربه کند؛ حتی اگر Network RTT فقط ۲۰ms باشد.

بنابراین در Performance Engineering باید میان این موارد تفکیک قائل شد:

• Network Latency
• Application Processing Time
• Database Latency
• Storage Latency
• External API Latency

گاهی چیزی که از دید کاربر «Latency شبکه» به نظر می‌رسد، در واقع یک Bottleneck در Application یا Database است.

چرا Latency در Microservices مهم است؟

در معماری Monolithic، بسیاری از Function Callها داخل یک Process انجام می‌شوند و هزینه Network Round Trip وجود ندارد.

اما در Microservices، یک Request ممکن است به چند سرویس مختلف وابسته باشد:

User
 ↓
API Gateway
 ↓
Auth Service
 ↓
Order Service
 ↓
Payment Service
 ↓
Inventory Service
 ↓
Database

اگر این سرویس‌ها روی Networkهای مختلف قرار داشته باشند، هر ارتباط می‌تواند Latency اضافه کند.

در چنین شرایطی حتی چند میلی‌ثانیه Latency در هر Hop، در یک Chain طولانی می‌تواند به زمان قابل‌توجهی تبدیل شود.

Sequential و Parallel Requests

نحوه طراحی Application نیز روی اثر Latency تأثیر دارد.

فرض کنید یک Request باید به سه سرویس متوالی مراجعه کند:

Service A
   ↓ 20ms
Service B
   ↓ 20ms
Service C
   ↓ 20ms

در یک Workflow کاملاً Sequential، بخشی از این تأخیرها روی هم جمع می‌شوند.

اما اگر چند Request مستقل بتوانند به صورت Parallel اجرا شوند، زمان کلی ممکن است بیشتر به کندترین مسیر وابسته باشد.

این موضوع در طراحی API و Microservices اهمیت زیادی دارد.

Database و Network Latency

Databaseهای Distributed و سیستم‌های Key/Value نیز می‌توانند به Latency شبکه حساس باشند.

برای مثال اگر Application و Database در دو Data Center مختلف قرار داشته باشند، هر Query یا Transaction ممکن است Network Round Trip قابل‌توجهی ایجاد کند.

این موضوع برای:

• Distributed Database
• Replication
• Consensus
• Distributed Cache
• Microservices
• Transactional Systems

اهمیت زیادی دارد.

AWS نیز اشاره می‌کند که Databaseها و Key/Value Storeها از Workloadهایی هستند که می‌توانند به افزایش Network Latency حساس باشند. 

Latency بین Data Centerها

در معماری Multi-DC، انتخاب محل Data Center اهمیت بسیار زیادی دارد.

برای مثال:

Application DC1
      │
      │ High Latency
      ↓
Database DC2

ممکن است Application از نظر CPU و RAM کاملاً سالم باشد، اما ارتباط مداوم با Database دور باعث کاهش Performance شود.

به همین دلیل در طراحی Multi-DC باید مواردی مانند:

• Distance
• RTT
• Packet Loss
• Bandwidth
• Replication Model
• Consistency Requirements
• Failure Scenario

همزمان بررسی شوند.

Latency و CDN

یکی از روش‌های مهم کاهش Latency برای کاربران، استفاده از CDN یا Content Delivery Network است.

در یک معماری سنتی ممکن است همه کاربران به یک Origin Server متصل شوند:

Users
  ↓
Internet
  ↓
Origin Data Center

اما CDN می‌تواند محتوا را در نقاط مختلف شبکه نزدیک‌تر به کاربران Cache کند:

              ┌─ Edge ─ User A
Origin ─ CDN ─┼─ Edge ─ User B
              └─ Edge ─ User C

در این حالت برای محتوای Cacheable، کاربر ممکن است به یک Edge نزدیک‌تر متصل شود و RTT کاهش پیدا کند. CDNها همچنین می‌توانند با بهینه‌سازی مسیر و کاهش فاصله بین User و Content، Latency را کاهش دهند. 

برای آشنایی بیشتر با این موضوع می‌توانید مقاله CDN چیست؟ را مطالعه کنید.

چگونه Network Latency را اندازه‌گیری کنیم؟

برای بررسی Latency ابزارهای مختلفی وجود دارد.

Ping

ساده‌ترین ابزار، ping است.

ping example.com

Ping معمولاً RTT را برای Packetهای ICMP گزارش می‌کند.

اما یک نکته مهم وجود دارد: Ping لزوماً عملکرد واقعی Application را نشان نمی‌دهد.

ممکن است ICMP سریع باشد اما HTTPS یا API به دلیل پردازش Server، Firewall، TLS یا سایر عوامل کندتر عمل کند.

Traceroute

Traceroute برای مشاهده مسیر تقریبی Packet و Hopهای بین مبدأ و مقصد مفید است.

traceroute example.com

در Linux و macOS معمولاً از traceroute و در Windows از tracert استفاده می‌شود.

MTR

MTR یا My Traceroute ترکیبی از ایده‌های Ping و Traceroute است و برای بررسی مداوم مسیر، RTT و Packet Loss در Hopهای مختلف کاربرد دارد.

MTR می‌تواند در تشخیص مشکلات Path و بررسی رفتار شبکه تحت شرایط مختلف بسیار مفید باشد. 

چرا یک Hop با Latency بالا همیشه مشکل‌دار نیست؟

این نکته در تحلیل MTR و Traceroute بسیار مهم است.

ممکن است یک Router در میانه مسیر به ICMP یا Traceroute با Priority پایین پاسخ دهد و Latency زیادی نشان دهد، اما Packetهای واقعی را بدون مشکل Forward کند.

بنابراین نباید صرفاً با دیدن یک عدد بزرگ در یک Hop نتیجه گرفت که همان Router عامل اصلی مشکل است.

باید بررسی کرد آیا افزایش Latency یا Packet Loss در Hopهای بعدی نیز ادامه پیدا می‌کند یا خیر.

چه Latencyای خوب است؟

یک عدد ثابت برای «Latency خوب» وجود ندارد؛ زیرا مقدار قابل‌قبول به نوع Application و مسیر ارتباطی بستگی دارد.

برای مثال یک سیستم Interactive ممکن است نسبت به یک Backup Job حساسیت بسیار بیشتری به Latency داشته باشد.

به صورت کلی:

برای برخی کاربردهای عمومی، RTT زیر 100ms معمولاً تجربه مناسبی ایجاد می‌کند، اما این عدد یک استاندارد جهانی برای تمام Applicationها نیست و باید بر اساس نیاز واقعی Workload تعیین شود. 

چگونه Network Latency را کاهش دهیم؟

کاهش Latency معمولاً با یک تغییر ساده انجام نمی‌شود. باید مشخص شود تأخیر دقیقاً در کدام قسمت مسیر ایجاد شده است.

روش‌های رایج عبارت‌اند از:

• نزدیک کردن Server به کاربران
• استفاده از CDN
• کاهش Network Hopهای غیرضروری
• انتخاب مسیرهای Network بهتر
• کاهش Congestion
• استفاده از Connection Reuse
• بهینه‌سازی API Architecture
• کاهش Round Tripهای غیرضروری
• قرار دادن Application و Database در موقعیت مناسب
• استفاده از Edge Computing در صورت نیاز
• رفع Packet Loss
• بهینه‌سازی Network Infrastructure

۱. نزدیک کردن سرویس به کاربران

اگر کاربران اصلی یک سرویس در یک منطقه جغرافیایی خاص هستند، قرار دادن Application یا Edge نزدیک‌تر به آن‌ها می‌تواند RTT را کاهش دهد.

در معماری‌های بزرگ ممکن است از چند Data Center یا Edge Location استفاده شود.

۲. استفاده از CDN

برای Static Content و برخی Workloadهای مناسب، CDN می‌تواند یکی از مؤثرترین راهکارهای کاهش فاصله شبکه باشد.

تصاویر، فایل‌های CSS، JavaScript و سایر Assetهای Cacheable می‌توانند از Edge نزدیک‌تر به کاربر ارائه شوند.

۳. کاهش Round Tripهای غیرضروری

اگر یک صفحه برای دریافت اطلاعات به تعداد زیادی Request وابسته باشد، هر Round Trip می‌تواند روی زمان نهایی اثر بگذارد.

طراحی API مناسب، Connection Reuse، Caching و ترکیب منطقی Requestها می‌تواند تعداد Round Tripهای غیرضروری را کاهش دهد.

۴. نزدیک کردن Application و Database

اگر Application مرتباً با Database ارتباط دارد، فاصله زیاد میان این دو می‌تواند بسیار پرهزینه باشد.

در بسیاری از معماری‌ها بهتر است Application و Database در یک Data Center یا Region مناسب قرار داشته باشند؛ مگر اینکه الزامات معماری مانند DR یا Multi-Region دلیل مشخصی برای جداسازی آن‌ها ایجاد کند.

۵. استفاده صحیح از Caching

Cache می‌تواند تعداد Requestهای لازم برای رسیدن به Origin یا Database را کاهش دهد.

در نتیجه به جای اینکه هر Request مسیر زیر را طی کند:

Client
 ↓
API
 ↓
Database
 ↓
API
 ↓
Client

ممکن است پاسخ از Cache ارائه شود:

Client
 ↓
Cache
 ↓
Client

این موضوع علاوه بر کاهش Load، می‌تواند Latency را نیز کاهش دهد.

۶. کاهش Packet Loss

اگر Packetها از دست بروند، مخصوصاً در TCP، Retransmission می‌تواند زمان انتقال را افزایش دهد.

بنابراین در کنار Latency باید Packet Loss نیز مانیتور شود.

۷. بهینه‌سازی مسیر شبکه

گاهی مشکل نه در Server و نه در Application، بلکه در Path شبکه است.

بررسی Route، BGP، ISP، Peering، Transit Provider و مسیر بین Data Centerها می‌تواند در برخی پروژه‌ها تفاوت قابل‌توجهی ایجاد کند.

Latency در Cloud

در Cloud Architecture انتخاب Region و Availability Zone اهمیت زیادی دارد.

اگر دو Component که دائماً با یکدیگر ارتباط دارند در موقعیت‌های نامناسب قرار بگیرند، Network Latency می‌تواند تبدیل به Bottleneck شود.

بنابراین هنگام طراحی Cloud Infrastructure باید فقط CPU و RAM و Storage را بررسی نکرد؛ Network Topology نیز باید بخشی از طراحی باشد.

Latency و Kubernetes

در Kubernetes نیز Network Latency می‌تواند در چند سطح ایجاد شود:

• Client تا Load Balancer
• Load Balancer تا Ingress
• Ingress تا Service
• Service تا Pod
• Pod تا Pod
• Pod تا Database
• Cluster تا External Service

در یک Microservices Architecture بزرگ، این مسیرها می‌توانند بسیار پیچیده شوند.

به همین دلیل Monitoring شبکه و Application، Distributed Tracing و مشاهده Dependencyها برای پیدا کردن Latency Bottleneck اهمیت پیدا می‌کنند.

در معماری‌های Kubernetes می‌توان از ابزارهایی مانند Prometheus، Grafana و OpenTelemetry برای مشاهده شاخص‌های مرتبط با Performance استفاده کرد.

برای آشنایی بیشتر با Kubernetes می‌توانید مقاله کوبرنتیس چیست؟ و برای Observability مقاله OpenTelemetry چیست؟ را مطالعه کنید.

Latency و Observability

در Production، یک عدد Average Latency به تنهایی کافی نیست.

فرض کنید:

Average Latency = 50ms

ممکن است این مقدار خوب به نظر برسد، اما اگر بخشی از Requestها چنین باشند:

P50 = 30ms
P95 = 70ms
P99 = 900ms

ممکن است ۱ درصد از کاربران تجربه بسیار بدی داشته باشند.

به همین دلیل در Observability بهتر است Latency را با Percentileهایی مانند:

• P50
• P90
• P95
• P99
• P99.9

بررسی کنیم.

این رویکرد برای سیستم‌های Enterprise و Distributed اهمیت زیادی دارد.

Latency Budget چیست؟

یکی از مفاهیم مفید در Performance Engineering، تعیین Latency Budget است.

فرض کنید هدف Application این باشد که Response را در کمتر از ۲۰۰ms ارائه کند.

می‌توان این زمان را میان اجزای مختلف تقسیم کرد:

این کار کمک می‌کند تیم به جای اینکه صرفاً بگوید «سایت کند است»، مشخص کند هر بخش چه سهمی از زمان پاسخ را مصرف می‌کند.

Latency و SRE

Latency یکی از مهم‌ترین شاخص‌های قابل استفاده در SRE است.

برای یک سرویس می‌توان SLIهایی مانند:

• API Response Latency
• Request Duration
• Network RTT
• Database Latency
• External Dependency Latency

تعریف کرد.

سپس می‌توان بر اساس آن‌ها SLO تعیین کرد و در صورت عبور Latency از Thresholdهای مشخص، Alert ایجاد کرد.

آیا افزایش Bandwidth مشکل Latency را حل می‌کند؟

نه همیشه.

اگر مشکل اصلی فاصله جغرافیایی یا طولانی بودن مسیر باشد، افزایش Bandwidth الزاماً Latency را کاهش نمی‌دهد.

برای مثال ممکن است یک لینک ۱۰Gbps داشته باشید، اما Server در فاصله بسیار زیادی از کاربران قرار داشته باشد.

در چنین شرایطی باید ابتدا علت اصلی Latency شناسایی شود.

آیا افزایش Server CPU می‌تواند Latency شبکه را کاهش دهد؟

اگر Bottleneck واقعاً شبکه باشد، افزایش CPU معمولاً Network Latency را کاهش نمی‌دهد.

اما اگر چیزی که به عنوان Latency مشاهده می‌شود در واقع Server Processing Time باشد، افزایش منابع یا بهینه‌سازی Application می‌تواند زمان پاسخ را کاهش دهد.

این دقیقاً دلیل اهمیت تفکیک Network Latency از Application Latency است.

چک‌لیست بررسی Latency در Production

• RTT بین Client و Server اندازه‌گیری شود.
• Latency در زمان Idle و تحت Load مقایسه شود.
• Packet Loss بررسی شود.
• Jitter اندازه‌گیری شود.
• مسیر شبکه با Traceroute یا MTR بررسی شود.
• تعداد Hopها بررسی شود.
• Congestion و Queueing بررسی شود.
• Latency بین Application و Database اندازه‌گیری شود.
• TTFB از Network RTT تفکیک شود.
• P50، P95 و P99 بررسی شوند.
• وابستگی‌های External API بررسی شوند.
• CDN و Edge Location مناسب بررسی شود.
• Application و Database از نظر جغرافیایی و Network Topology بررسی شوند.
• Latency در زمان Peak Traffic نیز اندازه‌گیری شود.
• برای سرویس‌های حیاتی Alert و SLO تعریف شود.

جمع‌بندی

Network Latency مدت زمانی است که داده برای عبور از یک نقطه شبکه به نقطه دیگر نیاز دارد و یکی از مهم‌ترین شاخص‌های Performance شبکه و Application است.

Latency به عواملی مانند فاصله جغرافیایی، مسیر شبکه، تعداد Hopها، نوع لینک، Processing تجهیزات، Congestion، Queueing و Packet Loss وابسته است.

همچنین باید توجه داشت که Latency با Bandwidth، Throughput، Jitter و Packet Loss یکسان نیست. یک شبکه می‌تواند Bandwidth بسیار بالایی داشته باشد اما همچنان Latency زیادی داشته باشد.

در معماری‌های مدرن، Latency فقط یک مسئله Network Engineering نیست. طراحی Application، Microservices، Database، Kubernetes، CDN، Multi-DC و Cloud نیز می‌تواند روی Latency نهایی اثر بگذارد.

برای کاهش Latency نیز باید ابتدا Bottleneck واقعی شناسایی شود. نزدیک کردن سرویس به کاربران، استفاده از CDN، کاهش Round Tripهای غیرضروری، بهینه‌سازی مسیر شبکه، کاهش Packet Loss، استفاده از Connection Reuse و طراحی صحیح Application و Database از مهم‌ترین راهکارها هستند.

مدیریت و بهینه‌سازی Network Performance

در زیرساخت‌های Production، کاهش Latency صرفاً با افزایش منابع Server انجام نمی‌شود. باید مسیر کامل ارتباط، از کاربر تا Application و Database، بررسی و مانیتور شود.

آلتیمیت کلاد می‌تواند در طراحی و بهینه‌سازی زیرساخت‌های شبکه، Monitoring، High Availability، Multi-DC، Kubernetes، CDN، Load Balancing و معماری Performance-Oriented به سازمان‌ها کمک کند.

برای بررسی معماری زیرساخت و شناسایی Bottleneckهای Performance، با آلتیمیت کلاد در ارتباط باشید.