使用 Automatic Interception Interfaces

在您的应用程序中使用 Automatic Interception Interface 的常规流程如下：

1. 确保将要分发的进程管理工具能够支持非依赖进程的并行执行。

2. 创建一个 Profile XML 文件，该文件需要描述即将远端执行的工具以及作为调用者的工具。

3. 创建一个 Profile XML 文件，该文件为每个需要 Incredibuild 处理的任务都指定了设置，无论这些任务是调用者还是那些即将远端运行的任务。对于不需要 Incredibuild 处理的任务，您不必在 Profile XML 文件中对其进行声明。对于每个调用者任务，设置为 AllowIntercept=true 即可。您软件的主可执行文件应在 Profile XML 文件中进行定义，并且应将 AllowIntercept 属性设置为“True”。如果即将远端执行的进程是由主可执行文件的子进程生成的，那么从主可执行文件起始的整个进程层次结构均应将 AllowIntercept 属性设置为“True”。例如，如果主项目是“a”，“a”执行了“b”，“b”又执行了“c”（即我们想要分发执行的进程），那么“a”和“b”均须经过指定，并且应将 AllowIntercept 属性设置为“True”。对于每个即将分发至远端机器的任务，应设置为 AllowRemote=true。

4. 通过 IBConsole 命令，运行那些需要借助 Incredibuild 进行提速的应用程序或工具，以提供 Profile XML 文件的名称。名称既可以是 Job 的命令行，也可以是批处理文件的名称，后者应包含用于执行应用程序的命令（更多细节请见下文）。出于测试目的，以这样一种方式运行应用程序，将会激活比本地机器所含核心数量更多的进程。在这种情况下，Incredibuild 必须为远端机器上的某些进程执行分发。如果您正在使用“/COMMAND=”语法运行 IBConsole.exe（或适用于 .bat 文件的 cmd.exe 文件），那么在 /COMMAND 参数中指定的应用程序将被隐式赋予 AllowIntercept 行为。

备注：

• 当某一可执行文件经过指定且 AllowRemote 已设置为“True”时，可执行文件分支下的所有进程都会在指定核心内（例如远程核心）自动执行。因此，无需为各个子任务都指定 AllowRemote。

将 IBConsole.exe 与 Automatic Interception Interface 结合使用

执行了上述步骤后，即可将命令行字符串用于运行任何支持并行进程执行模式的工具。该命令行应指定为 IBConsole.exe 的输入参数（请参见下方示例）。注意，Profile XML 文件也需要在命令行参数中进行指定。

相关进程应以本地并行模式执行，同时，在由远端机器执行的 Profile XML file 中，应以设置“AllowRemote=True”对工具进行指定。

通过 XML Interface 运行分布式 XML 作业时，所使用的基本命令行语法如下：

其中:

• <TOOL COMMAND>–用于在并行进程执行模式启用时运行工具的命令行字符串。

• <PROFILE XML>–Profile XML file

• Other Options - 请在 DevTools Command Line 章节查阅更多 IBConsole.exe 命令行选项。作为使用 Profile XML 文件的替代方法，可以在 IBConsole 命令行中显式指定 AllowIntercept 和 AllowRemote 指令：

  IBConsole.exe /command="<TOOL COMMAND>" /allowremote="<FILENAME1[,FILENAME2,...]>" /allowintercept="<FILENAME1[,FILENAME2,...]>" [Other Options]

其中:

• <TOOL COMMAND>–用于在并行进程执行模式启用时运行工具的命令行字符串。

• <FILENAME1[,FILENAME2,...]>–一个以逗号分隔的工具文件名列表

• Other Options- 请参阅 IBConsole Command Reference 部分以了解更多 IBConsole.exe 命令行选项。

示例

假设您有一个名为 RenderApp.exe 的应用程序，它可以并行运行 RenderTask.exe 的许多任务，其中每个 RenderTask.exe 均可获取一帧并进行渲染。如果您以常规方式运行此应用程序，即不以多核心方式运行，那么您的调用方式如下：

