Azure Data Factory自托管运行时Lookup启动耗时过长问题咨询

这不是预期行为 #

ADF自托管运行时里Lookup活动的15秒左右启动开销明显异常，远高于SSMS里的执行耗时，这不属于正常预期，肯定存在额外性能瓶颈。

优化措施 #

• 启用并调优数据库连接池
  在ADF的SQL数据源配置里打开连接池，调整最大连接数、空闲连接超时这些参数，避免每次Lookup都重新建立数据库连接——这是这类启动开销最常见的原因。

• 统一存储过程的执行上下文
  SSMS和ADF调用存储过程时的默认SET选项（比如ANSI_NULLS、QUOTED_IDENTIFIER）可能不一样，导致生成的执行计划天差地别。可以在存储过程开头直接指定这些选项，和SSMS环境保持一致：

  SET ANSI_NULLS ON;
  SET QUOTED_IDENTIFIER ON;
  

  如果执行计划还是不对，就在存储过程的查询语句末尾加OPTION (RECOMPILE)强制生成最优计划，或者创建计划指南绑定到这个存储过程。

• 排查自托管运行时的网络与配置

  • 把自托管运行时部署到和SQL服务器同VNet、同区域的机器上，减少网络延迟
  • 把自托管运行时更新到最新版本，修复已知的性能bug
  • 检查运行时的网络配置，确认DNS解析、防火墙规则没拖慢连接速度

• 优化Lookup活动的使用方式

  • 要是有多个Lookup活动，尽量合并成一次存储过程调用（返回多个结果集或者把配置数据合并），减少重复的连接开销
  • 如果存储过程返回的结果集不小，可以先把结果写到SQL临时表，再用Lookup读临时表，把执行和数据读取的开销分开
  • 检查Lookup活动的配置，别开不必要的功能，比如数据预览、额外的结果集校验

内容的提问来源于stack exchange，提问作者AxSc