BizTalk应用SOAP/ASMX Receive位置性能异常，请求耗时占比过高求助

你已经把数据库查询和BizTalk编排的耗时都排查清楚了，剩下的700ms里近650ms的损耗，基本都集中在IIS托管的ASMX服务、BizTalk接收适配器/管道或者两者之间的通信环节上。下面给你一步步拆解排查方向和优化建议：

一、先盯紧ASMX Web服务本身的开销 #

• 打开perfmon，监控IIS和ASP.NET的核心指标：重点看ASP.NET Apps\Request Execution Time（单请求执行时长）、ASP.NET\Requests Queued（排队请求数），如果排队数持续走高，说明IIS线程池不够用或者服务处理慢；如果执行时间本身就接近总耗时，那问题就在ASMX端。
• 给ASMX加个极简日志：在服务的入口方法前后打时间戳，直接统计从接收到请求到把消息传给BizTalk的时间，排除是不是身份验证、参数校验这类额外逻辑拖了后腿。
• 检查web.config的坑：别漏看compilation debug="true"——开调试模式会让ASMX性能暴跌，必须改成false；还有executionTimeout、maxRequestLength这些参数，有没有因为请求大小或超时设置导致隐性等待。

二、排查BizTalk接收侧的瓶颈 #

• 用BizTalk自带的性能计数器找线索：重点看BizTalk Messaging\Message Processing Time（消息在管道里的处理时长）、BizTalk Adapter for SOAP\Messages Received/Sec（SOAP适配器的消息接收速率），如果处理时间远超编排的30ms，那管道或适配器就是问题点。
• 检查接收管道组件：如果用了自定义管道组件，单独拿出来做性能测试（写个控制台程序跑批量调用），看看是不是组件本身耗时高；默认XML接收管道如果没用到XML Validator，直接关掉，能省不少XML解析和验证的时间。
• 调整BizTalk主机配置：接收位置绑定的主机，CPU、内存配额是不是太小？或者线程池参数不合理？在BizTalk管理控制台里，把主机的Maximum Worker Threads和Maximum IO Threads调高些（比如按服务器核心数的2倍设置），避免线程不够导致消息排队。

三、排查进程间通信的隐性开销 #

• 虽然是同一服务器，但IIS（w3wp.exe）和BizTalk主机进程（BTSNTSvc.exe）之间的通信也可能有损耗。用Process Monitor监控这两个进程的交互，看看有没有频繁的文件读写、注册表访问，或者长时间等待的事件。
• 优化接收位置的适配器配置：如果用的是HTTP适配器，确认Keep-Alive是开启的，减少TCP连接建立的开销；另外，Batch Size别设太大——批量处理能降低BizTalk的单消息 overhead，但太大的话会让单请求的等待时间变长，建议从10-20开始测试。

四、针对性优化方案 #

• 替换ASMX为WCF服务：传统ASMX的性能确实不如WCF，换成basicHttpBinding的WCF服务，不仅性能提升明显，配置也更灵活（比如可以开启传输压缩、调整线程池）。如果必须保留ASMX，尽量简化服务逻辑，只做消息转发，把校验、鉴权移到BizTalk管道里。
• 拆分BizTalk主机：把接收主机和编排处理主机分开，避免接收消息的线程被编排任务占用，保证接收链路的资源充足。
• 确认Oracle连接池：虽然数据库查询只有15ms，但要确保BizTalk用的Oracle驱动开启了连接池（默认是开的，但最好检查下配置），避免每次请求都新建数据库连接的隐性开销。
• 用性能分析工具精准定位：如果上面的排查还找不到问题，试试用BizTalk Server Profiler或者Visual Studio的性能分析工具，对BizTalk主机进程做采样分析，找到具体的耗时函数，直接定位瓶颈。

内容的提问来源于stack exchange，提问作者Piotr Grudzień