تأخیر بالای DPC به معنای مسیر کند VPN نیست
زمان درایور، رفتوبرگشتهای پژواک و رویدادهای نشست به گردن یکدیگر میافتند. پیش از تغییر یک جزء بخوانید هر شمارنده چه چیزی را میسنجد.
یک اختلال صوتی و یک توقف VPN در همان ده ثانیه رخ میدهند و یک ابزار عدد بالایی با برچسب تأخیر DPC گزارش میکند. وسوسه آن است که نتیجه بگیریم درایور تونل را کند میکند یا تونل به درایور فشار میآورد. هیچیک از این دو نتیجه از آن عدد برنمیآید.
سه اندازهگیری اینجا در جریان است و آنها یک مرز مشترک ندارند.
سه عدد، سه مرز
فراخوانی تعویقافتاده رویه کاری است که درایور از گرداننده وقفه خود به تعویق میاندازد و زمانی که درون این روالها میگذرد اندازهگیری محلی پردازنده است که به ماژولها و توابع نسبت داده میشود. رفتوبرگشت پژواک مشاهده زمان در سوکت است که پشته شبکه و پاسخدهندهای دوردست آن را تولید میکنند. رویداد قطع اتصال گذار وضعیتی است که کلاینت ثبت میکند. هر یک به پرسشی پاسخ میدهد که بقیه نمیتوانند و یکسان بودن واحدها آنها را قابل تعویض نمیکند.
انضباط سودمند نام بردن مرز پیش از خواندن مقدار است. واحد و مرز را کنار هم بنویسید. اگر ابزاری میلیثانیه گزارش میکند، بپرسید میلیثانیه چه چیزی: زمان درون یک روال، زمان انتظار برای اجرا یا زمان تا رسیدن پاسخ.
عدد بالا در یک دسته سرنخ است، هرگز تشخیص نیست.
تعریف پشت تیتر را بخوانید
ابزارها در آنچه تأخیر مینامند تفاوت دارند. برخی مدت روالهای درایور را گزارش میکنند و برخی تأخیر زمانبندی را و این دو کمیت میتوانند روی یک دستگاه در جهتهای مخالف حرکت کنند. داشبوردی که یکی از آنها را صرفاً تأخیر DPC مینامد کمتر از آنچه به نظر میرسد به شما گفته است. بنابراین دو داشبورد میتوانند درباره دستگاهی که اصلاً تغییر نکرده اختلاف داشته باشند.
همین احتیاط درون یک ابزار تحلیل واحد هم صدق میکند. مدت شامل یک روال را از ورود تا خروج دنبال میکند، در حالی که مدت انحصاری فقط قطعاتی را جمع میزند که خود آن روال در آنها اجرا میشد. انتخاب ستون اشتباه فراخوان را به مجرم تبدیل میکند.
کار محلی درایور و تأخیر شبکه نیز بدون ادغام بر هم اثر میگذارند. فعالیت بیشازحد مرتبط با وقفه میتواند کار زمانحساس را روی دستگاه به تأخیر بیندازد و مسیر پرترافیک میتواند بستهها را به تأخیر بیندازد و هر دو میتوانند در یک توقف قابل مشاهده درست باشند.
هر مشاهده را در یک پنجره بگذارید
یک ردیابی فقط زمانی سودمند است که بازه حاوی نشانه را بخوانید. ردیابی، رویداد کلاینت و شکست برنامه را با مهرهای زمانی ثبت کنید و سپس به همان ثانیهها در هر سه نگاه کنید. بیشینهای از یک ردیابی یکساعته و قطع اتصالی بعدازظهر همان روز دو واقعیت بیارتباطاند.
wpr -start CPU -filemode
wpr -stop vpn-trace.etl
xperf -i vpn-trace.etl -a dpcisr -o dpc.txt
سپس ردیابی را در ابزار تحلیل باز کنید و بر اساس مدت درون همان پنجره مرتب کنید، نه بر اساس کل ضبط. راهنمای تحلیل پردازنده نمای مدت DPC/ISR را توصیف میکند که زمان را به ماژولها و توابع نسبت میدهد.
در حالی که آنجا هستید، تأیید کنید واقعاً برای تونل چه اتفاقی افتاد. از دست دادن کوتاه ترافیک برنامه به این معنا نیست که کلاینت مذاکره تازهای آغاز کرده و موفقیت یک کاوش کوچک ثابت نمیکند که همه چیز دیگر به کار ادامه داده است.
همان جزئی را تغییر دهید که شواهد نشان میدهد
ماژول مشغول جای بررسی است، نه حکم. ممکن است کاری را انجام دهد که جزء دیگری یا باری که شما تولید کردهاید سبب آن شده است. نام ماژول، دستگاه، نسخه درایور و بازه مشاهدهشده را کنار هم نگه دارید، زیرا همین مجموعه چیزی است که تأمینکننده میتواند بر اساس آن اقدام کند.
یک تغییر در هر آزمایش تنها راه یادگیری از نتیجه است. مقایسه با کابل دامنه را تنگ میکند، اما همزمان مسیر رادیویی و فعالیت درایور را تغییر میدهد، پس آن را سرنخ بگیرید نه دلیل.
ردیابی را حساس تلقی کنید. ممکن است شامل نام فرایندها و جزئیات محیط باشد، بنابراین جای آن کانال ضبط پشتیبانیشده است نه پیوست عمومی. بگویید ردیابی قرار بود به کدام مشاهده پاسخ دهد.