This article describes several tips that can improve the performance of Azure App Service hosted application. Some of these skills are configuration changes you can now performed,
While other techniques may require some redesign and reconstruction of the application.
Developers want to deploy Azure from the App Services in squeezing the best performance.
Better performance can not only get a better response experience; and if we Azure, can "skillfully deflected the question," then we can also improve the performance of money.
In this article, we will examine strategies to improve the settings and performance of Web applications running in Azure App Services.
Here a few comments in App Service performance configuration interface can be operated, the theme of this skill set is squeezing out performance App Service itself.
1. Start HTTP / 2
Microsoft announced in early 2018 to support HTTP / 2 in the App Services but so far created by default App Service is working to HTTP1.1 agreement in Azure. HTTP / 2 against common Web protocols made significant changes, many changes designed to improve performance and reduce latency on the Web. For example, the HTTP / 2 and binary format header compression to reduce the size of the payload. Further multiplexing request pipeline and functions to allow for more concurrent requests performed using fewer network sockets, and helps to avoid a slow request block all subsequent requests, which is a common problem in HTTP 1.1.
You start the App Service HTTP / 2 protocol, as shown above, after the drop-down list specifies HTTP2.0 version, all supported client HTTP / 2 will automatically upgrade their connection, the client does not support HTTP / 2 is still interact Http1.1 original way.
HTTP / 2 will not benefit each application, the following is a simple test to verify the improved HTTP / 2 of:
App Service hosted a page reference script, CSS resources, 16 images, each image size exceeds 200 KB.
Use developer tool records the use of HTTP 1.1 occurred on the 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，以提高性能和弹性。
--------------------------------------------------------------------------------
下面的改进需要一些其他网络规划或重组（某些情况下，还需要更改应用程序本身）
下一组技巧中的主题是缩短数据在网络上传输的距离
- 让你的服务资源相距更近，比如常规的WebApi服务，需要搭建App Service 和Database，建议你把资源放在同一区域协同工作。
-
让你的App Service 与使用者更接近
如果大多数客户流量都来自世界的特定区域，则将资源放置在离客户最近的Azure区域中是很有意义的。当然，我们许多人的客户分布在世界各地。在这种情况下，您可以考虑跨多个Azure区域进行地理复制，以与每个人保持亲密关系，之后你使用类似Azure Traffic Manager（基于DNS技术的负载均衡器）将你的客户直接路由到 最近的服务实例。
-
让你的服务内容与 使用者更接近
脚本、图片、CSS，视频等静态资源是在CDN边缘服务器上缓存的较好选择，一旦缓存，Azure App Service 不需要花费带宽和时间在这些资源上，专注处理动态资源。
Azure支持CDN边缘服务器的搭建
回过头来，看以上性能优化建议，第一步还是要评估当前App Service现状和性能，不是每一个策略都对你的App Service 有效。