VPN-এ বড় SQL ফলাফল: সারিগুলো কোথায় অপেক্ষা করে

কোয়েরি মিলিসেকেন্ডে শেষ হতে পারে, তবুও 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';

সীমিত ওয়ার্কলোড চলার সময় কাউন্টারটি পড়ুন, নিষ্ক্রিয় এক ঘণ্টা পরে নয়, কারণ ক্রমপুঞ্জিত কাউন্টার ইনস্ট্যান্স চালু হওয়ার পর থেকে প্রতিটি সেশন মেশায়। জীবনের মোটের বদলে রান জুড়ে ডেল্টা তুলনা করুন। স্থানান্তরের সময় বাড়তে থাকা ডেল্টা প্রশ্নটিকে ভোগ বা সরবরাহে সংকুচিত করে।

দুই ক্লায়েন্টকে একই ঘড়িতে বসান

ডেটাবেসের কাছে থাকা ক্লায়েন্ট এবং দূরবর্তী ক্লায়েন্ট থেকে একটি সীমিত ওয়ার্কলোড চালান। কোয়েরি, প্যারামিটার, ফলাফলের আকার ও সংযোগ সেটিংস অভিন্ন রাখুন। দুই দিকেই একই পরিমাপ ব্যবহার করুন, কারণ সার্ভার সম্পাদনের সময়, গ্রিড প্রদর্শনের সময় ও এক্সপোর্টের সময় তিনটি ভিন্ন ঘড়ি। সার্ভার-সাইড সংখ্যার সঙ্গে ক্লায়েন্ট-সাইড এক্সপোর্ট টাইমারের তুলনা এমন সিদ্ধান্ত দেয় যা পরীক্ষা করা যায় না।

পথটি দায়ী মনে হলে, স্থানান্তর চলার সময় সেই নির্দিষ্ট প্রবাহের জন্য ক্ষতি, পুনঃপ্রেরণ ও অর্জিত থ্রুপুট দেখতে নেটওয়ার্ক মালিককে বলুন। একটি সাধারণ গতি পরীক্ষা অন্য রুট, এন্ডপয়েন্ট বা সমবর্তিতা প্যাটার্ন ব্যবহার করতে পারে। ছোট একটি সফল অনুরোধ টেকসই ফলাফল স্থানান্তর সম্পর্কে কম বলে।

পথকে দোষ দেওয়ার আগে বাইট কমান

ফিল্টারিং, অ্যাগ্রিগেশন এবং কেবল প্রয়োজনীয় কলাম নির্বাচন স্থানান্তরের আয়তন ও প্রতি সারিতে ক্লায়েন্টের কাজ—দুটোই কমায়। অভীষ্ট ফলাফল সংরক্ষণ করুন, কারণ প্রতিবেদনে এমন বিস্তারিত লাগতে পারে যা পর্দার সারাংশ দেয় না।

পুনরাবৃত্তিযোগ্য এক্সপোর্টের জন্য ডেটাবেসের কাছে অনুমোদিত সম্পাদন স্থান একটি নির্দিষ্ট আউটপুট লিখতে পারে, যা পরে একবার সরবরাহ করা হয়। এটি কর্মপ্রবাহ ও তার অ্যাক্সেস নিয়ন্ত্রণ বদলায়, এবং শেয়ার করা হোস্টে সীমাহীন ডাম্প রেখে দেওয়ার অনুমতি নয়।

কম্প্রেশন ডিফল্ট প্রতিকার নয়। সমর্থন ও নিরাপত্তা প্রকৃত প্রোটোকল ও ডিপ্লয়মেন্টের উপর নির্ভর করে, আর ক্লায়েন্ট যে চাপা প্রবাহ ধীরে খোলে তা অভিজ্ঞতা আরও খারাপ করতে পারে। আগে ধাপটি মাপুন, তারপর সেই ধাপের জন্য সমর্থিত পরিবর্তন বেছে নিন।