看到一篇 8 ways to improve ASP.NET Web API performance 覺得整理的不錯，順手簡單整理與寫點心得。
ASP.NET Web API 預設採用 JSON.NET。JSON.NET 求穩不求快，如果要求快，透過 ASP.NET Web API 優秀擴充點機制，可隨時更換序列化套件。
之前在 Blog 介紹過 Jil：
8 Ways作者則是採用 ServiceStack.Text 套件。
圖片來源：theburningmonk.com
同事反應，ASP.NET Core 專案無法正常進行中斷點(breakpoint)偵錯。簽出專案，下中斷點偵錯取得以下資訊：
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」。
如果這樣就解決了，那我還要寫這篇嗎？
前一篇使用GZIP或DEFLATE壓縮，提升資料傳遞效能40倍，我們處理了查詢資料量大時，Web API 在傳遞未經壓縮的資料產生許多不必要的網路流量的問題。現在我們轉換方向，如果是用戶端要傳遞大量資料至 Web API 時，那麼我們要怎麼處理？這比較麻煩，有二個方向要討論，一是 Client 端進行發送請求時，必須先做 GZIP/Deflate 的壓縮，而 Web API 接收到 GZIP/Deflate 壓縮資料後需要解壓縮還原資料內容。
從這個方向來思考，你應該能發現另一件事，就是前一篇我們只專注在 GZIP/Deflate 的壓縮上，並無做任何解壓縮的工作，那是因為瀏覽器本身在協商過程與接收到的 Header 可以判定接收到的是 GZIP/Deflate 的內容，瀏覽器會直接幫我們進行 GZIP/Deflate 的解壓縮工作。
專案有個查詢資料量不小，基本測試資料每次約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倍。
某個專案進行重構，異動部分較大，連方案、專案檔都重新命名，進而影響命名空間。全部整理完之後，重新建置正常，但執行確出現一個Global.asax錯誤。
