這篇文章將為大家詳細(xì)講解有關(guān)提升Azure App Service的幾個(gè)建議分別是什么，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。

成都創(chuàng)新互聯(lián)主要從事網(wǎng)站設(shè)計(jì)、網(wǎng)站建設(shè)、網(wǎng)頁(yè)設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)謝通門,10余年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來(lái)電咨詢建站服務(wù):18980820575

小編介紹了6個(gè)技巧，這些技巧可以改善Azure App Service托管應(yīng)用程序的性能。其中一些技巧是你現(xiàn)在就可以進(jìn)行的配置變更，而其他技巧則可能需要對(duì)應(yīng)用程序進(jìn)行一些重新設(shè)計(jì)和重構(gòu)， 這幾個(gè)技巧對(duì)于常規(guī)企業(yè)部署依舊有指引作用。

    開發(fā)者都希望從部署在Azure的App Services中壓榨出最佳性能，更好的性能不僅能夠獲得更佳的響應(yīng)體驗(yàn)，而且如果性能提升的策略在Azure中能有“四兩撥千斤”的效果，那么性能提升還可以為我們省錢。
在本文，我們將研究提高Azure App Services中運(yùn)行的Web程序性能的設(shè)置和策略。

下面幾個(gè)性能提升意見在App Service配置界面即可操作，這一組技巧的主題是

評(píng)估程序現(xiàn)狀，壓榨出程序本身性能。

1. 啟動(dòng)HTTP/2

Microsoft于2018年初宣布在App Services中支持HTTP/2，但到目前為止在Azure中默認(rèn)創(chuàng)建的App Service還是以HTTP1.1協(xié)議工作。HTTP/2對(duì)常見的的Web協(xié)議進(jìn)行了重大更改，許多更改旨在提高性能并減少Web延遲 (例如HTTP/2中的標(biāo)頭壓縮和二進(jìn)制格式將減少有效負(fù)載大小)；另外請(qǐng)求管道和多路復(fù)用等功能允許使用更少的網(wǎng)絡(luò)套接字來(lái)執(zhí)行更多并發(fā)請(qǐng)求，并有助于避免一個(gè)緩慢的請(qǐng)求阻止所有后續(xù)請(qǐng)求，這在HTTP1.1是常見問(wèn)題。

如上圖示，為你的的App Service啟用HTTP/2協(xié)議，下拉列表指定HTTP2.0版本后，所有支持HTTP/2的客戶端都將自動(dòng)升級(jí)其連接，不支持HTTP/2的客戶端仍然以原有Http1.1 方式交互。

下面是一個(gè)簡(jiǎn)單的測(cè)試以驗(yàn)證HTTP/2的改進(jìn)：

某App Service托管頁(yè)面引用了腳本、CSS資源、16張圖像（每個(gè)圖像的大小超過(guò)200 KB），使用developer tool記錄使用HTTP 1.1在App Service發(fā)生的情況。

注意觀察條形紅色部分顯示了后置請(qǐng)求以阻塞狀態(tài)開始。這是可怕的“行頭阻塞”問(wèn)題，其中[對(duì)連接數(shù)和并發(fā)請(qǐng)求的限制] 制約了客戶端和服務(wù)器之間的吞吐量，直到第一個(gè)請(qǐng)求開始后800毫秒，客戶端才會(huì)收到該頁(yè)面的最終字節(jié)。

接下來(lái)在App Service中啟用了HTTP/2支持：

不需要對(duì)客戶端或服務(wù)器上進(jìn)行任何其他配置更改，不到500ms完成所有請(qǐng)求。由于HTTP/2提高了網(wǎng)絡(luò)利用率，從而避免了阻塞。

2.  關(guān)閉空閑休眠

如果你有將應(yīng)用程序部署到IIS的經(jīng)歷，那么你應(yīng)該知道IIS在一段時(shí)間不活動(dòng)之后將休眠（這個(gè)配置在IIS理默認(rèn)是20分鐘）。

Azure App Service延續(xù)了這一傳統(tǒng)。盡管休眠可為在同一App Service Plan上運(yùn)行的其他App Service提供資源，但是此策略會(huì)損害當(dāng)前應(yīng)用程序的性能，因?yàn)橄乱粋€(gè)傳入請(qǐng)求將經(jīng)歷Web服務(wù)器冷啟動(dòng)的過(guò)程：緩存為空、連接池為空，站點(diǎn)預(yù)熱，所有請(qǐng)求的速度都比正常情況慢。為了防止空閑休眠，你可以在"App Service配置"中【始終開啟】標(biāo)志。

3. 關(guān)閉App Service實(shí)例親和力

即使你僅運(yùn)行App Service Plan的單實(shí)例，每個(gè)Azure App Service前面都是負(fù)載平衡器，負(fù)載均衡器會(huì)轉(zhuǎn)發(fā)請(qǐng)求到App Service實(shí)例。當(dāng)App Service因流量縮放出多實(shí)例，負(fù)載均衡器使用Application Request Routing將連接會(huì)話分發(fā)給實(shí)例。

因?yàn)锳zure無(wú)法知曉應(yīng)用程序是不是stateless服務(wù)，故默認(rèn)的App Service將確?？蛻舳嗽跁?huì)話期間訪問(wèn)同一App Service實(shí)例，為了實(shí)現(xiàn)這種親和力，負(fù)載均衡器會(huì)在對(duì)客戶端的第一個(gè)響應(yīng)中注入ARRAffinity Cookie。

如果你的應(yīng)用程序是stateless，并允許負(fù)載平衡器在實(shí)例之間分配請(qǐng)求，請(qǐng)關(guān)閉請(qǐng)求路由cookie，以提高性能和彈性。

下面的改進(jìn)需要一些其他網(wǎng)絡(luò)規(guī)劃或重組（某些情況下，還需要更改應(yīng)用程序本身）

這一組技巧中的主題是縮短數(shù)據(jù)在網(wǎng)絡(luò)上傳輸?shù)木嚯x

4. 讓你的服務(wù)資源相距更近

    比如常規(guī)的WebApi服務(wù)，需要搭建App Service和Database，建議你把資源放在同一區(qū)域協(xié)同工作,不然一次請(qǐng)求，處理鏈路會(huì)滿世界跑。

5. 讓你的App Service與使用者更接近

    如果大多數(shù)客戶流量都來(lái)自世界的特定區(qū)域，則將資源放置在離客戶最近的Azure區(qū)域中是很有意義的。當(dāng)然，我們?cè)S多人的客戶分布在世界各地。在這種情況下，您可以考慮跨多個(gè)Azure區(qū)域進(jìn)行地理復(fù)制，以與每個(gè)人保持更近距離，之后你使用類似Azure Traffic Manager（基于DNS技術(shù)的負(fù)載均衡器）將你的客戶直接路由到最近的服務(wù)實(shí)例。

6. 讓你的服務(wù)內(nèi)容與使用者更接近

    腳本、圖片、CSS，視頻等靜態(tài)資源是在cdn邊緣服務(wù)器上緩存的較好選擇，一旦緩存，Azure App Service不需要花費(fèi)帶寬和時(shí)間在這些資源上，專注處理動(dòng)態(tài)資源。

回過(guò)頭來(lái)，看以上性能優(yōu)化建議，第一步還是要評(píng)估App Service當(dāng)前現(xiàn)狀和性能，不是每一個(gè)策略都對(duì)你的App Service有效。

btw 這些策略對(duì)于常規(guī)企業(yè)級(jí)部署依舊有所指引。

關(guān)于提升Azure App Service的幾個(gè)建議分別是什么就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。