BizTalk开发系列(三十二)浅谈BizTalk主机性能优化

悠悠 2022-03-29 05:41 320阅读 0赞

**更多内容请查看：[BizTalk动手实验系列目录][BizTalk]**

**                      [BizTalk 开发系列][BizTalk 1]**

很多BizTalk的项目都要考虑到性能优化的问题，虽然BizTalk采用多线程处理消息的，大大提高了程序效率。但默认情况下BizTalk的主机有很多阻止参数会控制BizTalk对服务器的资源使用率，从而约束了BizTalk的效率。之前做了一个200万条CSV数据通过BizTalk传到数据库的程序。在不改变程序的情况下对主机性能做了一下简单优化，处理效率发生了成倍的增长。

**程序逻辑**

先简单的介绍一下程序的处理逻辑，CSV原文件大概有200多万条数据，文件大小50多Ｍ。每条只有两个字段总长度大概有三十个字符左右。进Pipeline之后由XML Disambler进行拆分,经过Orchestration拆分之后以每个XML　5000条数据进行处理。之后还需要经过其他Orchestration的订阅与处理。最后将数据存储到SQL Server中。从CSV到SQL Server Table一共需要经过５个变化也就是经过一次拆分和三次Map。

**软硬件环境**

硬件环境： Intel Xeon E5405 2.00Ghz X2 , 4GB , 74G X 8 RAID 5

软件环境：Windows Server 2003 Enterprise R2 32bit + BizTalk Server 2006 Enterprise R2 32bit + SQL Server 2005 Enterprise R2 32bit

虽然大家可能知道很多方法可以解决这个问题，比如数据库命令，SSIS，自定义Adapter，自定义Pipeline等，但关于程序的优化和合理性我们不在这里讨论因为项目有自己实际的问题，我们主要来看一下在不修改程序的情况下如果通过简单的优化主机性能达到性能的大幅度提高。

在优化之前（使用BizTalk默认设置）虽然我的程序也可以运行，但遇到了两个问题：一个是CPU的利用率很低一般情况下都在20%左右徘徊,磁盘读写效率也不高一般都在20M/s以下。二是数据库的数据不连续，也就是偶尔才会有数据往数据库里添加数据。不是连续的产生数据。所有数据跑完的时间大概需要2小时左右。

在优化之前我们需要了解一下两个概念: 主机阻止和CLR 宿主线程值。

**主机阻止**

在 BizTalk Server 上执行的大部分处理都在称为 BizTalk Server 主机实例的逻辑实体内进行，该逻辑实体是在 BizTalk Server 上以 Windows 服务或独立的主机进程运行的进程。为了管理主机实例进程使用的资源，BizTalk Server 使用可调整的阻止机制控制消息在主机实例中的传输和处理。

该阻止机制对主机实例的负载进行调节，以确保负载没有超过主机实例或任何下游主机实例的处理能力。该阻止机制还防止称为资源争用的情况发生，这种情况会降低主机实例进程或其他系统进程的整体性能。一个或多个进程消耗有限的资源从而损害进程自身和/或其他进程时，便会出现资源争用的情况。例如，消耗过量的内存或线程将导致内存分配失败或大量的线程上下文切换，这会影响进程的性能。这样的资源争用会降低 BizTalk Server 的整体性能。

主机阻止机制还检测可用资源利用不足的时间。如果可用的资源未得到充分利用，则阻止机制将允许主机实例处理更多的消息。主机阻止机制不断监视可用资源是否过度利用或利用不足，并据以调整通过主机实例的消息流。

总之，BizTalk Server 主机阻止机制有助于确保系统以最佳可持续水平运行。

**主机的CLR 宿主线程值**

Windows 线程是 Windows 进程可用的最基本的可执行单元，因此，有必要为与 BizTalk 主机实例相关联的 .NET 线程池分配足够的线程以防止线程不足。线程不足时，没有足够的线程用于执行请求的作业，因此会对性能造成负面影响。同时应注意防止为与主机相关联的 .NET 线程池分配不必要的过多线程。为与主机相关联的 .NET 线程池分配过多的线程会增加上下文切换。Windows 内核从运行一个线程切换到运行另一个线程时，会发生上下文切换，这会带来性能开销。分配过多的线程会产生过多的上下文切换，这会对总体性能产生负面影响。

通过在 BizTalk Server 的注册表中创建相应的 CLR Hosting 值，可以修改与 BizTalk 主机的实例相关联的 .NET 线程池中可用的 Windows 线程数。

**优化实战**

当然对于BizTalk的性能优化是一个复杂的事情。微软也提供也相应的分析工具和指南，但这些实现起来都比较麻烦，而且可能多人都喜欢偷懒，不喜欢看这些分析的数据和使用这些工具。现在我们就来简单的做一下优化，优化主有有几个方面，一个是修改主机的阻止参数，一个是注册表参数的优化(一些高级的功能都藏在注册表里^\_^)。

