ASP.NET Web API:使用GZIP或Deflate壓縮,提升資料傳遞效能40倍

ASP.NET Web API使用GZIP或Deflate壓縮,提升資料傳遞效能40倍

未壓縮資料量

專案有個查詢資料量不小,基本測試資料每次約1.92 MB,透過 ASP.NET Web API 傳遞至 Client 端每次就是 1.92 MB 的網路傳遞量,而且未來上線後,資料量只會越來越大,直覺感到不對勁(壞味道)。

IIS的動態壓縮靜態壓縮對 ASP.NET Web API 是無效的。而且,平常 ASP.NET Web API 的請求,資料負載量也不是很大,那種 KB 級的資料壓縮率不高,平常也就沒特別注意。不過在 MB 級的資料,有無啟用 GZIP 或 Deflate 壓縮的資料量差異,直接說結果,以我實測得到的數據差了40倍

如何在Visual Studio 2017中編輯Global.asax

如何在Visual Studio 2017中編輯Global.asax

某個專案進行重構,異動部分較大,連方案、專案檔都重新命名,進而影響命名空間。全部整理完之後,重新建置正常,但執行確出現一個Global.asax錯誤。

global.asax error

線上網站很慢!使用DebugDiagnostic Tool進行線上IIS網站程式效能分析

線上網站很慢!使用DebugDiagnostic Tool進行線上IIS網站程式效能分析

我們有個專案的架構如下:

JS Framework <--> ASP.NET MVC <--> ASP.NET Web API(Service) <--> UDSP <--> ASP.NET Web API(Authorzation)

專案網站有個怪問題,如果網站2到3小時的時間無人使用,那麼閒置時間後第一個第一次使用的人會特別慢。針對IIS的Application Pool的啟動模式由OnDemand改為AlwaysRunning,針對IIS站台的預先載入也已經修改為true,但效果有限。相關停頓、反應時間過長等情境在本地端(Local)模擬不出來,由於分層(tier)過多追起來費時費工。

有無什麼好辦法,可以針對發行至IIS的站台進行線上的偵錯?有的,目前我知道的有三種方法:

  1. WinDBG
  2. IntelliTrace Collector
  3. DebugDiagnostic Tool

WinDBG功能強大,但指令參數複雜,而且取得Dump檔的過程不是那麼友善。針對這樣的問題,WinDBG近期有推出一支Microsoft Store App - WinDBG Preview,可以透過GUI來查詢分析Dump檔案。IntelliTrace Collector也是強大,但推廣不易,因為IntelliTrace定位在Visual Studio企業版才能使用。DebugDiagnostic Tool是本篇的主角,選擇它的原因很簡單,第一、它安裝與使用容易。第二、它收集Dump容易。第三、它分析Dump容易。

首先,你必須先下載Debug Diagnostic Tool v2 Update 2並安裝至IIS所在的伺服器上。安裝好會多三套工具,DebugDiag 2 Collection、DebugDiag 2 Analysis、DebugDiag 2 RuleBuilder(beta)。

Project Template使用前請詳閱公開說明書

Project Template使用前請詳閱公開說明書

前篇「.NET開發者,你應該養成用空白範本寫正式專案」引起不少正反討論。其中有提到到團隊專案範本幾個字,fb討論我留下:「template有好有壞,好的是有規範,壞的是沒有創新與創意。但創新與創意又常常是重構的來源...」這句話,意外得到另一主題回應。我想就團隊專案範本來做另一主題說明,我為什麼會做這樣留言。


.NET開發者,你應該養成用空白範本寫正式專案

.NET開發者,你應該養成用空白範本寫正式專案

這是一篇有感而發的短文。

最近又在做效能調教的工作,在單一個專案內我移除了近30個無用的NuGet套件。其實不用問,一眼就能看出,這是一個從預設專案範本開始寫的專案。用專案範本有錯嗎?嗯,沒錯,也有錯。原因,最後在說。我們先來看看之前 twMVC#22分享主題:「一個微信專案從0到000的效能調教」的幾張投影片。