本文介绍了使用Throttling减慢biztalk。的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

大家好,

我们的一个应用程序同时从SAP获得100多个IDOCS和每个Idocs在业务流程中循环约70-80次(某种要求) 

One of our application receives 100+ IDOCS  from SAP at the same time and Each Idocs loops around 70-80 times in the orchestration (Some sort of requirement ) 

如果我们收到10个大的Idoc,那么CPU的ulitization仍然存在低于50%,但在非常罕见的情况下,我们同时收到了100个Idoc,CPU利用率连续1小时达到95-100%。  我们将来需要避免这种情况。

If we receive 10 big Idocs , the CPU ulitization remains under 50% but in a very rare scenario we received 100 Idocs at the same time and the CPU utilization goes to 95-100% for continuously 1 hour.  We need to avoid this in future.

我试图通过将业务流程放在专用主机上来调整一下更改基于费率的限制。 

I have tried to tweak a bit on it by putting the orchestration on a dedicated host and changed Rate based throttling. 

对于300秒的前2-3个倍数,CPU处于控制状态,但在大约1200或1500秒之后,我们仍然会收到旧消息进程和新处理也开始,所以CPU再次上升到100%

For first 2-3 multiples of 300 seconds the CPU is under control but after around 1200 or 1500 seconds  ,  we still have old messaged under process and new processing also starts so CPU again goes upto 100%

所以我们可以通过主机限制来限制业务流程实例仅参数?

So is there anyway we can limit the orchestration instance by working on Host throttling parameter only ?

谢谢,Varun

推荐答案

我们同时收到了100个Idocs,CPU利用率连续1小时达到95-100%。  我们将来需要避免这种情况。

we received 100 Idocs at the same time and the CPU utilization goes to 95-100% for continuously 1 hour.  We need to avoid this in future.

那么......为什么? 您支付了CPU费用,您应该使用它。 100%利用率本身不是问题。

So...why?  You paid for the CPU, you should use it. 100% Utilization itself is not a problem.

您试图解决具体影响吗? 它是否会影响特定的SLA?

Is there specific effect you're trying to address?  Is it impacting a specific SLA?


这篇关于使用Throttling减慢biztalk。的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

10-31 09:08