ماذا يحدث للمستخدمين الآخرين إذا تعطلت عملية .NET Worker؟

Question

معرفتي بكيفية معالجة العمليات من قبل عملية العمال ASP.NET غير كافية بشكل محزن. آمل أن يملأني بعض الخبراء هناك.

إذا تعطلت عملية العمال باستخدام نظام. OutofMemoryException ، فما هي تجربة المستخدم للمستخدمين الآخرين الذين يتم تقديمهم من قبل نفس العملية؟ هل سيحصلون على شاشة فارغة؟ 503 خطأ؟

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

تحديث: نتائجنا متنوعة. إذا تسببنا بشكل مصطنع في استثناء OOM (على سبيل المثال عن طريق تحميل PDF أكبر وأكبر في الذاكرة) ، فإن مؤشرات الترابط الأخرى التي تخدمها عملية العمال هذه "شنق" مؤقتًا ثم يكتمل ، في حين أن الآخرين لن يعودوا أبدًا. شكرا لكم على ردودكم.

Answer 1

w3wp.exe هي العملية

تقوم IIS بتشغيل جميع تطبيقات الويب في عملية عامل عام - W3WP.exe. سواء أكنت تكتب في ASP.NET ، أو ISAPI ، أو بعض الإطار الآخر ، فإن العملية التي تخدم طلب الويب هي w3wp.exe. في حالة ASP.NET ، يقوم W3WP.exe بتحميل DLLs و Services ASP.NET JIT. في حالات أخرى ، يعمل بشكل مختلف. لكن النقطة الأساسية هي أن W3WP.exe هي العملية. بدأ هذا النموذج في IIS6.0 ويستمر في IIS7.0.

فشل غير متوقع

إذا فشل w3wp.exe بشكل غير متوقع ، لأي سبب من الأسباب ، فمن المحتمل أن تحصل جميع المعاملات التي كانت تتعامل عليها على 500 خطأ (خطأ الخادم). ستبدأ IIS عملية عمل جديدة في مكانها (يطلق على مرض التصلب العصبي المتعدد هذا "المراقبة الصحية") ، مما يعني أن تطبيق الويب سيستمر في التشغيل. المستخدمون الذين لم يكن لديهم طلب يتم تقديمه من خلال العملية الفاشلة في وقت الفشل ، لن يكونوا على دراية بأي من هذا.

سيتم تمييز خطأ HTTP 500 الذي يتلقاه العميل في هذه الحالة من خطأ 500 الذي يتلقاه العميل في حالة خطأ في التطبيق ، دعنا نقول استثناءً غير معطل في رمز تطبيق ASPNET الخاص بك.

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

قائمة انتظار الطلب

IIS لديه نهج التسليم للطلبات. عند وصولهم إلى طبقة الشبكة (http.sys) ، يتم وضعها في قائمة انتظار ، لتلتقطها عملية العمال. ستستمر أي طلبات تنتظر في قائمة انتظار IIS التي يتم التعامل معها بواسطة WP غير متأثرة ، على الرغم من أنها قد ترى زيادة مؤقتة طفيفة في زمن الوصول (وقت الخدمة) بسبب خلاف الموارد ، حيث يتم تشغيل عملية أقل على الخادم. يكون وقت الانتظار في قائمة الانتظار هذه قصيرة جدًا بشكل عام ، على نظام تم تكوينه بشكل صحيح.

عندما تكون هذه قائمة الانتظار ممتلئة ، سترى 503 خطأ.

إعادة التشغيل التلقائي لـ W3WP.exe

يحتوي IIS على منشأة تلقائية (أو "مربية") ، من خلالها تقوم بإعادة تشغيل عمليات العمال بعد تجاوزها عتبات تكوينها, ، مثل حجم الذاكرة ، وعدد الطلبات ، أو وقت التشغيل. في جميع هذه الحالات ، ستقوم IIS بإعادة تشغيل عمليات العمال وإعادة تشغيلها عند الوصول إلى العتبة التي تم تكوينها. هذه إعادة التشغيل الاستباقية بشكل طبيعي لا تؤدي إلى أي تعطيل للطلبات. عندما تقرر IIS أن إعادة تشغيل عملية العمال ضرورية ، فإنها تمنع أي طلبات جديدة من الوصول إلى WP المرفوضة. يتم استنزاف الطلبات الحالية: يُسمح لأي معاملات على متن الطائرة في ذلك WP بإكمالها بشكل طبيعي. عندما تكتمل جميع الطلبات في WP ، فإن WP يموت ويبدأ IIS جديدًا في مكانه. ثم تبدأ هذه العملية الجديدة على الفور في التقاط طلبات جديدة من قائمة انتظار الإرسال. كل هذا شفاف للمستخدمين أو المتصفحات.

انا اقول بشكل طبيعي لأنه من الممكن أن تكون عملية العمال مريضة حقًا في نفس الوقت الذي تم فيه الوصول إلى العتبة. في هذه الحالة ، قد لا يستجيب w3wp.exe إلى IIS في الداخل مهلة "Quiesce" المكوّنة, ، وبالتالي يتعين على IIS قتل العملية في نهاية المطاف على الرغم من أنها لم تذكر أن جميع طلبات الطيران قد اكتملت. يجب أن يكون هذا نادرًا للغاية ، لأنه شروطان استثنائيان متميزان ، لكنه يحدث. في هذه الحالة ، ستحصل طلبات الطيران مرة أخرى على 500 خطأ.

حدائق الويب

أيضًا - يسمح IIS بعمليات عمل متعددة على خادم واحد. MS يطلق على هذا "حديقة ويب", ، مسرحية على كلمات من "مزرعة الويب". إذا كان لديك حديقة ويب تم إعدادها ، فستستمر المعاملات التي يتم تقديمها بواسطة حالات W3WP.exe بخلاف حدة الفشل ، غير متأثرة. "غير متأثر" يفترض أن الخطأ خارج الذاكرة مترجمة ، وليس مشكلة على مستوى النظام.

الحد الأدنى

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

ملاحظة: هذا الأسئلة والأجوبة حقًا ينتمي إلى serverfault.com !!

---

المراجع:
http://blogs.iis.net/thomad/archive/2008/05/07/the-iis-process-model-features.aspx

Answer 2

سيتم بدء سلسلة عمل جديدة ولن يعرف المستخدم أي شيء. ما لم يتم إيقاف تشغيله تمامًا عن طريق الفشل السريع (http://technet.microsoft.com/en-us/library/cc779127(ws.10).aspx)

Answer 3

إذا كان هذا وضعًا خارج الذاكرة ، فعادةً ما تقوم IIS بإعادة تدوير تجمع التطبيقات.

Answer 4

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

ومع ذلك ، إذا كان التطبيق الخاص بك يستخدم متغيرات الجلسة مع حالة جلسة داخل ، فستفقد جميع متغيرات الجلسة لجميع المستخدمين عند إعادة تشغيل تجمع التطبيقات. قد يكون لهذا أو لا يكون له تأثير سلبي على المستخدمين ، اعتمادًا على ما تفعله مع متغيرات الجلسة. يمكنك تجنب ذلك عن طريق التبديل إلى SQL Server Server Storage.