Visual Studio بطيء على مشاركة VPN: لماذا تتحول عمليات الحفظ إلى رحلات ذهاب وعودة

حلٌّ يُفتح في ثانية واحدة من قرص محلي يستغرق ثلاثين ثانية ليُفتح من مشاركة يُوصَل إليها عبر نفق. النفق نادرًا ما يكون السبب بحد ذاته. الذي يتغير هو أن العمليات التي كانت نداءات محلية تصبح رحلات ذهاب وعودة متزامنة، والمحرر ينفذ عدة منها قبل أن تظهر النافذة. تشرح الآلية أدناه سبب كون كل واحدة مكلفة وأيها يمكنك إزالته.

ما الذي يفعله المحرر أثناء فتح ملف

المحرر الذي يتتبع التغييرات يحتفظ باشتراك على كل ملف يفتحه. القرص المحلي يخدم ذلك الاشتراك من نظام الملفات دون أي شبكة. عبر مشاركة قد تتدهور الميزة نفسها إلى قراءات متكررة للبيانات الوصفية، لأن نموذج الإشعارات لا يعمل بالطريقة نفسها عبر SMB. إيقاف تتبع التغييرات تجربة أولى معقولة، لأنه يزيل فئة كاملة من الطلبات دون المساس بالنفق.

يضيف نظام المشروع حركة مرور خاصة به. تحميل حلٍّ يستعرض الدلائل ويقرأ ملفات المشروع وقد يبحث عن حزم SDK أو حزم أخرى، وكل بحث هو رحلة ذهاب وعودة عندما يكون المسار بعيدًا. والحل الذي يضم مشاريع كثيرة يضاعف هذا العدد، ولهذا ينمو زمن الفتح أسرع مما توحي به أحجام الملفات.

عمليات بحث الصدفة التي تنتهي قبل ظهور القائمة

يضيف Windows مصدرًا ثانيًا للتعطل لا علاقة له ببيئة التطوير. يعيد المستكشف وملحقاته حلّ الطابعات والأقراص المعيّنة والاختصارات المستخدمة سابقًا في كل مرة تُفتح قائمة سياق. وعندما تكون تلك الأهداف على شبكة لا يستطيع النفق الوصول إليها، يحجب كل حلّ حتى تنتهي مهلة، وعندها فقط تُرسم القائمة. لهذا قد يتجمد النقر بالزر الأيمن ثوانٍ بينما يُفتح الملف نفسه بشكل طبيعي.

أزل التعيينات الميتة وقوائم الطباعة، أو أبقِ فقط ما هو موجود على الشبكة التي أنت عليها فعلًا. وينطبق المنطق نفسه على أي شيء يحلّ مسارًا في الخلفية، بما في ذلك قوائم الملفات الحديثة والمجلدات المثبتة.

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

المراجعة الأساسية هي الجزء الذي يجب إتقانه، لأنها تحدد مقدار السجل الذي يسافر. حزم كل شيء يعمل ويهدر الرابط، في حين أن الحزم من آخر تغيير مشترك ينقل فقط ما يفتقده الجانب الآخر.

قِس ثلاث عمليات قبل لوم عرض النطاق

قِس ثلاثة أشياء منفصلة: ملف صغير واحد فُتح، ودليل واحد استُعرض، وحفظ واحد اكتمل. إذا كانت الثلاثة بطيئة بما يتناسب مع عدد الملفات، فالكلفة هي رحلات الذهاب والعودة. وإذا تعطل واحد بينما الآخرون بخير، فاشتبه في مهلة تجاه مورد لا يمكن الوصول إليه لا في عرض النطاق. سجّل على أي شبكة كان الجهاز في كل تشغيل، لأن حاسوبًا محمولًا يعيد الاتصال بملف تعريف آخر قد يغيّر الجواب بين المحاولات.

ثم كرر الثلاثة نفسها مقابل نسخة محلية من المشروع. الفرق هو ثمن المشاركة، وهو الرقم الذي تستشهد به حين يقترح أحدهم رابطًا أسرع كحل.