在asp.net會話中存儲DataTable對象的不好主意

我知道在asp.net中將DataTable存儲在會話變量中是不好的，因爲它會使用很多服務器的內存。我不明白的是，那麼你會怎麼做時：在asp.net會話中存儲DataTable對象的不好主意

用戶來到一個網頁，它需要加載一個DataTable對象（從SQL Server）。
用戶單擊簡單事件的單選按鈕（例如某些控件被禁用）。
如果您不保存會話中的DataTable對象，則必須在同一頁面上回發時再次從SQL服務器加載它，而不是僅從會話中獲取它？

感謝您的幫助。

來源

2011-07-04 tony

爲什麼不使用ASP.NET控件的ViewState在回發中保留這些值？這是標準方法，並且會比在Session中存儲（具有許多用戶）或使用ViewState存儲完整的DataTable的性能問題少。 –

剛剛問了一些問題，並且接受了答案。 – tony

另一種存儲數據表的方式，如果您只想在頁面級使用，則在ViewState。 ViewState["dtbl"] = DataTable;

而且你可以從ViewState訪問它只是DataTable dtbl = (DataTable)ViewState["dtbl"];

來源

2011-07-04 14:52:47

通常（在Intranet環境中）在ViewState中存儲洞DataTable將導致比在Session中存儲更多的性能問題。 –

但是這不會存儲到服務器內存中，它取決於何時存儲以及何時不存儲的情況。 –

，而不是將整個DataTable存儲在ViewState中，我寧願使用Control的ViewState（f.e。GridView）。 –

DataTable的是相當重的物體，不建議使用存儲在ViewState中或會議對這一問題。你描述的場景是關於緩存數據的。那麼，爲什麼不使用ASP.NET的緩存呢？

ViewState的，雖然它沒有在服務器會話或高速緩存上使用盡可能多的內存，還需要在服務器上的序列化/反序列化，需要一些臨時的內存使用情況，除了提供用戶大量有效載荷數據對服務器的每個請求（只要在任何瀏覽器中查看View Source，就會看到一個帶有base-64編碼數據的非常大的隱藏輸入）。如果您不使用加密，任何人都可以對每個請求中傳遞的數據進行解碼，如果任何數據都很敏感，則可能會導致安全問題。 ViewState也適用於少量的數據，通常最好堅持主要的數據類型，如整數和字符串。

會話通常不是一個好主意，要麼因爲它還需要序列化/反序列化，除了每個用戶的內存壓力之外，還會增加額外的開銷。會話有memory limits，隨着您增加併發用戶而減少每個用戶。會話數據不會「過期」，直到每個用戶的實際會話過期爲止，默認情況下爲30分鐘。會話對於用戶特定的數據很好，但建議保持非常小，並再次堅持原始數據類型，如整數和字符串。

緩存不序列的任何數據，並且僅limited in size由於OS的位數。在Windows 2003 32位上，您可以使用總共800 MB的應用程序池大小（如果使用/ 3GB開關，則爲1.2或1.3 GB）。在64位下，只有您配置了可用系統內存的數量，纔有更多的自由和限制。緩存的一個好處是，隨着內存壓力的增加，緩存可能會過期以釋放內存以用於更重要的事情。當內存壓力不是一個因素（不保證有效期）時，您還可以控制項目何時到期。如果使用SQL Server，則可以採取額外的步驟，並將數據庫中的數據依賴於緩存，從而允許數據本身決定何時過期緩存，從而確保新數據。最後，可以使用經常被遺忘的對象，但只能用於您知道可以在用戶之間共享的數據，並且不需要經常更改（希望在應用程序重新啓動之前）。

對於ViewState,Session,Cache和Application對象使用Microsoft的文檔，以確定您的特定場景中每個對象的最明智用法。除了使用AJAX（避免整頁回發）和HTTP壓縮以減少交付給客戶端的負載之外，正確使用這些組合可以使響應性很強的站點成爲可能。

在更復雜的場景（如Web場和負載平衡）中，還有其他需要考慮的問題。您需要問自己的問題將會是這樣的：如果用戶點擊與最初請求的服務器不同的服務器，是否應創建新的會話？無論用戶點擊什麼服務器，緩存都應該工作嗎？這些問題將爲您帶來可能會改變數據存儲位置的解決方案。由於存在額外的序列化限制，因此InProc會話比使用SQL Server作爲會話服務器更寬容。

來源

2013-03-19 03:34:56 Sumo

在asp.net會話中存儲DataTable對象的不好主意

回答

相關問題