我们有一个用于内部报告的Azure web应用程序，在99%的情况下，它可以处理最低定价层(3.5 GB RAM)所需的所有流量/请求。
但是有一个特定的请求来生成一个Excel报表，临时需要大约8 GB的RAM来服务(closesedxml是一个野兽，我们已经尽可能地最小化了RAM占用的峰值)。不幸的是，这不仅需要下一个定价层(7GB)，还需要再下一个定价层(14gb)。
这个请求只需要1分钟的服务，所以在尝试了其他所有方法之后，我正在考虑使用Azure api在请求进入时以编程方式更改应用程序服务计划，等待10秒左右的时间让它启动，然后处理请求，然后缩减规模。
这是一种合理的方法，还是有一些我不知道的其他功能来临时执行内存消耗操作?我考虑过Azure的功能，但我读到它们的内存限制在1.5GB…据我所知，如果不成为操作压缩xml底层Excel工作簿的专家，就不能以任何方式细分这项工作。
听起来很合理，我们正在做类似的事情，我们在运行大规模的月度导入之前扩大规模，我们扩大前端函数和后端CosmosDB，然后在导入完成后再次缩小规模，所以我认为这样做不会有任何问题。
顺便说一下，azure功能没有1.5 GB的限制，它完全取决于底层托管解决方案，您可以在P3V3应用程序服务计划或更大的专用计划上托管功能，并从他们提供的资源中受益，但这是另一个主题。
AppService (Plan)没有开箱。在类似的情况下，我们从一个自动化帐户开始，但升级到LogicApps。
使用LogicApp作为请求代理，对于特定类型的操作调用https://learn.microsoft.com/en-us/rest/api/appservice/app-service-plans/update来扩大AppService计划，并在成功完成后缩小规模。顺便说一句，在暴露url之前，也要在APIM上托管LogicApp !