我们目前在我们的生产服务器中遇到问题，并希望尝试在我们的开发中复制该问题。我目前正在等待访问我们的性能监控工具，而等待的时候想稍微玩一下。
我正在考虑，因为我怀疑主机在prod中受到限制，迫使主机在dev中加油，看看它是否会重新创建问题。
有办法做到这一点吗？
答案 0 :(得分：4)
正如其他人所提到的，监视throttling counters和其他计数器（如memory and WIP messages）是查看生产服务器中发生的事情的必要条件。如果您有SCOM，还建议在限制状态3+（发布+交付状态）上设置SCOM警报。
消息吞吐量可能会停止，特别是内存（4,5）和队列大小（6）状态。 1 + 2状态通常是短暂的（例如，大量消息的到达），Biztalk会在几秒钟内恢复。
通过调整throttling thresholds来模拟开发环境中的内存状态应该是直截了当的（显然不是生产中需要采取的措施！）
e.g。触发内存阈值状态 - AFAIK最低内存使用阈值you can set is 101MB。然后在dev中运行负载测试应该能够重现节流。 还有一个基于用户的限制覆盖来设置状态10 and 11，尽管实际上没有尝试过这个。
关于避免限制的其他一些经验：
（警告 - 我没有有效的BizTalk 2006 / R2设置 - 这是2009/2010年）
如果您进行了大量异步处理（例如，队列接收），请确保将拆分功能分配到单独的Hosts for Receive, Processing and Send主机中。这样，您可以调整异步接收主机的限制，使其比处理和发送主机更早地触发 - 这应该具有将新的传入消息限制到消息框但允许现有消息完成处理的效果。
在64位主机上，默认的25％内存主机使用限制级别通常是不必要的责任 - we increased this using Yossi Dahan's recommendation of 50% on a 4GB server
请注意，挂起的邮件会计入限制状态6 - 确保您有处理挂起邮件的策略（显然确保Sql Agent作业正在运行！）。