长话短说
开发者都希望从部署在Azure的App Services中压榨出最佳性能，更好的性能不仅能够获得更佳的响应体验，而且如果性能提升的策略在Azure中能有“四两拨千斤”的效果，那么性能提升还可以为我们省钱。
在本文，我们将研究提高Azure App Services中运行的Web程序性能的设置和策略。
下面几个性能提升意见在App Service配置界面即可操作，这一组技巧的主题是
评估程序现状，压榨出程序本身性能。
1. 启动HTTP/2
Microsoft于2018年初宣布在App Services中支持HTTP/2，但到目前为止在Azure中默认创建的App Service还是以HTTP1.1协议工作。HTTP/2对常见的的Web协议进行了重大更改，许多更改旨在提高性能并减少Web延迟 (例如HTTP/2中的标头压缩和二进制格式将减少有效负载大小)；另外请求管道和多路复用等功能允许使用更少的网络套接字来执行更多并发请求，并有助于避免一个缓慢的请求阻止所有后续请求，这在HTTP1.1是常见问题。
如上图示，为你的的App Service启用HTTP/2协议，下拉列表指定HTTP2.0版本后，所有支持HTTP/2的客户端都将自动升级其连接，不支持HTTP/2的客户端仍然以原有Http1.1 方式交互。
下面是一个简单的测试以验证HTTP/2的改进：
某App Service托管页面引用了脚本、CSS资源、16张图像（每个图像的大小超过200 KB），使用developer tool记录使用HTTP 1.1在App Service发生的情况。
注意观察条形红色部分显示了后置请求以阻塞状态开始。这是可怕的“行头阻塞”问题，其中[对连接数和并发请求的限制] 制约了客户端和服务器之间的吞吐量，直到第一个请求开始后800毫秒，客户端才会收到该页面的最终字节。
接下来在App Service中启用了HTTP/2支持：
不需要对客户端或服务器上进行任何其他配置更改，不到500ms完成所有请求。由于HTTP/2提高了网络利用率，从而避免了阻塞。
2. 关闭空闲休眠
如果你有将应用程序部署到IIS的经历，那么你应该知道IIS在一段时间不活动之后将休眠（这个配置在IIS理默认是20分钟）。
Azure App Service延续了这一传统。尽管休眠可为在同一App Service Plan上运行的其他App Service提供资源，但是此策略会损害当前应用程序的性能，因为下一个传入请求将经历Web服务器冷启动的过程：缓存为空、连接池为空，站点预热，所有请求的速度都比正常情况慢。为了防止空闲休眠，你可以在"App Service配置"中【始终开启】标志。
3. 关闭App Service实例亲和力
即使你仅运行App Service Plan的单实例，每个Azure App Service前面都是负载平衡器，负载均衡器会转发请求到App Service实例。当App Service因流量缩放出多实例，负载均衡器使用Application Request Routing将连接会话分发给实例。
因为Azure无法知晓应用程序是不是stateless服务，故默认的App Service将确保客户端在会话期间访问同一App Service实例，为了实现这种亲和力，负载均衡器会在对客户端的第一个响应中注入ARRAffinity Cookie。
如果你的应用程序是stateless，并允许负载平衡器在实例之间分配请求，请关闭请求路由cookie，以提高性能和弹性。
下面的改进需要一些其他网络规划或重组（某些情况下，还需要更改应用程序本身）\
这一组技巧中的主题是缩短数据在网络上传输的距离
4. 让你的服务资源相距更近
比如常规的WebApi服务，需要搭建App Service和Database，建议你把资源放在同一区域协同工作,不然一次请求，处理链路会满世界跑。
5. 让你的App Service与使用者更接近
如果大多数客户流量都来自世界的特定区域，则将资源放置在离客户最近的Azure区域中是很有意义的。当然，我们许多人的客户分布在世界各地。在这种情况下，您可以考虑跨多个Azure区域进行地理复制，以与每个人保持更近距离，之后你使用类似Azure Traffic Manager（基于DNS技术的负载均衡器）将你的客户直接路由到最近的服务实例。
6. 让你的服务内容与使用者更接近
脚本、图片、CSS，视频等静态资源是在CDN边缘服务器上缓存的较好选择，一旦缓存，Azure App Service不需要花费带宽和时间在这些资源上，专注处理动态资源。
回过头来，看以上性能优化建议，第一步还是要评估App Service当前现状和性能，不是每一个策略都对你的App Service有效。
btw 这些策略对于常规企业级部署依旧有所指引。
