降低BizTalk接收位置文件输入速度

我们有一个BizTalk 2010接收位置，它将获得一个70MB文件，然后使用入站地图（在接收位置）和出站地图（在发送端口）生成1GB文件。降低BizTalk接收位置文件输入速度

执行上述过程时，SQL Server中会消耗大量磁盘I/O资源。另一个接收位置处理性能受到很大影响。

我们已经尝试减少该接收位置的主机实例中的最大磁盘I/O线程数，但它仍占用SQL Server中的大量磁盘I/O资源。

实际上这个过程的优先级非常低。是否有任何方法可以减少此进程的磁盘I/O资源使用情况，以使其他进程的性能可以正常运行？

2014-09-25 hosir

您是否尝试为此特定接收端口创建单独的主机？ – FCR 2014-09-26 06:10:56

是的，我已经尝试为这个特定的接收位置创建单独的主机，并且为这个单独的主机设置最低磁盘I/O线程。但是，在将文件存入消息箱期间，它仍然使用大量的SQL Server磁盘I/O，并且所有其他receivelocation的文件接收性能都受到影响。 – hosir 2014-09-26 13:34:53

此问题与文件输入的速度无关，但正如您在注释中提到的那样，当尝试将1GB映射输出保留到MessageBox时，将此负载放置在消息框中。您有几个选项可以尽量减少对其他进程的影响：

将新创建的主机上的限制设置调整为非常低的状态。这可能会或可能不会按照您希望的方式工作。
在这些文件的接收位置设置一个服务窗口，以便它们只在非工作时间运行。如果您没有MessageBox的全天候需求，并且能够承受半夜响应时间较短（如2-3点），这将是理想的选择
如果您的要求可以处理此问题，请勿将文件映射到接收端口中，而是将其路由到编排和/或自定义管道组件，然后将其拆分为更小的部分，然后映射较小的部分。这应该至少让你更好地控制它们被处理的速度（在处理这些片段的循环中有一个延迟形状）。当你将他们加入到一起时，仍然可能会有问题，但不应该像现在的流程那样糟糕。

它也可能是值得看看你的地图。如果有很多缓慢/处理器繁重的调用，您可能可以重构它。

来源

2015-01-11 23:12:34

理想情况下，你应该抓取文件。在每个单独的分段上应用业务逻辑（包括映射），然后逐个将它们加载到SQL中。稍后，您可以使用管道或其他.NET组件从SQL中提取数据并重新设置数据。在BizTalk消息箱中处理大xml（比平面文件大10倍）不是一个很好的做法。如果它是纯粹的消息传递方案，则可以将文件转换为流并将其路由到目标。

来源

2015-01-23 04:39:58

降低BizTalk接收位置文件输入速度

回答

相关问题