上一篇文章說明了使用 EF6 的 Intercepting 與 NLog 來紀錄觀察分頁的執行內容與效能，在文末也提到 MiniProfiler 與 Clutch.Diagnostics.EntityFramework 目前尚未支援 EF6，如果不想使用 EF6 Intercepting 的話，其實還可以使用 Glimpse.EF 來觀察，Glimpse 在兩年多前也曾經寫文章介紹過，但可能當時界面與功能還蠻陽春，所以注意的人不是很多（文章的瀏覽數量都少少的），不過在去年開始進行了界面的改版而且版本更新進度也變得頻繁（因為 redgate 投入支援），另外也因為有提供介面讓開發者可以開發其他功能，所以有許多相當實用的功能可以使用，而且不限定 ASP.NET MVC 才能使用，提供 ASP.NET WebForm 的功能也相當豐富與使用，有興趣的朋友可以玩玩看。
這一篇就來介紹怎麼使用 Glimpse 與 Glimpse.EF 來觀察分頁的執行。
這陣子有網友詢問為何使用 PagedList.Mvc 所執行的效能為何會相當緩慢，而在看過程式碼後並未發現到有做任何特殊的處理或複雜的操作，就只是從 DbContext 將資料取出後再使用 ToPagedList() 方法取得分頁資料，另外我也曾建議他可以使用 LINQPad 去做單純的 EF 取得資料的觀察，這麼做是要將資料存取的環境給單純化，排除 ASP.NET MVC 環境的影響，而這位朋友回報說在 LINQPad 執行 EF 的取得資料處理是很快的，因為這位網友只給我看 Controller 裡 Action 方法的程式內容而已，我無從了解前端 View 是否有做其他的處理，所以我也不知道造成執行效能緩慢的原因為何。
無論使用 MvcPaging 或是 PagedList.Mvc，在取得分頁資料的操作處理上我並沒有遇到這樣的狀況，這些分頁套件並不是造成效能緩慢的主因，因為在我所處理過上萬筆甚至上百萬筆資料的分頁操作都不曾發生這樣的事情，其實造成效能緩慢的原因有很多可能，所以就必須一個一個去找尋原因，例如說將 PagedList.Mvc 從網站裡移除，然後觀察一次取得所有資料是否緩慢、使用 Skip Take 方法取得部份資料是否緩慢、不使用 EF 而直接使用 ADO.NET 執行 SQL Command、調整資料庫的設計或加上索引等，藉由這些的方式將原因給找出，而不是直接懷疑或認定 PagedList.Mvc 就是兇手。
這一篇簡單說明在 ASP.NET MVC 5 使用 EF 6 的 Intercepting 功能來觀察 PagedList.Mvc 的處理與執行的時間。
