كيف هو أداء Accurev؟

Question

كيف هو الأداء في الإصدار الحالي (4.7) من أكيوريف?

• الوقت المناسب للخروج لكل 100 ميجا بايت لكل جيجا بايت؟
• الوقت للالتزام لكل # من الملفات أو ميغابايت؟
• استجابة واجهة المستخدم الرسومية عندما يكون هناك أكثر من 100 تيار؟

لقد حصلت للتو على عرض توضيحي لـ Accurev، وتبدو التدفقات وكأنها طريقة خفيفة لنمذجة سير العمل حول التعليمات البرمجية/المشاريع.لقد سمعت أشخاصًا يشيدون بشركة Accurev للتدفقات الخلفية ويشكون من الأداء.يبدو أن شركة Accurev قد عملت على الأداء، ولكنني أرغب في الحصول على بعض بيانات العالم الحقيقي للتأكد من أنها ليست حالة من العروض التوضيحية التي تعمل بشكل جيد أو أقل جودة.

هل لدى أي شخص حكايات عن أداء Accurev أو بيانات (حتى أفضل) من الاختبار؟

Answer 1

ليس لدي أي أرقام ولكن يمكنني أن أخبرك بالأماكن التي لاحظنا فيها مشكلات في الأداء.

تستخدم إصداراتنا عادةً ملفات تتراوح من 30 إلى 40 ألفًا من التحكم بالمصادر.يوجد حاليًا في مساحة العمل الخاصة بي أكثر من 66 ألف ملف، بما في ذلك إنشاء ملفات وسيطة ومخرجات، يزيد حجمها عن 15 جيجابايت.للحفاظ على عمل AccuRev بشكل مستجيب، نستخدم بقوة تجاهل العناصر لذلك يتجاهل AccuRev أي ملفات وسيطة مثل *.obj.بالإضافة إلى ذلك نستخدم تحسين الطابع الزمني.بشكل عام، يعد تشغيل التحديث أمرًا سريعًا، ولكن أحجام المشروع عادةً ما تكون من 5 إلى 10 أشخاص، لذا عادةً ما يتم تنزيل بضع عشرات من الملفات فقط إذا قمت بالتحديث يوميًا.حتى لو قام شخص ما بإجراء تغييرات أثرت على الكثير من الملفات، فلا تعد السرعة مشكلة.من ناحية أخرى، فإن التعبئة الكاملة لجميع الملفات التي يزيد حجمها عن 30 ألفًا تكون بطيئة.ليس لدي وقت لأنني نادرًا ما أفعل ذلك، وفي مناسبة نادرة أفعل ذلك، أقوم بملء المكان عندما أذهب لتناول الغداء أو الاجتماع.أتوقع أنه قد يصل إلى 10 دقائق.بشكل عام، يتم تنزيل الملفات المصدر بسرعة كبيرة، ولكن لدينا بعض الملفات الثنائية الكبيرة، يتراوح حجمها بين 10 و20 ميجابايت، ويستغرق كل منها بضع ثوانٍ.

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

منذ عام أو نحو ذلك، قام أحد المشروعات بتحديث التعزيز بإضافة أكثر من 25 ألف ملف وإضافة FireFox أيضًا إلى المستودع (انسَ الحجم ولكن جعل التعزيز يبدو صغيرًا.) كما أضافوا ICU وكتبوا الكثير من البرامج وقاموا بتعديل عدد لا يحصى من الملفات.على ما أذكر، كان هناك ما يقرب من 250 ألف ملف موجود في الدفق.لقد قررت للأسف أنه يجب ترقية جميع الأكواد الجيدة الخاصة بهم إلى الجذر حتى تتمكن جميع المشاريع من المشاركة.تبين أن هذا يتجاوز قليلاً ما يمكن لـ AccuRev التعامل معه بشكل جيد.لقد استغرقت عملية الترويج لجميع التغييرات ساعات طويلة.على ما أذكر، بمجرد ترقية FireFox، سارت بقية الأمور بسلاسة - ربما كانت المشكلة تتعلق بمعاملة واحدة تحتوي على أكثر من 100 ألف ملف؟

