我正在尝试设置可以在 BizTalk 2010 中同时运行的最大编排数量。我发现我可以在主机级别为编排指定限制，并且可以选择指定暂停时间和恢复时间规范（在主机设置的“编排限制”选项卡上）。
根据阅读我在 MSDN 上找到的有限文档，我解释说，在为“暂停于”设置指定的数量处，BizTalk“暂停”并且不再启动新的编排，直到活动编排的数量 < ;= 恢复设置的规范。这是准确的解释吗？
I'm trying to set up a maximum number of orchestrations that can be run at once in BizTalk 2010. I've found that I can specify throttling for an Orchestration at the host level and have the option to specify a Pause at and Resume at specification (on the Host setting's "Orchestration Throttling" tab).
Based on reading the limitted documentation that I could find on MSDN, I'm interpreting that at the number specified for the "Pause at" settings, BizTalk "pauses" and does not start anymore new orchestrations, until the number of active orchestrations is <= the specification of the Resume at setting. Is this an accurate interpretation?
发布评论
评论（2）
我对此设置的理解（假设它与 自 BizTalk 以来限制 BTSNTSvc.exe.config 中的 PauseAt / ResumeAt 条目 2006）的一个缺点是它限制任何单个订阅（任何类型的端口或编排）的消息数量，而不一定限制特定类型的并发编排数量。此订阅的任何其他消息都将在消息框中排队。
（恕我直言，我发现 BTS 限制设置更多的是 BizTalk 的自我保存机制，而不是应用程序特定的调整机制）
如果您需要限制特定类型的编排数量（例如，如果 BizTalk 正在使下游应用程序过载）有限的 WCF 或 SQL 资源），您将需要实现单例编排的变体（即并发编排 <= N）。 Richard Seroter 此处描述了这种机制（负载均衡/ 循环调度，尽管我们已经使用了 Mike S 在评论中建议的随机数生成修改）。由于单个编排将处理所有/许多消息，因此围绕单例存在一些额外的稳健性问题 - 例如，尽可能严格地限制消息和变量的范围。您还需要监视单例，以确保消息的积压不会太高 - 我们发现，一旦您在单例上排队的消息超过 10k，处理时间就会变慢。
My understanding of this setting (assuming that its the same as the Throttling PauseAt / ResumeAt entry in BTSNTSvc.exe.config since BizTalk 2006) is that it restricts the number of messages to any single subcription (port or orchestration of any type), and not necessarily the number of concurrent orchestrations of a particular type. Any further messages for this subscription will be queued in the messagebox.
(IMHO I've found the BTS Throttling settings are more of a self preservation mechanism for BizTalk rather than an app specific tuning mechanism)
If you need to restrict the number of Orchestrations of a specific type (e.g. if BizTalk is overloading a downstream application with limited WCF or SQL resources), you will need to implement a variant of the Singleton Orchestration (i.e. concurrent orchestrations <= N). Richard Seroter describes such a mechanism here (Load Balancing / Round Robin Scheduling, although we've used the random number generation modification suggested by Mike S in the comments). There are some additional robustness concerns around singletons as a single orchestration will process all / many messages - e.g. scope your messages and variables as tightly as possible. You also need to monitor singletons to ensure that the backlog of messages doesn't get too high - we've found that once you get 10k+ messages queued up on a singleton that processing times slow down.
看看这个页面；
BizTalk 设置仪表板
特别是“暂停”在“部分说；
Look at this page;
BizTalk Settings Dashboard
Particularly the "Pause at" Section that says;