لماذا يكون aspnet_compiler.exe بطيئًا جدًا (وهل يمكن جعله أسرع)؟

Question

أثناء عملية البناء لدينا نقوم بتشغيل aspnet_compiler.exe ضد مواقع الويب الخاصة بنا للتأكد من أن جميع العناصر المتأخرة في ASP.NET/MVC تم إنشاؤها بالفعل (لا أعرف شيئًا عن ASP.NET ولكني متأكد من أن هذا ضروري لمنع العثور على حالات الفشل في وقت التشغيل).

مواقعنا كبيرة الحجم إلى حد ما، حيث تحتوي على بضع مئات من الصفحات/المشاهدات/عناصر التحكم/إلخ.ومع ذلك، يبدو الوقت المستغرق مفرطًا في نطاق 10-15 دقيقة (كمرجع، هذا أطول مما يستغرقه تجميع الحل بأكمله مع ما يقرب من 40 مشروعًا، ونحن نقوم فقط بتجميع مشروعين على موقع الويب مسبقًا).

أشك في أن الأجهزة هي المشكلة لأنني أعمل على أحدث شريحة Intel رباعية النواة، مع ذاكرة وصول عشوائي (RAM) سعة 4 جيجابايت وقرص ثابت WD Velociraptor بسرعة 10000 دورة في الدقيقة.وجزء من الأمر الغريب هو أن EXE لا يبدو أنه يستخدم الكثير من وحدة المعالجة المركزية (1-5٪) ولا يبدو أنه يقوم بالكثير من عمليات الإدخال/الإخراج أيضًا.

لذا...هل هذه مشكلة معروفة؟لماذا هو بطيء جدا؟وهل هناك أي طريقة لتسريع ذلك؟

ملحوظة: لتوضيح بعض الأمور التي أجاب عنها الناس، أنا لا أتحدث عن تجميع التعليمات البرمجية داخل Visual Studio.نحن نستخدم مشاريع تطبيقات الويب بالفعل، وسرعة تجميعها ليست هي المشكلة.المشكلة هي التجميع المسبق للموقع بعد لقد تم بالفعل تجميع هذه المشاريع (راجع صفحة MSDN هذه لمزيد من التفاصيل) كجزء من البرنامج النصي لبناء التطوير.نحن نجري تجميعًا مسبقًا في مكانه، ولا ننسخ الملفات إلى الدليل الهدف.

Answer 1

1. يجب أن يقوم المحول البرمجي بإنشاء ملف ثانٍ للتعليمات البرمجية الخلفية لكل صفحة بتنسيق aspx. يفحص
2. أثناء التجميع، سيقوم aspnet_compiler.exe بنسخ جميع ملفات موقع الويب إلى دليل الإخراج، بما في ذلك CSS وJS والصور.

ستحصل على أوقات تجميع أفضل باستخدام مشروع تطبيق ويب بدلاً من نموذج موقع الويب.

Answer 2

والتبديل إلى مترجم روزلين على الأرجح سوف تحسن كثيرا من الوقت precompile. هنا هو مادة جيدة عن ذلك: <لأ href = "http://blogs.msdn.com/b/webdev/archive/2014/05/12/enabling-the-net-compiler-platform-roslyn-in-asp الصافي-applications.aspx "يختلط =" noreferrer "> http://blogs.msdn.com/b/webdev/archive/2014/05/12/enabling-the-net-compiler-platform-roslyn-in-asp الصافي-applications.aspx.

وبالإضافة إلى ذلك، تأكد من أن يتم تمكين تجميع الدفعة من خلال تحديد السمة دفعة إلى true على عنصر تجميع.

Answer 3

وببساطة، يستخدم aspnet_compiler ما هو فعال "قفل المترجم العالمي" كلما كان يبدأ قبل إعداد أي صفحة aspx الفردية؛ هو في الأساس يسمح فقط لتجميع كل بالتتابع الصفحة.

وهناك أسباب لذلك (على الرغم من أنني شخصيا أختلف معهم) - في المقام الأول، من أجل كشف ومنع المراجع الدائرية مما تسبب في حلقة لا نهائية من نوع ما، وكذلك التأكد من أن كافة التبعيات يتم بناؤها بشكل صحيح قبل الصفحة التي تتطلب يتم ترجمة ، وتجنب الكثير من "قضايا CS سيئة".

ولقد بدأت مرة واحدة كتابة نسخة متشعب كبير من aspnet_compiler.exe آخر مرة كنت أعمل في شركة على شبكة الإنترنت، ولكن حصلت على قيدوا مع "العمل الحقيقي" وأبدا الانتهاء من ذلك. اكبر مشكلة هي صفحات ASPX: الاشياء MVC / الشفرة يمكنك بشكل مواز للHELL الخروج منها، ولكن تحليل ASPX / تجميع ما المحرك حوالي 20 مستويات عميقة من الطبقات / طرق الداخلية وخاصة

Answer 4

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

Answer 5

فقط 2 سنتي.

أحد الأشياء التي تؤدي إلى إبطاء التجميع المسبق لمشاهدات ASP.NET بشكل كبير هو -fixednames خيار سطر الأوامر ل aspnet_compiler.exe. لا تستخدمها خاصة إذا كنت تستخدم Razor/MVC.

عند نشر تطبيق الويب من Visual Studio تأكد من تحديد "عدم الدمج"، و لا حدد "إنشاء تجميع منفصل" لأن هذا هو ما يسبب القفل العام ويبطئ الأمور.

مزيد من المعلومات هنا https://msdn.microsoft.com/en-us/library/hh475319(v=vs.110).aspx