لقد قمت مؤخرًا بتحديث التعزيز ولذا كان علي الاحتفاظ بأكثر من 25 ألف ملف والترويج لها.استغرق الأمر دقيقة أو دقيقتين ولكن ليس من غير المعقول بالنظر إلى عدد الملفات وحجم الثنائيات.

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

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

Answer 2

تحرير 2014:يمكننا الآن الحصول على أداء X-Windows مقبول باستخدام الإصدار التجاري من RealVNC.

التعليق الأصلي: تنطبق هذه الإجابة على أي إصدار من Accurev، وليس فقط 4.7.أولاً، قد يكون أداء واجهة المستخدم الرسومية جيدًا إذا كان بإمكانك استخدام عميل الويب.إذا لم تتمكن من استخدام عميل الويب وإذا كنت تريد أداء واجهة المستخدم الرسومية، فمن الأفضل أن تستخدم Windows، أو أن يكون لديك جميع المطورين في مكان واحد، أي.حيث يقع خادم Accurev.هل تحاول تشغيل واجهة المستخدم الرسومية على نظام X-Windows عبر شبكة WAN؟انسى ذلك :لقد استغرقت تجربتنا عشرات الثواني أو الدقائق لعمليات النقر والنقر الأساسية.وهذا عبر شبكة WAN جيدة إلى حد ما على بعد حوالي 800 ميل، مع وقت اتصال مثالي تقريبًا.لا يعد هذا فشلًا في Accurev، ولكنه فشل في X-Windows، ومن المحتمل أن تواجه مشكلات مماثلة مع تطبيقات X الأخرى عبر شبكة WAN.لذا تجنب X الأساسي إذا استطعت.حاليًا لا يمكننا ذلك، ويتم إجبار مستخدمي WAN لدينا على سطر الأوامر فقط.المشكلة الأساسية هي أن Accurev مركزي ولا يمكنك زيادة سرعة الضوء.أعتقد أنه يمكنك التغلب على زمن استجابة WAN عن طريق تشغيل Accurev Replication Servers، لكن هذا لا يزال لا يعالج المشكلة بشكل صحيح إذا كان لديك مطورين عن بعد في مكاتب فردية عبر VPN.ومن المثير للسخرية أن خوادم النسخ المتماثل تحول إلى حد ما VCS المركزي هذا إلى شكل من أشكال DVCS.إذا لم يكن لديك خوادم النسخ المتماثل، فإن الحل البديل الرهيب ولكن العملي إلى حد ما هو استخدام أداة مزامنة دلتا مثل rsync لمزامنة الشجرة المصدر بين جهازك المحلي حيث يمكنك تشغيل واجهة المستخدم الرسومية (على سبيل المثال.واجهة المستخدم الرسومية التي تعمل مباشرة على الكمبيوتر المحمول الذي يعمل بنظام التشغيل Windows أو Linux)، والجهاز الذي تعمل فيه فعليًا (على سبيل المثال.آلة UNIX على بعد 1000 ميل).هناك خيار آخر وهو استخدام شيء مثل VNC الذي يعمل بشكل أفضل عبر شبكة WAN مقارنة بـ X، والاتصال بسطح المكتب الافتراضي في موقع خادم Accurev، واستخدام X من هناك.في مكان عملي، لجأ أكثر من فريق إلى استخدام Mercurial على الجانب والترقية إلى Accurev فقط عندما يكون ذلك ضروريًا للغاية.كما أشار ستيفن نوت أعلاه، فإن العمل الضروري الآخر هو استخدام تحسين الطابع الزمني والتجاهل.لدينا أيضًا مشرفو Accurev (نعم، يتطلب الأمر تعيين أشخاص ليشرفوا عليه) يشكون عندما نحتاج إلى تضمين أعداد كبيرة من الملفات، على الرغم من حقيقة أنها تشكل جزءًا أساسيًا من منتجنا ويجب تضمينها والتحكم في الإصدار.ارسم استنتاجاتك الخاصة.