تفاوت ترافیک و پهنای باند سرور
سرعت لحظه‌ای در برابر حجم مصرف‌شده

پهنای باند، سرعت پورت و throughput یکی نیستند

پهنای باند یا سقف پورت ظرفیت نرخ انتقال را با bit per second بیان می‌کند؛ برای نمونه Mbps یعنی میلیون bit در ثانیه. throughput سرعت مفیدی است که برنامه در عمل می‌بیند و می‌تواند به مسیر اینترنت، latency، congestion، پروتکل، CPU، دیسک، تعداد اتصال‌ها و مقصد محدود شود. بنابراین عدد اسمی پورت، سرعت تضمین‌شده دانلود از هر سایت نیست.

اعداد ابزارهای انتقال فایل ممکن است بر حسب MB/s باشند، در حالی که پورت با Mbps معرفی می‌شود؛ هر byte هشت bit دارد، اما سربار پروتکل نیز وجود دارد. مقایسه باید با واحد یکسان و در چند زمان و چند مقصد انجام شود. تست تک‌لحظه‌ای به‌تنهایی ظرفیت موردنیاز یک سرویس را تعیین نمی‌کند.

ترافیک چگونه از نرخ به حجم تبدیل می‌شود؟

ترافیک حاصل جمع داده منتقل‌شده در زمان است. اگر برنامه مدت طولانی با نرخ بالا کار کند، حتی بدون رسیدن به سقف پورت می‌تواند حجم ماهانه زیادی مصرف کند. وب‌سایت، backup خارج از سرور، update سیستم، replication، ویدئو و دانلود هرکدام الگوی متفاوتی دارند.

در رفتار فعلی این پنل، مصرف ورودی و خروجی گزارش‌شده برای VM با هم در total محاسبه می‌شوند. عدد نمایش‌داده‌شده یک شمارنده تجمعی دوره است، نه سرعت همان لحظه. برای برآورد، حجم واقعی log/CDN یا آزمایش workload را مبنا قرار دهید و برای رشد و retryها حاشیه در نظر بگیرید.

اندازه‌گیری ۳۰ ثانیه‌ای پنل دقیقاً چه می‌کند؟

سرور برنامه هر ۳۰ ثانیه job پایش را زمان‌بندی می‌کند. برای VPSهای فعال، resource metering در Hyper-V فعال و گزارش Measure-VM خوانده می‌شود. اختلاف شمارنده با snapshot قبلی به مصرف افزوده و داده‌ها در traffic_snapshots و جمع روزانه traffic_daily ثبت می‌شوند؛ شمارنده کل سرویس نیز به‌روزرسانی می‌شود.

این فاصله به معنی قبض‌کردن «بسته‌های ۳۰ ثانیه‌ای» یا نمایش کاملاً real-time نیست؛ اجرای فرمان و ثبت داده زمان می‌برد و نرخ نمودار از اختلاف دو نمونه برآورد می‌شود. ریست‌شدن شمارنده Hyper-V نیز در منطق delta در نظر گرفته می‌شود. برای تصمیم عملیاتی، روند چند نمونه و جمع روزانه قابل‌اتکاتر از یک نقطه نمودار است.

پس از رسیدن به traffic_limit_gb چه رخ می‌دهد؟

سقف حجمی هر سرویس در فیلد traffic_limit_gb نگهداری می‌شود. وقتی مصرف تجمعی به سقف برسد یا از آن عبور کند و سرویس هنوز محدود نشده باشد، پنل با Set-VMNetworkAdapter -MaximumBandwidth سقف نرخ adapter مجازی را به مقدار throttle تنظیم‌شده کاهش می‌دهد و وضعیت محدودشدن را ثبت می‌کند. سرویس صرفاً به دلیل تمام‌شدن ترافیک حذف نمی‌شود.

سرعت throttle و سرعت عادی از تنظیمات مدیریتی می‌آیند؛ بنابراین این صفحه عدد ثابتی وعده نمی‌دهد. اعلان پنل وضعیت را به کاربر گزارش می‌کند. اثر نهایی روی برنامه به workload بستگی دارد: صفحه کوچک ممکن است هنوز باز شود، اما backup، دانلود یا API پرترافیک کندتر می‌شوند.

ریست ماهانه و ترافیک اضافه چگونه عمل می‌کنند؟

هر سرویس یک traffic_reset_day دارد. job پایش در آن روز، در صورتی که مصرف دوره مثبت باشد و همان روز قبلاً reset نشده باشد، شمارنده مصرف را صفر می‌کند. اگر adapter به علت اتمام ترافیک محدود بوده است، پنل محدودیت را برمی‌دارد و رخداد reset را ثبت می‌کند. «ماهانه» در اینجا به روز تنظیم‌شده سرویس وابسته است، نه الزاماً اول ماه تقویمی.

خرید موفق ترافیک اضافه، مقدار خریداری‌شده را به سقف سرویس می‌افزاید. اگر سرویس محدود باشد و مصرف فعلی زیر سقف جدید قرار بگیرد، رفع throttle آغاز می‌شود. مقدارهای قابل خرید و قیمت از تنظیمات/فرم جاری تعیین می‌شوند؛ برای همین قبل از تصمیم، اطلاعات زنده پنل مرجع است.

چطور ترافیک موردنیاز را تخمین بزنیم و کم کنیم؟

از داده واقعی شروع کنید: مجموع responseهای وب، فایل دانلودی، backup خروجی، update، replication و ترافیک ورودی را در یک هفته عادی و یک بازه اوج اندازه بگیرید. سپس فصل فروش، انتشار نسخه و رشد کاربران را لحاظ کنید. ضرب ساده تعداد بازدید در اندازه صفحه مفید است، اما cache hit، bot، retry و upload را جا می‌اندازد.

• فایل‌های ثابت را cache و فشرده کنید و logهای حجیم را با retention روشن نگه دارید.
• backup را incremental و زمان‌بندی کنید، اما برای صرفه‌جویی آن را روی همان VPS حبس نکنید.
• مصرف روزانه و درصد سقف را پایش و پیش از نزدیک‌شدن به حد، درباره افزایش ظرفیت تصمیم بگیرید.
• ترافیک غیرعادی را از bot، compromise یا loop برنامه جدا کنید؛ فقط خرید حجم بیشتر درمان علت نیست.