超狂.超提升ASP.NET Web API效能的8種方法(有沒有100倍呀?)

超狂.超提升ASP.NET Web API效能的8種方法(有沒有100倍呀?)

看到一篇 8 ways to improve ASP.NET Web API performance 覺得整理的不錯,順手簡單整理與寫點心得。

  1. 使用最快的 JSON 序列化套件

ASP.NET Web API 預設採用 JSON.NET。JSON.NET 求穩不求快,如果要求快,透過 ASP.NET Web API 優秀擴充點機制,可隨時更換序列化套件。

之前在 Blog 介紹過 Jil

8 Ways作者則是採用 ServiceStack.Text 套件。

JSON Serialization 速度

圖片來源:theburningmonk.com

ASP.NET Core Debugging Breakpoint not hit?

ASP.NET Core Debugging Breakpoint not hit?

同事反應,ASP.NET Core 專案無法正常進行中斷點(breakpoint)偵錯。簽出專案,下中斷點偵錯取得以下資訊:

breakpoint not hit

The breakpoint will not currently be hit. No symbols have been loaded for tis document.

如果這時你下關鍵字「asp.net core breakpoint」去搜尋,在第一筆你就能找到解決方案。

他的解決方案是叫你「關閉:Enable Just My Code」與「開啟:Microsoft symbols Server」。

如果這樣就解決了,那我還要寫這篇嗎?

POST GZIP/Deflate Data to ASP.NET Web API

POST GZIP/Deflate Data to ASP.NET Web API

前一篇使用GZIP或DEFLATE壓縮,提升資料傳遞效能40倍,我們處理了查詢資料量大時,Web API 在傳遞未經壓縮的資料產生許多不必要的網路流量的問題。現在我們轉換方向,如果是用戶端要傳遞大量資料至 Web API 時,那麼我們要怎麼處理?這比較麻煩,有二個方向要討論,一是 Client 端進行發送請求時,必須先做 GZIP/Deflate 的壓縮,而 Web API 接收到 GZIP/Deflate 壓縮資料後需要解壓縮還原資料內容。

從這個方向來思考,你應該能發現另一件事,就是前一篇我們只專注在 GZIP/Deflate 的壓縮上,並無做任何解壓縮的工作,那是因為瀏覽器本身在協商過程與接收到的 Header 可以判定接收到的是 GZIP/Deflate 的內容,瀏覽器會直接幫我們進行 GZIP/Deflate 的解壓縮工作。

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