نرخ انتقال مفید مورد نیاز پنجره تحویل خود را محاسبه کنید، سپس مسیر کامل را اندازه‌گیری کنید. ظرفیت پورت، زمان رفت‌وبرگشت، رفتار TCP، ذخیره‌سازی و پردازش برنامه همگی بر نتیجه تأثیر می‌گذارند. از آزمایش‌های کنترل‌شده با همزمانی واقع‌گرایانه استفاده کنید و آن‌ها را از طریق برنامه واقعی تکرار کنید، پیش از انتخاب یک سطح شبکه.
پنجره تحویل را به نرخ تبدیل کنید
با مقداری داده مفید برنامه و زمان موجود برای تحویل آن شروع کنید. با استفاده از واحدهای اعشاری، انتقال 2 TB در دو ساعت تقریباً به 278 مگابایت بر ثانیه بار مفید، یا 2.22 Gbps، نیاز دارد، پیش از در نظر گرفتن سربار پروتکل و وقفه‌ها. این محاسبه یک مثال برنامه‌ریزی است، نه یک نتیجه سرویس اندازه‌گیری‌شده.
انتقال‌هایی را که همپوشانی دارند شامل کنید. یک خروجی زمان‌بندی‌شده، دانلودهای مشتری و بارگذاری‌های پشتیبان می‌توانند منابع را به اشتراک بگذارند، حتی اگر مجموع ماهانه آن‌ها متعادل به نظر برسد. یک مدل دوره پرترافیک بنویسید، نه فقط یک میانگین ماهانه. مشخص کنید کدام جهت اهمیت دارد و آیا یک انتقال ناموفق باید از ابتدا شروع شود یا می‌تواند ادامه یابد؛ آن رفتار بر مقدار کاری که سیستم انجام می‌دهد تأثیر می‌گذارد.
ظرفیت پورت را از توان عبوری مفید جدا نگه دارید
یک پورت سرور ظرفیت یک پیوند را توصیف می‌کند. توان عبوری مفید داده‌ای را توصیف می‌کند که برنامه شما در یک بازه مشاهده‌شده تحویل می‌دهد. رمزنگاری، قالب‌بندی پروتکل، ارسال مجدد، فعالیت ذخیره‌سازی و کار در گیرنده بخش‌هایی از آن مسیر را اشغال می‌کنند. بنابراین یک پورت 10 Gbps فهرست‌شده اثبات نمی‌کند که یک برنامه به‌طور پیوسته 10 Gbps بار مفید را تحویل خواهد داد.
IETF RFC 6349 به‌طور خاص آزمایش مسیر شبکه را از بررسی عملکرد TCP متمایز می‌کند. از این تفکیک در تشخیص خود استفاده کنید. ابتدا تأیید کنید که نقاط پایانی و مسیر مناسب هستند، سپس انتقال و برنامه را بررسی کنید. افزایش پورت خریداری‌شده گیرنده‌ای را که داده را کند می‌نویسد یا برنامه‌ای که یک درخواست را در یک زمان پردازش می‌کند اصلاح نمی‌کند.
درک کنید چرا زمان رفت‌وبرگشت اهمیت دارد
TCP کنترل می‌کند چه مقدار داده می‌تواند در حال پرواز باقی بماند تا زمانی که تأییدها بازگردند. حاصل‌ضرب پهنای باند-تأخیر مقیاس مفیدی برای این کار ارائه می‌دهد: نرخ ضربدر زمان رفت‌وبرگشت. یک مسیر فرضی 10 Gbps با 40 میلی‌ثانیه تأخیر رفت‌وبرگشت تقریباً 50 مگابایت در حال پرواز را نشان می‌دهد. این محاسبه توضیح می‌دهد چرا تأخیر و رفتار انتقال به برنامه‌ریزی سرعت بالا تعلق دارند.
نتیجه دستوری برای اعمال یک تنظیم دلخواه سوکت نیست. سیستم‌عامل‌ها، کنترل ازدحام، پنجره‌های مذاکره‌شده و مسیر واقعی بر رفتار تأثیر می‌گذارند. مستندات نرم‌افزار فعلی را تأیید کنید و اندازه‌گیری‌ها را قبل از تنظیم دقیق بررسی کنید. اتصالات موازی بیشتر ممکن است در برخی شرایط توان عبوری کل را بهبود بخشد، اما می‌تواند رفتار انتقال فردی که برنامه شما به آن وابسته است را نیز پنهان کند.
یک ماتریس آزمایش کنترل‌شده بسازید
فقط از نقاط پایانی که مالک آن‌ها هستید یا مجاز به آزمایش آن‌ها هستید استفاده کنید. پنجره و نرخ آزمایش را توافق کنید تا تمرین سرویس عادی را مختل نکند. ابزارهایی مانند iperf3 جهت، مدت و جریان‌های موازی قابل تنظیم را فراهم می‌کنند؛ مستندات رسمی آن کنترل‌ها را تعریف می‌کند. نسخه، نقاط پایانی، زمینه مسیر و تنظیمات را همراه با نتیجه ثبت کنید تا اپراتور دیگری بتواند آن را بازتولید کند.
با یک جریان واحد شروع کنید، سپس همزمانی نمونه را اضافه کنید. اگر برنامه به هر دو جهت وابسته است، هر دو جهت را اجرا کنید. این ماتریس نمونه سؤالاتی را جدا می‌کند که یک نتیجه سرصفحه‌ای واحد آن‌ها را با هم مخلوط می‌کرد. نتایج خام را زمانی که آدرس‌های داخلی یا جزئیات عملیاتی را افشا می‌کنند به‌صورت خصوصی نگه دارید و فقط اندازه‌گیری‌های مورد نیاز برای تصمیم را منتشر کنید.
| آزمایش | چه چیزی را بررسی می‌کند | چه چیزی را اثبات نمی‌کند |
|---|---|---|
| یک جریان انتقال | رفتار مسیر تک‌جریان | تحویل تجمعی برنامه |
| چندین جریان موازی | همزمانی و محدودیت‌های تجمعی | نرخ انتقال یک مشتری |
| انتقال برنامه | ذخیره‌سازی، پروتکل و نرم‌افزار با هم | عملکرد برای هر مجموعه داده |
| تکرار دوره پرترافیک | تغییر تحت فعالیت واقع‌گرایانه | یک تضمین توان عبوری دائمی |
در طول آزمایش به نقاط پایانی نگاه کنید
مصرف CPU، فشار حافظه، فعالیت ذخیره‌سازی و شمارنده‌های خطا را در هر دو سر ثبت کنید. یک نتیجه انتقال بدون مشاهدات نقطه پایانی ممکن است محدودیت واقعی را نامرئی بگذارد. بررسی کنید که آیا یک فرایند یا CPU اشباع شده در حالی که دیگران بیکار هستند. از تغییر چندین تنظیم به‌طور همزمان خودداری کنید، زیرا شناسایی اینکه کدام تنظیم کمک کرده را دشوار می‌کند.
یک آزمایش مبتنی بر حافظه را از آزمایشی که داده واقعی را می‌خواند و می‌نویسد جدا کنید. اولی می‌تواند به بررسی مسیر انتقال کمک کند؛ دومی بیشتر کار برنامه را منعکس می‌کند. اگر نتایج به‌شدت متفاوت باشند، ذخیره‌سازی و پردازش را بررسی کنید، نه اینکه رقم مبتنی بر حافظه را به‌عنوان یک وعده تحویل در نظر بگیرید. هر دو اندازه‌گیری زمانی که دامنه آن‌ها روشن باشد می‌توانند مفید باشند.
برنامه را با بارهای واقع‌گرایانه آزمایش کنید
یک خروجی HTTP، جریان تکرار رمزنگاری‌شده و یک نشست انتقال فایل الگوهای پردازش متفاوتی دارند. از اندازه‌های فایل، نرخ درخواست و تنظیمات رمزنگاری نمونه استفاده کنید. زمانی که کاربر منتظر آن مرحله است، زمان صرف‌شده برای آماده‌سازی داده قبل از ارسال اولین بایت را شامل کنید. تأخیر اولین پاسخ را از زمان تکمیل متمایز کنید، نه اینکه یکی را به‌عنوان دیگری گزارش دهید.
آزمایش را در بازه‌های کافی تکرار کنید تا تغییر را ببینید، و یک خط پایه قبل از تغییر پیکربندی نگه دارید. برای خروجی فرضی 2 TB، زمان تکمیل واقعی را با پنجره دو ساعته مقایسه کنید و حاشیه‌ای برای وقفه‌ها بگذارید. یک بهبود را در برابر گلوگاه مشاهده‌شده انتخاب کنید، نه اینکه ظرفیت پورت را بدون دلیل چند برابر کنید.
از نتیجه برای انتخاب یک پیکربندی استفاده کنید
خروجی مفید یک نیاز منابع با شواهد است: نرخ بار مفید اندازه‌گیری‌شده، زمان تکمیل قابل قبول، همزمانی مورد انتظار و یک مرحله محدودکننده شناخته‌شده. انواع شبکه SwissOctet را با آن نیاز مقایسه کنید، از جمله سهمیه ترافیک و مشخصات CPU و ذخیره‌سازی. مکان به‌تنهایی مسیر یا تأخیر سرتاسری به هر گیرنده را تعیین نمی‌کند.
رویه آزمایش را پس از استقرار نگه دارید. زمانی که مجموعه داده‌ها رشد می‌کنند، نرم‌افزار تغییر می‌کند یا کاربران به شبکه‌های متفاوتی منتقل می‌شوند، از آن دوباره استفاده کنید. یک خط پایه قابل تکرار تشخیص یک حادثه عملکردی را آسان‌تر می‌کند و دلیل محکم‌تری برای تغییر یک پیکربندی فراهم می‌کند تا یک آزمایش سرعت منفرد یا یک حداکثر تبلیغ‌شده.
چک‌لیست عملی شما.
- نرخ بار مفید را از حجم و مهلت محاسبه کنید.
- انتقال‌های همپوشان و جهت را مدل کنید.
- نقاط پایانی آزمایش مجاز و محدودیت‌ها را توافق کنید.
- یک جریان، همزمانی و آزمایش‌های برنامه را مقایسه کنید.
- در طول آزمایش هر دو نقطه پایانی را مشاهده کنید.
- یک خط پایه قابل تکرار و حاشیه مفید را حفظ کنید.
جزئیاتی که اهمیت دارند.
آیا یک پنجره TCP بزرگ‌تر همیشه یک انتقال کند را اصلاح می‌کند؟+
خیر. ابتدا مسیر و نقاط پایانی را تشخیص دهید. ذخیره‌سازی، CPU، افت و رفتار برنامه می‌توانند غالب باشند، و تنظیم دقیق انتقال باید با سیستم واقعی سازگار باشد.
چرا یک جریان واحد و چندین جریان را آزمایش کنیم؟+
آن‌ها به سؤالات متفاوتی پاسخ می‌دهند. ظرفیت تجمعی می‌تواند بالاتر از نرخ یک انتقال باشد؛ همزمانی برنامه تعیین می‌کند کدام نتیجه اهمیت دارد.
آیا می‌توانم یک آزمایش ظرفیت را علیه هر سرور عمومی اجرا کنم؟+
از نقاط پایانی که کنترل می‌کنید یا مجوز آزمایش آن‌ها را دارید استفاده کنید. مدت، نرخ و زمان‌بندی را توافق کنید تا اندازه‌گیری سرویس‌های نامرتبط را مختل نکند.
به منبع بروید.
این منابع از مفاهیم فنی این راهنما پشتیبانی می‌کنند. پیش از تغییر یک سیستم تولیدی، مستندات جاری را دنبال کنید.
- IETF RFC 6349: چارچوبی برای آزمایش توان عبوری TCP datatracker.ietf.org
- ESnet: فراخوانی iperf3 software.es.net
راهنمایی تحریریه توسط SwissOctet. مثال‌ها نمایشی هستند. مشخصات خدمات، گزینه‌های موجود و شرایط قراردادی باید جداگانه تأیید شوند.