VPN کے ذریعے بڑا SQL نتیجہ: قطاریں کہاں انتظار کرتی ہیں

سوالات ملی سیکنڈوں میں ختم ہو سکتے ہیں اور پھر بھی VPN کے ذریعے لیپ ٹاپ تک پہنچنے میں منٹ لگ سکتے ہیں۔ سرور قطاریں بفرز میں لکھتا ہے، کنکشن انہیں لے جاتا ہے اور کلائنٹ انہیں استعمال کرتا ہے، اور یہ مراحل ترتیب سے چلنے کے بجائے ایک دوسرے پر چڑھ جاتے ہیں۔ ان میں سے کوئی بھی حد بن سکتا ہے۔ بینڈوڈتھ بدلنے یا کمپریشن فعال کرنے سے پہلے وہ مرحلہ تلاش کریں جو واقعی انتظار کر رہا ہے۔

تین مراحل، ایک اسٹاپ واچ

ٹائمر کو دو مختلف معنی رکھنے والے نمبروں میں تقسیم کریں: وہ لمحہ جب پہلی قطار دستیاب ہوتی ہے اور وہ لمحہ جب آخری قطار استعمال ہو چکی ہوتی ہے۔ پہلا صفحہ بنانے والا گرڈ صرف یہ ثابت کرتا ہے کہ سوال شروع ہوا تھا۔ مکمل نتیجے کا وقت وہی ہے جو صارف ایکسپورٹ کرتے یا آخر تک اسکرول کرتے وقت محسوس کرتا ہے۔

سوال کی عبارت، پیرامیٹرز اور کنکشن کی ترتیبات کے ساتھ دونوں نمبر درج کریں۔ اس سیاق و سباق کے بغیر موازنہ دو مختلف کاموں کے درمیان ہے، دو مقامات کے درمیان نہیں۔

نیٹ ورک سے پہلے انتظار پڑھیں

SQL Server نتیجے کی قطاریں آؤٹ پٹ بفرز میں لکھتا ہے تاکہ کلائنٹ انہیں لے، اور آہستہ استعمال کرنے والا کلائنٹ سرور کو اس بھیجنے پر انتظار کروا سکتا ہے۔ انتظار کی قسم ASYNC_NETWORK_IO ہے، اور Microsoft کا مسائل کے حل کا نوٹ وجوہات میں بڑے نتائج اور کلائنٹ کی طرف پروسیسنگ شمار کرتا ہے۔ انتظار بتاتا ہے کہ بھیجنے کا راستہ بند ہے، کیوں نہیں۔

سست VPN تعاون کر سکتا ہے، لیکن ایسا کلائنٹ بھی جو ہر قطار کو فارمیٹ کرتا ہے، فائل میں لکھتا ہے یا بیچ کے درمیان رکتا ہے۔ انتظار کا نام اگلی پیمائش کی طرف اشارہ ہے، لنک کے بارے میں فیصلہ نہیں۔

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

کاؤنٹر اس وقت پڑھیں جب محدود ورک لوڈ چل رہا ہو، خالی گھنٹے کے بعد نہیں، کیونکہ جمع شدہ کاؤنٹر انسٹینس شروع ہونے کے بعد سے ہر سیشن کو ملا دیتے ہیں۔ زندگی بھر کے کل کے بجائے رن کے دوران ڈیلٹا کا موازنہ کریں۔ منتقلی کے دوران بڑھتا ڈیلٹا سوال کو استعمال یا ترسیل تک محدود کرتا ہے۔

دونوں کلائنٹ ایک ہی گھڑی پر رکھیں

ڈیٹا بیس کے قریب کلائنٹ سے اور دور دراز کلائنٹ سے محدود ورک لوڈ چلائیں۔ سوال، پیرامیٹرز، نتیجے کا حجم اور کنکشن کی ترتیبات یکساں رکھیں۔ دونوں طرف ایک ہی پیمائش استعمال کریں، کیونکہ سرور کے عملدرآمد کا وقت، گرڈ دکھانے کا وقت اور ایکسپورٹ کا وقت تین مختلف گھڑیاں ہیں۔ سرور کی طرف کے نمبر کا کلائنٹ کی طرف کے ایکسپورٹ ٹائمر سے موازنہ ایسا نتیجہ دیتا ہے جسے جانچا نہیں جا سکتا۔

جب راستہ ذمہ دار لگے، تو نیٹ ورک کے مالک سے کہیں کہ منتقلی کے دوران اسی مخصوص بہاؤ کے لیے ضیاع، دوبارہ بھیجنا اور حاصل شدہ تھروپٹ دیکھے۔ عام رفتار کا ٹیسٹ کوئی دوسرا راستہ، اینڈ پوائنٹ یا ہم وقتی طرز استعمال کر سکتا ہے۔ چھوٹی کامیاب درخواست مستقل نتیجہ منتقلی کے بارے میں کم کہتی ہے۔

راستے کو الزام دینے سے پہلے بائٹس کم کریں

فلٹرنگ، مجموعہ بندی اور صرف ضروری کالم منتخب کرنا منتقلی کے حجم اور ہر قطار کے ساتھ کلائنٹ کے کام، دونوں کو کم کرتا ہے۔ مطلوبہ نتیجہ محفوظ رکھیں، کیونکہ رپورٹ کو ایسی تفصیل درکار ہو سکتی ہے جو اسکرین پر خلاصے میں نہیں۔

قابل تکرار ایکسپورٹ کے لیے، ڈیٹا بیس کے قریب منظور شدہ عملدرآمد کی جگہ متعین آؤٹ پٹ لکھ سکتی ہے جو پھر ایک بار پہنچایا جاتا ہے۔ یہ ورک فلو اور اس کے رسائی کنٹرول بدلتا ہے، اور مشترکہ ہوسٹ پر غیر محدود ڈمپ چھوڑنے کی اجازت نہیں۔

کمپریشن ڈیفالٹ علاج نہیں ہے۔ معاونت اور سلامتی اصل پروٹوکول اور تعیناتی پر منحصر ہے، اور کلائنٹ جسے آہستہ کھولتا ہے وہ کمپریس شدہ اسٹریم تجربہ مزید خراب کر سکتی ہے۔ پہلے مرحلہ ناپیں، پھر اس مرحلے کے لیے معاون تبدیلی منتخب کریں۔