添加链接
link之家
链接快照平台
  • 输入网页链接,自动生成快照
  • 标签化管理网页链接
相关文章推荐
骑白马的领带  ·  将 Azure Active ...·  1 年前    · 
不羁的小刀  ·  gcc ...·  2 年前    · 
打盹的斑马  ·  Android studio ...·  2 年前    · 

We are developing a java SpringBoot application and we deploy it to an app service. We were planning on using staging slots to achieve zero down time deployments, but when I started testing deploying our spring boot app to the staging slot, I noticed that that the start up process for spring boot consumes up to 90-95% of the CPU available. And as the production slot and and staging slot share the same application service plan, this means that the production slots have 90-95% CPU usage, which kills the average response times for clients connecting to our production slot.

This all means that staging slots don't achieve zero down time for us, as until the staging slot instances have booted up spring boot and calmed down our production slot is being severely affected. I have not found any way to use a separate app service plan for the staging slot but has anyone else faced this issue and found any solution?

You can't use a separate app service plan for a deployment slot. I'm afraid your options are limited. I would first enable logging in conjunction with Application Insights to determine what's the root cause of the high CPU usage on application startup. The only option I can really think of is scaling your app service plan and utilizing CPU above 85% to trigger a scale out so your production app can still respond to requests. Another option is scaling your app service plan up, I suggest, by worker size, e.g., if you're currently running an S1 then scale up to S2 and so forth and monitor performance. You may also find this blog post helpful as it discusses minimize cold starts which doesn't address the root cause but may help mitigate it.

Hi Ryan,

Thanks for a quick reply! I did try scaling up my ASP by increasing instances but that didn't solve the issue as each production slot instance, is a staging slot instance that needs to start up the new version of our spring boot code, and each instance consumes too much CPU during startup. I also tried using other types of instances P1V3 instead of P1V2 to see if that made a difference but it only had a very slight difference.

The solution I landed in is that I have two app service instances with difference app service plans. My pipeline then alternates in deploying between them so that one acts as a staging instance to the other. Once the staging instance is deployed and warmed up the pipeline modifies my Traffic manager profile to direct traffic to the now warmed up app service, and finally the pipeline scales down the old app service to minimize cost, and then calls a function app to to store in a Redis DB which is app service is currently handling production traffic. This is necessary because the next time the pipeline runs it will first check which app service is handling the production traffic, so that it deploys the new code to the other instance.

Basically I'm reproducing the staging slot functionality, but in way where the staging slot can have a separate app service plan.

/Anders