RenderApp 1-1000

在这种情况下，应用程序会按顺序运行 RenderTask.exe 的 1000 个任务，且每次运行均会附带一帧（适用于第 1-1000 个任务）并进行渲染。使用此方法，需要花费 1000 倍于处理一帧的时间，用来完成对所有帧的渲染。

其实除此之外，您还可以使用此应用程序支持的另一种方法。这种方法利用了本地机器上的本地核心。您使用此方法调用 RenderApp 时，可以令其同时在 4 个核心上运行，具体如下：

RenderApp 1-1000 cores4

在这种情况下，应用程序每次会基于机器中的 4 个核心以同时运行 4 个 RenderTask.exe 任务，而不是每次只运行一个任务。使用此方法，运行 1000 个任务所需的时间仅相当于运行 250 个任务的时间。

借助 Incredibuild，您可以创建一个 XML 格式的 Profile 文件，这种文件能够指定 Incredibuild 以何种方式处理应用程序中的不同任务（进程）。RenderApp 作为主应用程序，运行于本地机器，也是子进程的调用者。您可以在 Profile XML 文件中对其进行定义，同时应设置为 AllowIntercept=true。此外，由于 RenderTask 运行于远端机器，您可以将其定义为远程任务。

注意： 您无需在远端机器中安装任何程序，但需上传所有文件到远端机器。Incredibuild 在处理任务时，会将远端机器的核心视为本地机器的核心。

RenderApp.exe AllowIntercept=trueRenderTask.exe AllowRemote=true

此例中，Incredibuild 的工作流如下：

1. Incredibuild 执行主进程 RenderApp.exe。

2. Incredibuild 拦截所有调用（即与 RenderApp.exe 将执行的进程调用相关的调用），然后将这些调用与在 profile.xml 文件中标记为“AllowRemote=true”的进程相比较。

3. 当 Incredibuild 发现了在进程中标记为“AllowRemote=true”的进程调用时，Incredibuild 引擎会将此进程分发至远端机器，而不是在本地执行它。

4. 任何由远程执行进程生成的输出均会被转发至本地机器 (Initiator)，视为在某一本地核心上执行该输出。

要进一步加速 RenderApp 的执行，建议不要运行 RenderApp 1-1000 –cores4，而是运行命令。

IBConsole RenderApp.exe 1-1000 -cores1000 /profile=profile.xml 如果进行该操作，全部 1000 个任务均会进入 Incredibuild 队列，此时 Incredibuild 会根据可用核心数量来管理任务执行。例如，如果有 200 个可用核心，那么每次可运行 200 个任务，因而完成全部 1000 个任务的时间仅相当于完成 5 个任务的时间。

欢迎您查看我们的示例项目，项目位于 Samples\Dev Tools Interfaces Usage Samples\Interception Interface 中的 Incredibuild 安装文件夹下。其中有一个 Sample Project 示例，它是一个简单的自动拦截示例。

该示例需要以下参数：

• 要运行的 exe (DummyProcess.exe)

• 执行进程的次数

• 终止进程前的睡眠时间

• [可选]子进程自行终止前的时间

Automatic Interception Interface 示例项目：

以下是一个作业示例，其中展示了某个名为 MainProcess 的进程执行了很多名为 Dummy 的子进程。

以下示例中的 XML 文件已保存为 Profile.xml 文件。

• IBConsole /command="MainProcess.exe DummySubProcess.exe 10 2000 2000" /profile="profile.xml" /openmonitor /title="Automatic Interception Sample"

在此示例中，MainProcess.exe 并行加速了 10 个 DummySubProcess.exe 实例，其中每个实例运行了 2 秒。此外，由于进程在配置文件中被定义为 AllowRemote=true，因此进程会在本地和远程两种机器上运行。