NanoProfiler 對於資料庫存取的監控 - Entity Framework

之前連著兩篇介紹了 NanoProfiler.Data 在 ADO.NET 與 Dapper 的專案裡的使用情境與安裝說明，而這一篇就接著介紹專案使用 Entity Framework 與 NanoProfiler 的說明。

 

---

NanoProfiler 對於資料庫存取的監控 - Dapper

上一篇「NanoProfiler 對於資料庫存取的監控 - ADO.NET」的最後有講到使用 ADO.NET 進行資料存取處理雖然可以使用 NanoProfiler 將程式的執行效能作監控，但是卻無法將執行的 T-SQL 內容給記錄起來，所以算是一個未完成品。

現在這一篇則是改用 Dapper 取代 ADO.NET 的操作，然後再使用 NanoProfiler.Data 去進行資料存取的監控並且將執行的 T-SQL 給記錄起來。

 

---

NanoProfiler 對於資料庫存取的監控 - ADO.NET

前一篇「使用 NanoProfiler 對 ASP.NET Web API 進行性能監控」介紹了 NanoPrifiler 這個套件，讓我們可以在 ASP.NET MVC / WebAPI 或 WCF 等專案裡去監控程式執行的效能，因為是第一篇，所以只有簡單的說明怎麼在 Controller 類別的 Action 方法裡的使用方式，所以在 NanoProfiler 的 Profilering Result 頁面裡只有呈現 Controller 的 Action 裡被 ProfilingSession 給包起來的程式執行數據。

很多人誤會說只要在某個地方用程式給包起來之後就會將有用到的所有程式效能數據都能夠抓出來，這…… 真的有點誤會了，其實 NanoProfiler 並沒有如此厲害，要是真的那麼厲害的話，這樣的程式也太恐怖了些，其實效能數據的監控並不是全部程式的執行效能數據都抓出來就可以讓我們了解程式的狀況，因為太多的數據呈現反而會失去焦點與意義，而是應該對於執行效能有疑慮或是要詳加注意的部分再去做監控就可以。所以 NanoProfiler 的效能監控是由我們來決定那些程式需要被監控，有需要監控的地方再去把程式給包起來就好。

這一篇來說明對於使用 ADO.NET 進行資料庫存取的 Repository 要如何使用 NanoProfiler.Data 去做到監控與執行 T-SQL 的記錄呈現。

 

使用 NanoProfiler 對 ASP.NET Web API 進行性能監控

在開發 ASP.NET MVC 網站的時候，我會使用 MiniProfiler 或 Glimpse 來監控每一個頁裡各種功能的執行性能，這在之前有寫了多篇文章作介紹，然後也在 twMVC#15 以「開發的效能與效率」這個 Session 裡也做了介紹和說明。但是到了開發 ASP.NET Web API 服務的時候，因為沒有頁面，所以也就無法使用 MiniProfiler 或 Glimpse 等工具去對每次的 API 執行去做監控，以致於就會相當仰賴 Log 記錄，在想要監控的程式片段去計算執行時間與寫入 Log，但是這樣的方式相當沒有效率，而且事後去查看 Log 也要當浪費很多時間才能把相關數據給整理出來。

在 2014 年底，我在 Nuget 的 Release 訊息裡發現了一個名為「NanoPrifiler」的套件，當時的介紹文章相當少，大概只有作者部落格裡的兩篇文章（第三篇文章還是到了 2015 年八月才發佈），而且我在 2014 年看到的時候還沒有放在 Github 分享出來（原本一開始有放在 Github 上，但是後來又關閉，現在已經重新公開），一開始我是被他的介紹與文章說明給吸引，直覺這個套件就是我所想要的，所以花了一點時間去研究，接著在 2015 年初就全面導入到專案開發裡，甚至於之後公司裡幾個後續所開發的 ASP.NET Web API 專案也都導入使用 NanoProfiler。

在 2015 年 12 月裡所舉行的 twMVC#21，我在主講的「以實例說明 ASP.NET Web API 服務的開發與測試過程」裡就有將 NanoProfiler 介紹給大家，而到了現在才有時間將使用、安裝的說明給整理出來，所以將會有一系列的文章說明如何使用 NanoProfiler。

 

---

ASP.NET MVC Elmah Dashboard - 查看 Elmah 存在 SQL Server 的記錄

無論是 ASP.NET WebFroms or MVC or WebApi，我都會在專案裡安裝使用 Elmah 來攔截紀錄例外錯誤，這個部落格裡也有很多篇文章在說明，Elmah 這套件真的是一個歷史悠久的工具，早在 2004 年就已經出現了，但是我真的很意外居然蠻多人是聽都沒有聽過，甚至有許多人是不懂為何要來攔截記錄錯誤（我就完全不懂這些人是如何知道網站發生了什麼例外錯誤，而且怎麼去做分析與修復？），有些團隊雖然沒有使用過 Elmah 而是選擇自己建立錯誤處理機制或是使用其他的錯誤攔截記錄機制，不管如何，例外錯誤的處理是不能夠掉以輕心的，問題往往都能夠從這些有被紀錄的 Exception 裡去被發現。

雖然 Elmah 有提供一個基本的記錄顯示介面，可以讓我們看到有哪些 Exception 被記錄下來，但長久下來要在一大多的 Exception Record 裡去找出問題或是作分析就會是一大難題，因為這個基本的顯示介面是相當陽春的，如果有將這些記錄存在 SQL Server 裡的話，還可以在 SSMS 裡去下 T-SQL 做資料查詢，但是要要查個 Exception 紀錄還要開啟 SSMS 也是蠻累人的，尤其是有些團隊的環境裡是不允許開發人員直接連接正式環境的 SQL Server，所以就無法使用 SSMS 去做查詢了。

如果有將 Elmah 所攔截的例外錯誤給存放到「SQL Server」的團隊，這邊向你們介紹一個簡單方便的套件「ASP.NET MVC ELMAH Dashboard」

 

---