我对扩展Azure持久功能有疑问。
我正在编写一个仿真引擎,该引擎执行大量计算密集型任务(复杂数学)的(1000倍)耗时相对较短,每个近似值需要10秒。
我正在使用DurableOrchestration创建“活动”功能的扇出。
在运行模拟的那一刻,它将按照下面的配置在虚拟机中排队任务并运行2个任务。
{
"durableTask": {
"maxConcurrentActivityFunctions": 2,
"maxConcurrentOrchestratorFunctions": 10
}
}
目前,这种方法可以扩展到大约20到30多个虚拟机,并且需要一段时间才能运行,我的测试需要几分钟。通过查看历史记录表,我猜它正在缓慢增加VM的数量。
我真正想让我的功能运行在指定数量的vm(例如200)上,并在几秒钟内运行仿真。
我正在制定消费计划,这当前可行吗?或者可以通过其他App计划实现吗?
仅是考虑一下,也许一个好主意是创建带有一些Activity函数调用集合的ActivityBatch类,您可以在其中指定每个任务将花费多长时间以及所需的运行时间的近似值。
这样,Azure可以计算将功能传播到的虚拟机数量,以便它可以尝试满足用户要求。
预先感谢
答案 0 :(得分:2)
无法直接干预Scale Controller(决定横向扩展和实例数量的组件)。它具有内部算法,可根据当前利用率指标(例如队列大小和CPU负载)确定缩放参数。该算法不是公开的且不可配置。
答案 1 :(得分:2)
正如米哈伊尔(Mikhail)所说,您不能直接在消费计划中对其进行控制,但是您可以通过尽可能多地一次积压而不是点滴来“影响”它。
当降低maxConcurrentActivityFunctions时,它将导致它最终扩展到更多实例,但是在扩展频率和活动对CPU的使用量方面存在折衷。
如果它们占用大量CPU,那么我很想尝试将并发计数降低为1,因为同一节点上100%CPU上的并发计数将仅是每个节点上运行1的两倍,因此您可能会得到更多实例和更快的开始到结束时间。
绝对值得尝试,并且出于信息考虑,它只会分配新实例 根据文档,最多每10秒一次,我不确定100%是否一次只添加1个实例,但是我确定自己一次添加了1个以上?
哦,在App Service计划下,您可以一直运行200个实例,但是除非您期望它以24/7的速度运行,否则可能不会划算。