باتونی SQL ایپ VPN پر کیوں رینگتی ہے اور کیا بیچ کرنا چاہیے

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

علامت ایک اسکرین ہے، استفسار نہیں

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

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

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

ایک صارف عمل میں یکے بعد دیگرے انتظار گنو

اندازہ لگانے کے بجائے کلائنٹ میں پیمائش ڈالو۔ psql میں \timing on ہر بیان کا گزرا وقت چھاپتا ہے، اور EXPLAIN (ANALYZE, BUFFERS) دکھاتا ہے کہ اس وقت میں سے سرور نے واقعی کام پر کتنا لگایا۔

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

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

آزاد کالیں بیچ کرو، منحصر رکھو

دو بیان جو ایک دوسرے کا نتیجہ نہیں پڑھتے، ساتھ سفر کر کے ایک بار جمع ہو سکتے ہیں، جو دو انتظار کو ایک بنا دیتا ہے۔ دو بیان جہاں دوسرے کو پہلے کی قدر درکار ہو، ایسا نہیں کر سکتے، کیونکہ انحصار حقیقی ہے اور بیچ کرنا پروگرام کا کام بدل دے گا۔ کچھ بھی دوبارہ لکھنے سے پہلے کالوں کو ان دو ڈھیروں میں تقسیم کرو، اور ہر ڈھیر کا حجم بتاتا ہے کہ کیا ممکن ہے۔

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

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

بینڈوتھ خریدنے سے پہلے کنکشن دوبارہ استعمال کرو

نیا کنکشن نام کے حل، TCP مصافحہ، TLS گفت و شنید اور توثیق کا خرچ لیتا ہے، اور زیادہ تاخیر والے راستے پر ان میں سے ہر ایک پہلے استفسار چلنے سے پہلے ایک اور گول سفر ہے۔ کنکشن پول اسی خرچ کو ہر کال کی بجائے ہر عمل کے لیے ایک بار ادا کرنے کے لیے ہیں۔

ADO.NET میں پول والا کنکشن بند کرنا یا dispose کرنا نیا طبعی کنکشن کھولنے کے بجائے اسے دوبارہ استعمال کے لیے واپس دیتا ہے، اس لیے رساؤ جیسا دکھنے والا نمونہ اکثر درست استعمال ہوتا ہے۔ پول کو واقعی استعمال میں ہونے کی تصدیق کرو، اندازہ نہ لگاؤ: طبعی کنکشن بننے کا لاگ رکھو، یا اسکرین چلتے وقت سرور پر سیشن کی گنتی دیکھو۔ SQL کارکردگی کی رہنمائی گول سفر کم کرنے اور بار بار ہونے والی ad hoc کالوں کو بیچ کرنے کے بارے میں یہی بات کہتی ہے، خدمت کے مخصوص مثالوں کے ساتھ، جنہیں آپ کو اپنی تعیناتی پر منطبق کرنا چاہیے۔

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

عمل درآمد کو ڈیٹا کے قریب لے جانے پر غور کرو

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

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

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