BizTalk: كيفية الحد من عدد الاتصالات بخدمة WCF؟

Question

لقد طورت تطبيق BizTalk الذي يتلقى كإدخال ملف يحتوي على مجموعة من الرسائل. يمكنني استخدام مكون BizTalk XML Disassembler ل "إزالة" الملف في رسائل Sepereate. يتم التقاط كل من هذه الرسائل من صندوق الرسائل بواسطة تزامن يحول الرسالة ويطلق خدمة WCF.

المشكلة التي أواجهها الآن هي أن كل دفعة تحتوي على 1000 رسالة ، وأن هذه الرسائل 1000 يبدو أنها تتصل بخدمة WCF في وقت واحد. يتم "قصف" خدمة WCF من قبل تلك الرسائل ويتم تكوينها لمعالجة 10 رسائل فقط بالتوازي (يجب على كل مكالمة معالجة البيانات ووضع البيانات في قاعدة بيانات) وإرجاع مجموعة من الاستثناءات "مشغول للغاية" إلى BizTalk. قمت بتكوين محول WCF لإعادة إعادة الاتصال مرة أخرى بعد دقيقة واحدة.

والنتيجة النهائية هي أن BizTalk أولاً تقوم بإرشاق الرسائل ، ثم القنابل خدمة WCF مع جميع الرسائل 1000 ، تحصل على مجموعة من الاستثناءات "مشغولة للغاية" ، ثم تنتظر أثناء عدم القيام بأي شيء ، حتى يتم تمرير دقيقة واحدة ، ثم قم بقنواتها مرة أخرى ، وهكذا ، وهكذا على.

ستكون المعالجة أكثر كفاءة إذا كان بإمكاني تكوين BizTalk لفتح اتصالات MAX 10 لخدمة WCF المحددة ، ولكن على حد علمي ، هذا غير ممكن. (تم تكوين خدمة WCF لاستخدام net.tcp.)

لقد جربت بالفعل إعدادات الاختناق للمضيف بعدة طرق مختلفة ، لكنها إما أنها لا تساعد ، أو أنها تجعل التطبيق بطيئًا. كما يبدو أن الاختناق في biztalk يتم تنفيذه بطريقة تطرحها أولاً على خدمة ، ثم يلاحظ أنها كانت تفجير ، ثم تنتظر بعض الوقت ، ثم يرفع الخانق ويبدأ القصف مرة أخرى. يبدو من الأفضل أن تنقل الطلبات/الرسائل ، بحيث تنتشر بشكل متساوٍ في الوقت المناسب. أرغب في تكوين محول WCF لتلقي رسائل MAX 4 في الثانية على سبيل المثال. يقول الاختناق الممكن الآن شيئًا مثل: خلال النافذة المنزلق من 5 ثوان ، أريد أن يتم تنشيط الاختناق إذا كان هناك أكثر من 20 رسالة. ولكن هذا ليس هو نفسه ، لأنه يسمح بتأثير "الانفجار".

أي أفكار كيف يمكنني تحسين الإنتاجية؟

Answer 1

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

حاولت اللعب مع تكوين الاختناق لمضيف BizTalk. هذا لم يساعد. لم أحاول فعلاً استخدام نمط Singleton ، لأن هذا شيء لا أريده: لقد أنشأنا بنية قوية موجهة للخدمة يمكنها بسهولة معالجة العديد من الرسائل بالتوازي ، ولا أريد التراجع تمامًا عن ذلك من خلال تقديم نمط مفردة .

إذن ماذا انتهى بي الأمر بعد ذلك؟ أولاً ، فكرت مرة أخرى في ما هو مطلوب بالفعل: نحن بحاجة إلى معالجة مجموعة من الملفات التي تحتوي كل منها على 1000 رسالة. الترتيب الذي تتم فيه معالجة رسالة داخل ملف ، غير مهم. الترتيب الذي تتم معالجة الملفات ، مهم. عادة ، يجب علينا معالجة الملف الأول 1 ، ثم 2 ، ثم 3 ، وهلم جرا. ومع ذلك ، ليس الأمر صارمًا ، فالترتيب هو فقط على نطاقات الملفات ، على سبيل المثال ، يجب معالجة النطاق الأول 1-5 ، ثم النطاق 6-8 ، ولكن ضمن نطاق ، لا يكون ترتيب الملفات مهمًا. لذلك كانت تلك المتطلبات.

أول شيء قمت بتغييره ، بدلاً من معالجة رسالة واحدة في كل مرة ، أقوم بتغيير الخدمة لقبول مجموعة من الرسائل ، حتى أتمكن من معالجة ملف واحد في وقت واحد. عن طريق معالجة ملف واحد في وقت واحد ، لا يوجد سوى مكالمة واحدة إلى خدمة WCF ، والتي تتمتع بميزة أن هناك الكثير من الدردشة بين BizTalk وخدمة WCF. لاحظ أن هذا يجعل الرمز على جانب خدمة WCF أكثر تعقيدًا لأنه لا يزال يتعين معالجة كل رسالة بشكل مستقل عن الآخرين (يجعل التعامل مع الأخطاء أكثر تعقيدًا). إذا تمكنا من معالجة عدد محدود من الملفات في وقت واحد ، فيمكننا أيضًا تجنب الخطأ المزدحم جدًا.

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

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

Answer 2

استخدم ال BizTalk نمط Singleton. هذا قبيح. لكن الهندسة المعمارية الأنيقة BizTalk تخلق القبح عندما تلتقي بالعالم الحقيقي.

Answer 3

بالنسبة لمحولات WCF المستندة إلى SOAP و HTTP و HTTP ، يمكنك استخدام إعدادات ConnectionManagement والحد من عدد الاتصالات هناك. يمكنك تحديد عدد الاتصالات المتزامنة بالضبط التي يُسمح بها كل مثيل مضيف BizTalk.تعيين محولات WCF المستندة إلى SOAP و HTTP و HTTP

ملحوظات:

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

2. هذا فقط ل محولات WCF المستندة إلى HTTP و HTTP. ليس لمحولات WCF الأخرى كما لاحظ RVDGINSTE

Answer 4

تعد حالات خنق المضيف في BizTalk آلية للحفاظ على الذات لتوافر BizTalk نفسها - لن أغيرها بخفة.

كما هو الحال مع Igal's Singleton Idea ، يمكنك القيام بأشياء قذرة إلى BizTalk لمنعها من زيادة تحميل تطبيقك من خلال مكالمات WS ، ولكن في النهاية قد تؤذي قابلية التوسع لخادم BizTalk عن طريق القيام بذلك. يبدو أن المكالمات المتزامنة لتطبيقك قد تكون المشكلة - ربما ننظر إلى التغيير إلى القيام بذلك بشكل غير متزامن باستخدام MSMQ؟

ولكن إذا بقيت WCF متزامن ، يمكنك أيضًا النظر إلى هذه المقابض لمحول WCF على مضيف إرسال الخاص بك (أعتقد أنك ستحتاج إلى الانتقال إلى محول WCF-Custom إن لم يكن بالفعل)

Answer 5

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

سأقول أن المدونة مؤرخة جدًا .. لكن الفكرة تعمل.