ما مدى تكلفة خدمات WCF المستضافة؟

Question

أنا وزميل في العمل أجرينا مناقشة حول خدمات WFC عندما يظهر موضوع "التكلفة".

السؤال هو:

بالنظر إلى أن خدمة WCF التي تستضيفها IIS وخدمة WCF التي تستضيفها Windows-Service تفعل الشيء نفسه بالضبط ، أي الخدمة ستكون أكثر "باهظة الثمن" فيما يتعلق بدورات الذاكرة ووحدة المعالجة المركزية إذا كان كلاهما يقبل نفس الحمل؟

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

Answer 1

لا يمكنني تقديم أرقام ملموسة ، على الرغم من أن هذا كان مصدر قلق كبير ، فيجب عليك بالتأكيد إجراء اختبار الأداء للتأكد. للحصول على خدمة WCF المستندة إلى HTTP النموذجية ، سيتم التعامل مع جميع الطلبات في البداية بواسطة HTTP.SYS داخل Windows ، ثم يتم إرسالها إلى العملية المناسبة. سواء لم يتم استضافة خدمتك في IIS أم لا ، فلن يهم ما يقرب من إعدادات التكوين الخاصة بـ WCF التي تستخدمها ، فيما يتعلق بالتكوين لكل نسبة أو في كل جلسة أو تهيئة محددة ، وطلب حدود الحجم وطلب الاختناق.

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

خلاصة القول: استخدم كل ما هو أكثر ملاءمة ، اختبار الأداء عند الضرورة.

Answer 2

أحد الاعتبارات المهمة في الأداء بين الاستضافة المستندة إلى خدمة Windows أو Windows لـ WCF ، هو نوع الربط. يدعم IIS فقط روابط WCF التي تعمل على HTTP ، مثل wsHttpBinding. basicHttpBinding, ، إلخ.

من المعروف عمومًا روابط غير HTTP لها أداء أفضل ، مثل nettcpbinding (يتطلب أن يكون كل من الخدمة والعميل يعتمدان على WCF على ما أعتقد) أو NetNamedPipeBinding (أسرع ، ولكن يجب أن تكون الخدمة/العميل على نفس الجهاز). هذه بالطبع لها قيودها الخاصة ، خاصة مع المرونة.

هذه لمحة عامة جيدة: http://weblogs.asp.net/spano/archive/2007/10/02/choosing-the-right-wcf-binding.aspx

كان هناك مناقشة مشابهة للغاية هنا: أداء الربط WCF

Answer 3

أعلم أن هذا لا يجيب على سؤالك تمامًا ، لكني أود مشاركة تجربتي.

لديّ تطبيق وحدة تحكم Windows عندما يتم الاتصال بجدولة خدمات WCF المستضافة في IIS. في هذه الهندسة المعمارية ، يكون IIS غير ضروري تمامًا ومكونًا إضافيًا للحل العام. تم تضمينه حقًا في الحل لأسباب تسويقية ، وتعزيز المنتج ، وليس لأسباب تقنية.

هذه هي المشكلات الرئيسية التي أواجهها ، ولماذا كنت سأتجنب استخدام IIS إذا كان بإمكاني لأسباب تقنية ، وهذا ينطبق على تجربتي. يرجى ملاحظة: أنا لا أقول أن استضافة خدمات WCF في IIS هي فكرة سيئة. أنا فقط أعطي أفكاري من المنتج الذي أعمل عليه في الوقت الحالي.

1. وجود IIS في الحلقة يعني وجود نظام آخر في الحل العام. وهذا بدوره يضيف التعقيد إلى نشرك. بعض العملاء لديهم IIS6 آخرون يديرون 7. في حين أن هذه الاختلافات قد تبدو صغيرة على السطح. لا تخطئ ، فهي لا تزال مختلفة ، مما يعني أنك تضيف المزيد من الإمكانات للاختلافات في البيئة إذا كنت تنشر منتجك على عملاء مختلفين. لا تقلل من هذه الاختلافات. حتى أن لدي عملاء يحاولون تشغيل خدمات WCF الخاصة بي داخل مجموعة مواقع SharePoint (Duh!) ، فإن النقطة أكثر بكثير مما تعتقد أنه يمكن أن يحدث خطأ.
2. لدى IIS أيضًا اعتبار AppPool ، والذي قد يلزم تكوينه وفقًا لتعقيد منتجك. يحتاج هذا AppPool إلى هوية لتشغيلها ، وإضافة المزيد من التعقيد مرة أخرى إلى الحل العام.
3. لقد واجهت بعض المشكلات التي يكون فيها خدمة واحدة متورطة في بعض الأحيان "مثيرة للاهتمام" - رسائل إحباط مؤشرات الترابط. على الرغم من أنني ما زلت أحاول اكتشاف السبب الدقيق ، إلا أنني في ذهني ، آمل بإخلاص أن هذا لا يرتبط بطريقة ما. النقطة المهمة هي أنني لن أحصل على هذا الاعتبار إذا قمت بإزالة IIS من الحل العام.
4. لقد سمعت مناقشات مفادها أن IIS هي بيئة استضافة أكثر قوة لخدمات WCF مقابل استضافة الذات. لست متأكدًا تمامًا من أن هذا يحمل أي وزن. إذا كنت تعرف ما تفعله ، فلا ينبغي أن يكون هناك أي سبب لأن خدمتك المستضافة الذاتية غير موثوق بها. لكنني أعتقد أنه من الممكن أن يكون العمل أكثر مقدمة لتنفيذ بعض الميزات التلقائية التي تحصل عليها في IIS ، على سبيل المثال إعادة تدوير WP.
5. أنا لست غير راضٍ بشكل عام عن IIS في الحلقة ، ولكنه ألم عندما أقوم بتسليم المنتج للنشر ، ويجب على الاستشاريين الذين ليس لديهم خلفية تقنية قوية إعداد تطبيق IIS. عادةً ما يمكن أن يحدث شيء ما وسيحدث خطأ ، ويتضمن شخصًا لديه خبرة فنية أكثر للتدخل وحلها. إذا كنت تستضيف ذاتيًا ، فيمكنك حزم تطبيقك بسهولة أكبر للنشر.
6. آسف للتكرار ، ولكن إذا ذهبت إلى IIS ، سيكون لديك تطبيقان في الحل الخاص بك بدلاً من 1 ، على الرغم من أن الجانب التجاري لمؤسستك لن يرى التطبيق كوحدة عمل واحدة فقط ، ولا فهم التعقيد الكامل للحل أنت تنفذ. على سبيل المثال: لماذا لدينا ملفان تكوين؟ لماذا يتعين علينا تكوين البريد مرتين؟ لماذا يتعين علينا نشر DLLs على موقعين. يتم طرح هذه الأسئلة كثيرًا.
7. أخيرًا ، اعتقدت أنني سأذكر ما إذا كنت تعمل عن بُعد أو أكثر من VPN للنشر للعملاء ، يزداد هذا الموقف سوءًا ، وأحيانًا يكون للمستشار الوصول إلى المجالات الحساسة التي لا تفعلها. كمطور يحاول القضاء على أكبر قدر ممكن من الأمتعة الإضافية من الحل العام. دعنا نذكر أيضًا أن SYS Admin قد يصدر أحيانًا إعادة تعيين IIS مريحة ، إذا تم استضافة تطبيقك إلى جانب الآخرين ، فسيقومون بإعادة ضبط خدماتك.

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