قطع شدن VPN هنگام بارگذاری‌های بزرگ: نخست صف را بخوانید
صف بالادستی اشباع‌شده ترافیک کنترل را هم به اندازهٔ برنامه‌ها به تأخیر می‌اندازد. رفتار در حالت بی‌کار و زیر بار را مقایسه کنید، سپس یک چیز را تغییر دهید و آزمون را تکرار کنید.
تونل تمام روز پایدار است و بعد هر وقت بارگذاری بزرگی شروع می‌شود قطع می‌شود. درخواست‌های تعاملی نخست متوقف می‌شوند، کلاینت پایان مهلت را گزارش می‌کند و اتصال وقتی انتقال تمام شود برمی‌گردد. این الگو به صف‌شدن و پردازش اشاره دارد، نه به از کار افتادن سرور دوردست، چون به سرور هرگز فرصت داده نشد که به‌موقع پاسخ دهد. کار این است که آن را زیر بار کنترل‌شده بازتولید کنید و شمارنده‌های درست را بخوانید.
در هر اجرا یک متغیر را تغییر دهید و نقطهٔ پایانی را ثابت نگه دارید.
مقایسهٔ بار قابل تکرار بسازید
وقتی پیوند بی‌کار است یک خط پایه ثبت کنید: زمان رفت‌وبرگشت، چند درخواست برنامه و گزارش رویداد خود تونل. سپس بارگذاری با اندازهٔ معلوم را شروع کنید و دقیقاً همان اندازه‌گیری‌ها را در حین اجرا تکرار کنید. نقطهٔ پایانی، کلاینت و مقصد آزمون را بی‌تغییر نگه دارید، چون تغییر دو مورد از آن‌ها با هم چیزی به شما نمی‌گوید.
دقت کنید کدام رویداد نخست ظاهر می‌شود. بالا رفتن زمان رفت‌وبرگشت پیش از هر خطایی نشانهٔ صف است؛ پایان مهلت قطعی با تأخیر پایدار نشانهٔ چیز دیگری است، مانند تجدید کلید یا اقدامی روی حساب. دو الگو به گام‌های بعدی متفاوت می‌رسند. پیش از تغییر هر چیزی مشاهده را بنویسید.
خروجی را با برچسب‌های زمانی ذخیره کنید تا اجرای زیر بار و اجرای بی‌کار خط به خط مقایسه شوند.
صف را بخوانید، نه سرعت را
پیوندهای مصرف‌کننده بسته‌ها را در تجهیزات ارائه‌دهنده بافر می‌کنند و صف بالادستی پر همه چیز را به تأخیر می‌اندازد، از جمله بسته‌های کنترل کوچکی که تونل را زنده نگه می‌دارند. آزمون سرعتی که رقم بالایی نشان می‌دهد دربارهٔ آن تأخیر کم می‌گوید، و به همین دلیل آزمون در حالت بی‌کار قبول می‌شود در حالی که پیوند اشباع‌شده شکست می‌خورد.
ping -c 20 -i 0.2 203.0.113.10 mtr -rwc 20 203.0.113.10 tc -s qdisc show dev eth0 ss -ti dst 203.0.113.10 nstat -az | grep -E 'Retrans|Timeout'
رقم‌های تأخیر زیر بار را با رقم‌های حالت بی‌کار مقایسه کنید. جهش از ده‌ها میلی‌ثانیه به صدها، بدون افت بسته، صف است؛ افت با تأخیر پایدار به عیب دیگری اشاره دارد.
دستگاه و مسیر کنترل را بررسی کنید
رمزگذاری و ارسال، زمان پردازنده می‌گیرد و یک روتر کوچک یا لپ‌تاپی که از نظر حرارتی محدود شده می‌تواند هنگام اشتغال بسته‌ها را بیندازد. بار کلی را ببینید نه درصد یک فرایند را، چون ارسال در هسته و پردازش وقفه جایی که مردم معمولاً نگاه می‌کنند دیده نمی‌شود.
uptime mpstat -P ALL 1 3 dmesg | grep -i -E 'thermal|throttl' journalctl -u openvpn-server@server --since '10 min ago' | tail -20
پایان مهلت کلاینت می‌تواند با تجدید زمان‌بندی‌شدهٔ کلید یا با رویدادی از سیاست نشست هم‌زمان شود. برای ترتیب رویدادها گزارش خود کلاینت را بخوانید، نه فقط پیام خطای برنامه را.
یک چیز را تغییر دهید و تکرار کنید
جایی که پلتفرم پشتیبانی می‌کند، نرخ بارگذاری را محدود کنید یا ترافیک انبوه را پایین‌تر از ترافیک تعاملی دسته‌بندی کنید تا صف هرگز پر نشود. سپس همان بار کاری را تکرار کنید و همان سه رقم پیشین را مقایسه کنید. تغییری که آزمون سرعت را بهتر می‌کند اما پایان مهلت را سر جایش می‌گذارد چیزی را درست نکرده است.
بالا بردن مهلت‌ها در همه‌جا و تضعیف رمزگذاری دو تغییری هستند که نشانه را از میان می‌برند بدون آنکه مرزی را که شکست خورده مشخص کنند. هیچ‌یک تعمیر نیست. هر دو شکست را به زمان دیرتری می‌برند که انتسابش سخت‌تر است.
با آزمودن یک درخواست تازه و رفتار اتصال دوباره‌ای که کاربر واقعاً به آن تکیه دارد تمام کنید. پایداری زیر باری که شکایت را برانگیخت تنها نتیجه‌ای است که ارزش ثبت دارد.