VPN শেয়ারে Visual Studio ধীর: কেন সংরক্ষণ রাউন্ড ট্রিপে পরিণত হয়

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

ফাইল খোলা থাকাকালীন সম্পাদক কী করে

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

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

মেনু দেখানোর আগেই মেয়াদোত্তীর্ণ শেল অনুসন্ধান

Windows আরেকটি স্থবিরতার উৎস দেয় যার IDE-এর সঙ্গে কোনো সম্পর্ক নেই। Explorer ও তার শেল এক্সটেনশন প্রিন্টার, ম্যাপ করা ড্রাইভ ও আগে ব্যবহৃত শর্টকাট প্রতিবার প্রসঙ্গ মেনু খোলার সময় পুনরায় সমাধান করে। সেই লক্ষ্যগুলি এমন নেটওয়ার্কে থাকলে যেখানে টানেল পৌঁছায় না, প্রতিটি সমাধান টাইমআউট শেষ হওয়া পর্যন্ত আটকে থাকে, আর কেবল তখনই মেনু আঁকা হয়। এজন্য ফাইল নিজে স্বাভাবিকভাবে খুললেও ডান-ক্লিক কয়েক সেকেন্ড ঝুলে থাকতে পারে।

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

net use
Get-Printer | Select-Object Name, PortName
Measure-Command { Get-ChildItem \files\proj | Out-Null }

কেন স্থানীয় কার্যসংস্করণ জেতে

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

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

ইতিহাস একক অবজেক্ট হিসেবে সরান

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

hg bundle --base 9f2c1a7e outgoing.hg
hg unbundle outgoing.hg
git bundle create repo.bundle main
git clone repo.bundle repo

বেস সংশোধনীটি ঠিক করার অংশ, কারণ এটি ঠিক করে কত ইতিহাস ভ্রমণ করবে। সবকিছু বান্ডল করা কাজ করে কিন্তু লিঙ্ক নষ্ট করে, আর শেষ সাধারণ পরিবর্তন থেকে বান্ডল করা কেবল তাই সরায় যা অন্য পক্ষের নেই।

ব্যান্ডউইথকে দোষারোপের আগে তিনটি অপারেশন মাপুন

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

তারপর প্রকল্পের স্থানীয় কপির বিরুদ্ধে একই তিনটি পুনরাবৃত্তি করুন। পার্থক্যটি শেয়ারের দাম, এবং কেউ সমাধান হিসেবে দ্রুততর লিঙ্ক প্রস্তাব করলে এটিই উল্লেখ করার সংখ্যা।