Microsoft Orleans grain 通信性能
Microsoft Orleans grain communication performance
我正在使用 Mircosoft Orleans 作为基础开发工作流引擎,因为它提供了许多有用的功能,例如自动分配工作和处理故障转移。
我有三种谷物:
- 工作流 - 包含工作流中的信息以及工作块应按什么顺序执行
- 工作块 - 实际完成工作的部分
- 执行 - 工作流的单次执行
我的问题是,当 运行 大量当前执行时,即 > 1000,性能确实会受到影响。我做了一些分析并将其缩小到谷物之间发生的通信。无论如何我可以再改进一下吗?
这是我的代码大纲以及颗粒如何相互作用
执行粒度位于一个循环中,从工作流中获取下一个工作块,然后在工作块上调用执行。正是这种在 grains 之间不断调用导致我的一个测试工作流的执行时间从 运行 单次执行时的 10 秒到 运行 超过 1000 次时的大约 5 分钟。这可以改进吗还是我应该重新构建解决方案以删除 grain 通信?
[StorageProvider(ProviderName = "WorkflowStore")]
[Reentrant]
[StatelessWorker]
public class Workflow : Grain<WorkflowState>, IWorkflow
{
public Task<BlockRef> GetNext(Guid currentBlockId, string connectionName)
{
//Lookup the next work block
}
}
[Reentrant]
[StatelessWorker]
public class WorkBlock : Grain<WorkBlock State>, IWorkBlock
{
public Task<string> Execute(IExecution execution)
{
//Do some work
}
}
[StorageProvider(ProviderName = "ExecutionStore")]
public class Execution : Grain<ExecutionState>, IExecution, IRemindable
{
private async Task ExecuteNext(bool skipBreakpointCheck = false)
{
if (State.NextBlock == null)
{
await FindAndSetNext(null, null);
}
...
var outputConnection = await workblock.Execute();
if (!string.IsNullOrEmpty(outputConnection))
{
await FindAndSetNext(State.NextBlock.Id, outputConnection);
ExecuteNext().Ignore();
}
}
private async Task FindAndSetNext(Guid? currentId, string outputConnection)
{
var next = currentId.HasValue ? await _flow.GetNextBlock(currentId.Value, outputConnection) : await _flow.GetNextBlock();
...
}
}
在我看来,这些函数不应该是独立的 grains,将它们聚合起来会消除昂贵的 grain 间通信。
如果将 Work Block 重命名为 Activity 并将 Execution 重命名为 WorkflowInstance,你的概念和微软的Workflow Foundation非常相似。我在 Orleans 上开始了一个关于 GitHub (Orleans.Activities) 到 运行 WF4 工作流程的项目。虽然它还没有准备好生产,没有性能测试,但至少可以工作。也许你应该试一试。
这里有几个问题:
1) Workflow 是一个 StatelessWorker 并且使用 StorageProvider 似乎不对。 StorageProvider 意味着它有它关心的状态持久化,StatelessWorker 意味着它没有任何状态。而是使用常规的非 StatelessWorker grains。
2) 让我们从上往下看建模:工作流只是关于工作流的数据和要执行的代码,WorkBlock 是多块工作流的一个块(多步工作流的一个步骤),对吗?在这种情况下,其中 none 应该是谷物。他们只是状态。执行是唯一需要粮食的。执行接收工作流,工作流在其数据中编码下一个块是什么,执行只执行该块。
3) 从可伸缩性的角度来看,您只需要大量的执行粒度。如果一个 Workflow 有一个 id,那么你可以为每个 Workflow id 使用一个 Execution grain。如果您想并行多次执行相同的工作流(具有相同的 ID),现在视情况而定。如果并行的不是太多,也许一个 Execution grain 就足够了。如果没有,您可以使用 X Execution grains 池(Execution grain 的 id 将是“WorkflowId-NumberBetween0AndX”)。
我正在使用 Mircosoft Orleans 作为基础开发工作流引擎,因为它提供了许多有用的功能,例如自动分配工作和处理故障转移。
我有三种谷物:
- 工作流 - 包含工作流中的信息以及工作块应按什么顺序执行
- 工作块 - 实际完成工作的部分
- 执行 - 工作流的单次执行
我的问题是,当 运行 大量当前执行时,即 > 1000,性能确实会受到影响。我做了一些分析并将其缩小到谷物之间发生的通信。无论如何我可以再改进一下吗?
这是我的代码大纲以及颗粒如何相互作用
执行粒度位于一个循环中,从工作流中获取下一个工作块,然后在工作块上调用执行。正是这种在 grains 之间不断调用导致我的一个测试工作流的执行时间从 运行 单次执行时的 10 秒到 运行 超过 1000 次时的大约 5 分钟。这可以改进吗还是我应该重新构建解决方案以删除 grain 通信?
[StorageProvider(ProviderName = "WorkflowStore")]
[Reentrant]
[StatelessWorker]
public class Workflow : Grain<WorkflowState>, IWorkflow
{
public Task<BlockRef> GetNext(Guid currentBlockId, string connectionName)
{
//Lookup the next work block
}
}
[Reentrant]
[StatelessWorker]
public class WorkBlock : Grain<WorkBlock State>, IWorkBlock
{
public Task<string> Execute(IExecution execution)
{
//Do some work
}
}
[StorageProvider(ProviderName = "ExecutionStore")]
public class Execution : Grain<ExecutionState>, IExecution, IRemindable
{
private async Task ExecuteNext(bool skipBreakpointCheck = false)
{
if (State.NextBlock == null)
{
await FindAndSetNext(null, null);
}
...
var outputConnection = await workblock.Execute();
if (!string.IsNullOrEmpty(outputConnection))
{
await FindAndSetNext(State.NextBlock.Id, outputConnection);
ExecuteNext().Ignore();
}
}
private async Task FindAndSetNext(Guid? currentId, string outputConnection)
{
var next = currentId.HasValue ? await _flow.GetNextBlock(currentId.Value, outputConnection) : await _flow.GetNextBlock();
...
}
}
在我看来,这些函数不应该是独立的 grains,将它们聚合起来会消除昂贵的 grain 间通信。
如果将 Work Block 重命名为 Activity 并将 Execution 重命名为 WorkflowInstance,你的概念和微软的Workflow Foundation非常相似。我在 Orleans 上开始了一个关于 GitHub (Orleans.Activities) 到 运行 WF4 工作流程的项目。虽然它还没有准备好生产,没有性能测试,但至少可以工作。也许你应该试一试。
这里有几个问题:
1) Workflow 是一个 StatelessWorker 并且使用 StorageProvider 似乎不对。 StorageProvider 意味着它有它关心的状态持久化,StatelessWorker 意味着它没有任何状态。而是使用常规的非 StatelessWorker grains。
2) 让我们从上往下看建模:工作流只是关于工作流的数据和要执行的代码,WorkBlock 是多块工作流的一个块(多步工作流的一个步骤),对吗?在这种情况下,其中 none 应该是谷物。他们只是状态。执行是唯一需要粮食的。执行接收工作流,工作流在其数据中编码下一个块是什么,执行只执行该块。
3) 从可伸缩性的角度来看,您只需要大量的执行粒度。如果一个 Workflow 有一个 id,那么你可以为每个 Workflow id 使用一个 Execution grain。如果您想并行多次执行相同的工作流(具有相同的 ID),现在视情况而定。如果并行的不是太多,也许一个 Execution grain 就足够了。如果没有,您可以使用 X Execution grains 池(Execution grain 的 id 将是“WorkflowId-NumberBetween0AndX”)。