我正在使用 Naked Agility 提供的 Azure DevOps 迁移工具,并且它们运行良好。工作项正在迁移,但在短短几分钟内,我们就达到了速率限制的阈值。我自己不是开发人员,所以我不确定从哪里开始,或者是否有办法绕过这些限制。我们正在迁移大约 9000 个工作项,并在 4 天内迁移了大约一半,然后程序崩溃了。那么有没有人有关于如何加快速度的提示?
我现在重新开始迁移,它会跳过已经存在的迁移,但它仍然需要几天才能完成。
我正在使用 Naked Agility 提供的 Azure DevOps 迁移工具,并且它们运行良好。工作项正在迁移,但在短短几分钟内,我们就达到了速率限制的阈值。我自己不是开发人员,所以我不确定从哪里开始,或者是否有办法绕过这些限制。我们正在迁移大约 9000 个工作项,并在 4 天内迁移了大约一半,然后程序崩溃了。那么有没有人有关于如何加快速度的提示?
我现在重新开始迁移,它会跳过已经存在的迁移,但它仍然需要几天才能完成。
所以我尝试在 Azure 中使用 VM,设置与视频概述中的完全一样。从本地 VM 复制我的迁移器文件夹并重新启动迁移。10 分钟后,我收到了来自 DevOps 的邮件,说我的请求被延迟了:
2020 年 9 月 8 日上午 11:01(欧洲西部夏令时间),我们检测到您在https://dev.azure.com/orgname/上的资源消耗超出了我们的限制之一。为了维持其他用户的服务可用性,我们开始延迟您的一些请求。您的请求将继续延迟,直到您的资源消耗恢复到我们的限制以下。
我对可能导致这种情况的原因有更多的想法。
现在迁移在大约 30 分钟内到达了 45 个项目,并且自从重新启动后,它们都被跳过了。平均时间约为 38 秒,所以我预计当我们超过 60 秒时它会崩溃。
顺便说一句,该工具的最新版本(10.0)似乎不起作用。尽管它设置为 false,但在 NodeStructure 配置上崩溃。
没有办法限制速率限制,它们是为了保护服务的其他用户。如果您要迁移大量工作项,那么您肯定会遇到它们,并且运行速度会慢一些。
9000 个工作项不是很多,所以我认为它需要这么长时间。我建议从与目标服务器位于同一数据中心的 VM 运行 migration.exe。