لماذا يرى تطبيق الويب الخاص بي الكمون؟

Question

لدينا تطبيق ASP.NET، الذي يتصرف بشكل غريب تحت IIS6. التطبيق نفسه بسيط واضح ASP.NET 2.0 صفقة WebForms، لا شيء غريب للغاية يحدث هناك (هناك وحدات HTTP الزوجين في خط الأنابيب، لكنني لن أعتبر تلك الغريبة :)). الشيء الذي لا أفهمه هو أوقات تنفيذ الصفحة، أو، بشكل أكثر تحديدا، الفرق بين الوقت الذي أبلغ عنه تتبع ASP.NET (TRACE.AXD) ولاحظه العميل (FIDLLER). عند تشغيل التطبيق في صندوق المطور (WinXP، IIS5.1)، أبلغت الأوقات التي أبلغت عنها ASP.NET و FIDLLER قريبة جدا:

Page exec الوقت: 0.0919834 FIDLLER TOTAL THILLENS TIME: 0.1560980 

أستطيع أن أفهم 60ms التي أنفقت فيها الحصول على بيانات 5 كيلو بايت من IIS إلى FIDLLER (كلاهما يعمل على نفس الجهاز، BTW). الآن، عندما ننقل الرمز إلى الخادم (Win2k3، IIS6)، تتغير الصورة بشكل كبير:

Page exec الوقت: 0.1702014 fiddler إجمالي التسلسل الوقت: 0.5156283 

هذه الصفحة نفس الصفحة، وتشغيل fiddler مرة أخرى على نفس الجهاز مع الكود. لماذا يستغرق فجأة 350 مللي ثانية لتقديم نفس 5 كيلو بايت؟

ملاحظة. على كلا الجهازين يتم الحصول على النتائج عن طريق الوصول إلى عنوان URL عبر اسم مضيف الجهاز الفعلي، على سبيل المثال http: //machinename/app/page.aspx. (في مقابل http: //localhost/app/page.aspx.).

PPS. التكوين - الحكيم، إعداد مربع ديف والخادم هو أقرب ما يمكن أن نجعله - كلاهما يستخدم كلاهما نفس الويب. ضرب كلا DB (SQL Server) مع مصادقة متكاملة، وبالتالي، يعمل التطبيق تحت حساب مجال. يستخدم التطبيق مصادقة النماذج، ولا ينتحذر (أي يعمل دائما تحت نفس الحساب). الآن، الطريقة التي يعمل بها IIS5 مختلفة عن IIS6 - على IIS5، يتم تحديد الحساب في علامة في Machine.config، وعلى IIS6 إنه إعداد AppPool. يبدو الإعداد نموذجا نموذجيا لكل من البيئة، ولا يمكنني تخيله مسبقا تأخير 350ms ...

Answer 1

بعد إنفاق أحد حوادث الدعم القليلة الثمينة لدينا مع اشتراك MSDN لدينا، أعرف أخيرا الإجابة الصحيحة على "أين أمضى كل هذا الوقت". باختصار، يتم إنفاق الوقت في وحدات HTTP لدينا في خط أنابيبنا. القياسات الزمنية التي أبلغ عنها ASP.NET Trace.axd سجل الوقت الذي يقضيه فقط في صفحة .aspx نفسها، وحدات ليس وشملت.

إحدى الطرق السهلة للتأكد من ذلك (ومعرفة كم من الوقت تأخذ كل وحدة نمطية للقيام بشيءها) هي استخدام ETW (تتبع الحدث لنظام التشغيل Windows). هنا هو تفسير (أشك بشدة في كتابة هذا المنشور بعد أن نظروا إلى علمنا :)) شيء واحد يمكنني إضافته إلى الوصف الممتاز أعلاه هو أنني استخدمت svctraceviewer. بدلا من Logparser لتحليل إخراج التتبع.

تحديث: يعمل النهج أعلاه أيضا على Windows Server 2008، فقط تأكد من أن لديك التتبع المثبتة.

Answer 2

قم بإجراء مسار تتبع على عنوان URL الذي تتصل فيه ومقارنتها. أنا أراهن مع آلة المطور التي تقيم فيها داخلية للآلة، ولكن على آلة الإنتاج التي تسير خارجها، ثم العودة عبر عنوان IP.

إذا كان هذا هو الحال، فحاول إضافة هذا إلى ملف المضيفين الخاص بك (C: Windows System32 Drivers Etc Hosts

www.mysite.com    127.0.0.1

سيؤدي ذلك إلى التأكد من عدم مغامرة طلبك خارج الماكينة للقيام بالطلب. يجب أن ترى أوقات الاستجابة لتبدأ في المجيء مع بعضها البعض.

تحديث

بالنظر إلى التحديثات الجديدة. إذا كان الخادم قيد التحميل، في حين أن الاختبار في الإنتاج قد يمثل ذلك الفرق، لأنه يحاول بنشاط تقديم طلبات أكثر من آلة التطوير التي تحاول فقط تسليم 1.

أو يمكن أن يكون ذلك لأنك تقوم باختبار إصدارين مختلفين من IIS، 5.1 على XP و 6.0 في عام 2003. لا يمكن حقا حساب الاختلافات ما لم يتم تشغيل البيئة نفس البرنامج.

Answer 3

هل يعمل التطبيق في تكوينات إصدار متطابقة على كلا المربعين؟

تحرير: تغيير خط أنابيب الطلب بشكل كبير بين IIS5 و IIS6، Trace.axd سترى فقط جزء ASP.NET منه، وليس تجمع التطبيقات الجديدة ومكونات http.sys.

أود أن أتخيل أنه يمكن ضبط التكوين على IIS6 قليلا، ولكن من المحتمل أن تبحث في اختلاف خادم WebServer غير الإنتاجي خفيف الوزن (IIS5) وحامل الويب القوي مع تجمعات تطبيقات فردية لإدارة وأكثر من طبقات التجريد.