以下是我修改之后的参数设置，各主机阻止参数的含义大家可以通过查看帮助文档(规划可持续性能 > 引擎性能特性 > 通过主机阻止优化资源使用 >如何修改默认的主机阻止设置)了解，有些属性设置为０是指不启用主机阻止，也就是使用服务器最大资源。

1. 主机属性

[![clip\_image002][clip_image002]][clip_image002_clip_image002]

2.阻止阈值

[![image][]][image 1]

3.消息发布阻止设置

[![clip\_image002\[7\]][clip_image002_7]][clip_image002_7_clip_image002_7]

4. 消息处理阻止设置

[![clip\_image002\[9\]][clip_image002_9]][clip_image002_9_clip_image002_9]

5.修改.NET宿主线程值

Regedit.exe->HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\BTSSvcguid，其中 guid 是每个 BizTalk Server 主机实例的唯一 GUID

[![clip\_image002\[11\]][clip_image002_11]][clip_image002_11_clip_image002_11]

【Update：2016-9-8】 BizTalk 2013/2013 R2直接在Biztalk管理控制台的主机实例里进行修改

![28375-20160908092655082-1082708687.png][]

6.调整消息大小阈值

在映射期间，高于此阈值的文档将缓冲到文件系统中。修改该大小阈值，请在 BizTalk Server 注册表的以下位置处创建一个名为 TransformThreshold 的 DWORD 值：

HKLM\\Software\\Microsoft\\BizTalk Server\\3.0\\Administration\\TransformThreshold

输入一个要设置为新阈值的字节数的十进制值: 8000000

**优化结果**

通过简单的优化之后数据的处理时间从原来的将近２小时缩短到了25分钟左右，服务器的CPU,磁盘读写利用率也得到了大幅度的提高。还有数据库的数据基本上可以连续的产生。

CPU使用率平均在50%左右，有数据存储到SQL Server时会达到90%以上。

[![image][image 2]][image_image 2]

磁盘写数据速率达到了52Ｍ

[![image][image 3]][image_image 3]

**总结**

性能优化是个复杂的问题，需要经过大量的测试，而且由于项目和环境的需要面对的问题也不一样，程序的瓶颈也不一样。需要按实际情况解决。当然如果在程序设计和开过过程中充分考虑各产品的性能特点，优化程序的架构和处理方式应该是上上策。希望通过本文起到抛砖引玉的作用。大家在性能优化方面有什么经验也可以交流交流。最后声明一下：***以上数据仅供参考***！

*参考资料*

[BizTalk]: http://www.cnblogs.com/cbcye/admin/%20http:/www.cnblogs.com/cbcye/archive/2011/12/19/2293014.html
[BizTalk 1]: http://www.cnblogs.com/cbcye/archive/2008/10/28/1321182.html
[clip_image002]: https://images.cnblogs.com/cnblogs_com/cbcye/WindowsLiveWriter/BizTalkBizTalk_111/clip_image002_thumb.jpg
[clip_image002_clip_image002]: /images/20220329/8ec4d9c12ae7424389336f9f32e2f6e8.png
[image]: /images/20220329/bb52febd6ca048b8b11985894f1c89cc.png
[image 1]: http://images.cnblogs.com/cnblogs_com/cbcye/WindowsLiveWriter/BizTalkBizTalk_111/image_2.png
[clip_image002_7]: https://images.cnblogs.com/cnblogs_com/cbcye/WindowsLiveWriter/BizTalkBizTalk_111/clip_image002%5B7%5D_thumb.jpg
[clip_image002_7_clip_image002_7]: /images/20220329/1ea3bfc5b8bf49078b3f1137023b29ae.png
[clip_image002_9]: https://images.cnblogs.com/cnblogs_com/cbcye/WindowsLiveWriter/BizTalkBizTalk_111/clip_image002%5B9%5D_thumb.jpg
[clip_image002_9_clip_image002_9]: /images/20220329/396f42fabbb6437cad31790fb32382e3.png
[clip_image002_11]: https://images.cnblogs.com/cnblogs_com/cbcye/WindowsLiveWriter/BizTalkBizTalk_111/clip_image002%5B11%5D_thumb.jpg
[clip_image002_11_clip_image002_11]: /images/20220329/56ca3dfa797c44e1a1458b63562537f4.png
[28375-20160908092655082-1082708687.png]: /images/20220329/48c3255e4ad24e5389861db95e3f1910.png
[image 2]: https://images.cnblogs.com/cnblogs_com/cbcye/WindowsLiveWriter/BizTalkBizTalk_111/image_thumb_1.png
[image_image 2]: /images/20220329/96a1ff6a7bfb4800896c8c030cf26e06.png
[image 3]: https://images.cnblogs.com/cnblogs_com/cbcye/WindowsLiveWriter/BizTalkBizTalk_111/image_thumb_3.png
[image_image 3]: /images/20220329/c2e5ac81ff614d479af5766204f8e5ca.png