我有一個 WebUserControl 從 SQL 獲取記錄并存盤在 ViewState 中，到目前為止效果很好。但是現在我有一個包含 100k 記錄的資料集，我注意到在每次 PostBack 時 XHR 請求都會下載所有資料并且非常慢，如果我將資料存盤在 Session 中就不會發生這種情況，所以我會問存盤這么多資料是否合適在會話變數中？
我的測驗：
- Viewstate： ViewState 網路回應
- 第一個請求讀取資料并存盤在 ViewState 中（時間：11s，大小：119MB）
- 第二個請求是一個通用的回發，對視圖狀態沒有任何作用，盡管如此，接收回復需要很長時間并下載大量資料（時間：15s，大小：119MB）
- 總計：26 秒，238MB
- 會話： 會話網路回應
- 第一個請求讀取資料并存盤在Session內部（時間：7s，大小：123kB）
- 第二個請求是一個通用的回發，它對 Session 不做任何事情并且速度很快（時間：60ms，大小：122kB）
- 總計：7 秒，244kB
在這個測驗之后，我的意思是，將資料存盤在 Session 而不是 ViewState 中似乎要好得多，檢索資料和為每個請求下載更少的資料更快，但我不完全確定這是一個好習慣，也許我忽略了更好的方法來做到這一點。我希望這很清楚，英語不是我的第一語言，對此感到抱歉。
uj5u.com熱心網友回復：
你說得很對。事實上，我什至發現整個頁面大小可以超過 web config 中設定的回發限制。
但是，有兩個重要問題：
正如評論中指出的那樣，用這么多資料加載 session() 也是一個非常糟糕的主意。
接下來：
你真的需要在 session() 中存盤那么多資料嗎？雖然您指出了性能的巨大提升 - 您仍然在 Web 服務器上施加了非常大的負載。這會消耗 session() 記憶體，如果使用基于 sql server 的會話，那么你將在 sql server 上施加相當大的負載（該 blob 資料由 .net 序列化，然后保存到一行sql server 會話狀態——這又將是 sql server 上非常難以加載的負載——甚至“序列化”到會話中的時間也需要一些時間）。
一個頁面上真正可以顯示多少行資料？30頂？
現在，對于幾 1000 行，我什至不敢使用 ViewState。它只是簡單地加載和膨脹網頁太多。
并且只有說 1000 行和網格視圖（或串列視圖）的資料分頁，那么這可以作業。
但是，超過 1000 行？
您甚至不能在同一個星球上加載那 100k 行。這根本不可能。
想想谷歌，甚至任何其他軟體——網路或桌面。
我們不下載整個互聯網，然后說你使用 ctrl-f 搜索巨大的怪物頁面資料。
這也是一樣。
那么，這到底意味著什么？
您必須轉儲內置資料尋呼機，并撰寫自定義代碼。
您可以使用最新版本的 sql server（2012 及更高版本）可以使用所謂的 sql server 資料分頁。因此，這意味著我們希望讓 SQL Server 進行資料分頁，而不是加載整個大資料，然后嘗試分頁該資料。嘗試一次性處理這么多資料是不切實際的——至少從 UI 的角度來看是這樣。
（無論如何，用戶如何一次處理 100,000 行 - 這實際上是不可能的。
這意味著，如果您的頁面有 30 行？那么，您甚至不需要 ViewState 或會話。您從 100,000 行中僅提取 30 行，您的表現將是即時的。您的頁面將在不到一秒的時間內加載（和資料頁面）！！！
并且您減少了服務器上的大量記憶體使用，并且您還如前所述，減少了視圖狀態的大小。（你只說 30 行 - 有了它，你甚至發現讓 gridview/list 視圖繼續使用視圖狀態（它們擁有的自動視圖狀態）。
因此，請查看 sql server 端分頁的概念。您仍然可以拼湊看起來像資料尋呼機的東西，并且可以獲取（計算）該表中的總行數，但您只能說一次提取 30 行。
此處概述了其作業原理：
在 SQL Server 中對結果進行分頁的最佳方法是什么
And the above link and post outlines some alternative approaches if you don't have sql server 2012 or later. I am of the view and position that using the newer "paging" features of 2012 is the simple approach, despite that some solutions posted in above are noted to be even faster.
So, you have to build a pager here. You can roll your own, but at the end of the day, the built in paging system is REALLY only for better UI performance, and really only works for about 1000 rows of data. after that, you need to adopt a paging system, and your software and users will love you for this - since everything will respond and run quite much as fast as you can click the mouse. You don't even need to adopt ajax calls for this, but you do have to cut down the rows pulled from SQL server - down to 30 or 20 or however many rows your grid displays at one time.
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/450848.html