কেন কথাবার্তাপূর্ণ SQL অ্যাপ VPN-এ ধীরগতিতে চলে এবং কী ব্যাচ করতে হবে

একটি ফর্ম যা লোকাল নেটওয়ার্কে এক সেকেন্ডের কম সময়ে দেখা যায়, VPN-এ পাঁচ সেকেন্ড নেয়, অথচ একই লিংকে ফাইল কপি পুরো গতিতে চলে। পার্থক্যটি ব্যান্ডউইথে নয়। ফর্মটি একের পর এক উত্তর পাওয়ার জন্য অপেক্ষা করে এবং প্রতিটি ধাপে পুরো রাউন্ড ট্রিপ দেয়, আর ফাইল কপি বাইটগুলোকে অবিরত পথে রাখে। অ্যাক্সেস লাইনে হাত দেওয়ার আগে সেই অপেক্ষাগুলো গুনুন।

উপসর্গটি একটি স্ক্রিন, কোনো কোয়েরি নয়

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

তাই স্পিড টেস্ট নির্দোষ দেখায়। বাল্ক ট্রান্সফার থ্রুপুট মাপে, কথাবার্তাপূর্ণ ফর্ম লেটেন্সি মাপে, আর একটি VPN একটিতে দুর্দান্ত ও অন্যটিতে সাধারণ থাকতে পারে। তাই স্ক্রিন নির্ণয় মানে লিংক নয়, স্ক্রিন মাপা।

কিছু বদলানোর আগে একটি ব্যবহারকারী কাজের শুরু থেকে শেষ পর্যন্ত সময় লিখে রাখুন। সেই সংখ্যাটিই একমাত্র ভিত্তিরেখা যা বলতে পারে পরে করা সংশোধন কাজ করেছে কি না।

একটি ব্যবহারকারী কাজে ধারাবাহিক অপেক্ষা গুনুন

অনুমান না করে ক্লায়েন্টেই পরিমাপ করুন। psql-এ \timing on প্রতিটি স্টেটমেন্টের অতিবাহিত সময় ছাপে, আর EXPLAIN (ANALYZE, BUFFERS) দেখায় সেই সময়ের কতটা সার্ভার সত্যিই কাজে ব্যয় করেছে।

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

ফলাফলটি ধারাবাহিক অপেক্ষার সংখ্যা হিসেবে লিখুন। পরবর্তী দুই অংশ যে পরিমাণ কমাতে পারে তা এই সংখ্যাই, এবং এটি এমন একটি সংখ্যা যার পক্ষে আপনি প্রমাণ নিয়ে তর্ক করতে পারেন।

স্বাধীন কলগুলো ব্যাচ করুন, নির্ভরশীলগুলো রাখুন

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

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

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

ব্যান্ডউইথ কেনার আগে সংযোগ পুনরায় ব্যবহার করুন

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

ADO.NET-এ একটি পুলকৃত সংযোগ বন্ধ বা নিষ্পত্তি করলে নতুন ভৌত সংযোগ খোলার বদলে তা পুনরায় ব্যবহারের জন্য ফিরে আসে, তাই লিক বলে মনে হওয়া প্যাটার্নটিই প্রায়ই সঠিক ব্যবহার। পুল সত্যিই ব্যবহৃত হচ্ছে কি না যাচাই করুন, ধরে নেবেন না: ভৌত সংযোগ তৈরির লগ রাখুন, বা স্ক্রিন চলার সময় সার্ভারে সেশন সংখ্যা দেখুন। SQL পারফরম্যান্স নির্দেশিকা-ও রাউন্ড ট্রিপ কমানো ও ঘন ঘন অ্যাড হক কল ব্যাচ করার একই কথা বলে, সেবা-নির্দিষ্ট উদাহরণসহ যা আপনার নিজের ডিপ্লয়মেন্টে প্রযোজ্য করতে হবে।

পুলিং সেটআপ খরচ সরায় এবং ধারাবাহিক কোয়েরি অপেক্ষা অপরিবর্তিত রাখে। এটি নিজে কোনো সংশোধন নয়, পরিষ্কার পরিমাপের পূর্বশর্ত।

এক্সিকিউশনকে ডেটার কাছাকাছি নেওয়ার বিষয়টি বিবেচনা করুন

অ্যাপ্লিকেশনটি ডেটাবেসের কাছে চালালে অনেক দূরবর্তী ডেটাবেস বিনিময় একটি দূরবর্তী ডিসপ্লে সেশনে বদলে যায়। কথাবার্তাপূর্ণ কাজের চাপে এটি বড় পরিবর্তন হতে পারে, আর এটি পারফরম্যান্সের মতোই পরিচালনগত পরিবর্তন: সেশন ব্যবস্থাপনা, অ্যাক্সেস নিয়ন্ত্রণ, সফটওয়্যার ডিপ্লয়মেন্ট ও ব্যবহারকারী অভিজ্ঞতা সবই অ্যাপ্লিকেশনের সঙ্গে সরে যায়।

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

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