نتیجه بزرگ SQL از طریق VPN: ردیف‌ها کجا منتظر می‌مانند

پرس‌وجوها می‌توانند در میلی‌ثانیه تمام شوند و با این حال دقیقه‌ها طول بکشد تا از طریق VPN به یک لپ‌تاپ برسند. سرور ردیف‌ها را در بافرها تولید می‌کند، اتصال آن‌ها را حمل می‌کند و کلاینت آن‌ها را مصرف می‌کند، و این مراحل به‌جای اجرای متوالی هم‌پوشانی دارند. هر یک از آن‌ها می‌تواند به حد تبدیل شود. پیش از تغییر پهنای باند یا فعال کردن فشرده‌سازی، مرحله‌ای را که واقعاً منتظر است پیدا کنید.

سه مرحله، یک کرونومتر

زمان‌سنج را به دو عدد با معنای متفاوت تقسیم کنید: لحظه‌ای که اولین ردیف در دسترس است و لحظه‌ای که آخرین ردیف مصرف شده است. شبکه‌ای که صفحه اول را ترسیم می‌کند فقط ثابت می‌کند که پرس‌وجو شروع شده است. زمان نتیجه کامل همان چیزی است که کاربر هنگام خروجی گرفتن یا پیمایش تا انتها تجربه می‌کند.

هر دو عدد را همراه با متن پرس‌وجو، پارامترها و تنظیمات اتصال ثبت کنید. بدون این بافت، مقایسه میان دو کار متفاوت است، نه دو مکان.

انتظار را پیش از شبکه بخوانید

SQL Server ردیف‌های نتیجه را در بافرهای خروجی می‌نویسد تا کلاینت آن‌ها را بگیرد، و کلاینتی که کند مصرف می‌کند می‌تواند سرور را روی آن ارسال منتظر نگه دارد. نوع انتظار ASYNC_NETWORK_IO است، و یادداشت عیب‌یابی مایکروسافت نتایج بزرگ و پردازش سمت کلاینت را از جمله علل آن فهرست می‌کند. انتظار می‌گوید مسیر ارسال مسدود است، نه اینکه چرا.

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

SELECT wait_type, wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type = 'ASYNC_NETWORK_IO';

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

هر دو کلاینت را روی یک ساعت بگذارید

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

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

پیش از متهم کردن مسیر، بایت‌ها را کم کنید

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

برای خروجی‌های تکرارشدنی، یک مکان اجرای تأییدشده نزدیک پایگاه داده می‌تواند خروجی تعریف‌شده‌ای بنویسد که سپس یک بار تحویل داده می‌شود. این گردش کار و کنترل‌های دسترسی آن را تغییر می‌دهد و اجازه گذاشتن یک دامپ بدون محدودیت روی میزبان مشترک نیست.

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