視圖狀態無效長度錯誤

我一直在試圖讓一個基本-64字符數組和無效字符在基地-64串舊無效長度的底部。視圖狀態無效長度錯誤

這是一個大的ViewState，因爲我存儲數據的很大一部分在那裏，我不希望從數據庫中請求每三秒鐘的用戶。因爲它是如此之大（4兆在某些情況下），我使用gzip，和壓倒一切的LoadPageStateFromPersistenceMedium（）和SavePageStateToPersistenceMedium（BYVAL pageViewState作爲對象），並創建自定義的視圖狀態。

問題是，每一個現在，然後上述錯誤正在發生。我試圖去的這條底線，並在會議呼籲SavePageStateToPersistenceMedium時使存儲初始視圖狀態的長度，並將其與的LoadPageStateFromPersistenceMedium新的視圖狀態的長度進行比較。我注意到Viewstate的長度已經被嚴重削減，我想知道是什麼原因造成的。

出現的第二個字符串中我也注意到+字符（我正在採取各的最右邊10，以查看是否最初被添加任何東西）。對於一個用戶來說，這肯定會發生得比其他用戶多得多，這或者表明他處理的數據或者他與系統的物理連接（速度，軟件，瀏覽器等）的問題。

有沒有人有任何想法？我們也有一些服務於用戶的刀片服務器，所以我想知道它是否可以作爲用戶從一個服務器推向另一個服務器，但我需要檢查這一點。

我也聽說過，這可能是與渲染的事，但我想在視圖狀態加載之前渲染？

來源

2011-09-30 user676767

你確定這個數據你存儲，必須有可在頁面呈現？從你的描述中，如果你設置並從代碼中獲取這些數據，並且不需要渲染控件的頁面佈局，我想Cache也可以。 ViewState應該很小，只與頁面有關。如果每個用戶或緩存（如果是每個應用程序），則會將更大的一部分數據存儲在Session中。 –

@DavidePiras我在想着完全一樣的東西。我認爲使用緩存將更快，更清潔。它有避免ViewState問題的巨大副作用。 – JefClaes

是的，但請記住，緩存在應用程序範圍內，如果您存儲的這些數據對於每個連接的用戶都不相同，請使用Session。 –

正如我在評論上述建議你應該分析，理解和判斷，如果數據的量確實需要在每個頁面加載要來回發送;如果它屬於該頁面，並且被某些用戶控件使用，或者僅在某些手工緩存機制的後面的代碼中使用它。

我不重複，你可以找到所有在線的替代品的ViewState只在該網頁，每個請求相關，會議爲每個用戶緩存和緩存爲每個應用程序的緩存中的數據量小。

閱讀這篇文章，瞭解詳情：How to Choose From Viewstate, Session, Application, Cache, and Cookies

來源

2011-09-30 10:46:12

緩存和會話仍然存在需要存儲的問題。我寧願看看我是否能夠首先處理例外問題的底部，就像我說的那樣，頁面除了這一點之外表現還是非常好，而且還沒有過去。另外，如果我要使用會話，我仍然需要進行壓縮，因爲數據集的正常大小是4MB。 – user676767

@ user676767：你在這裏錯了，這很痛苦。沒有人，我的意思是沒有人會支持在ViewState中存儲5MB數據集的想法。這只是簡單的堅果。 –

>緩存和會話仍然存在不得不存儲的問題<在會話狀態下存儲少量4Mb的微小開銷與通過網絡發送5Mb的開銷相比微乎其微。儘管您的應用程序似乎在嗡嗡作響，CPU利用率爲0％，這是因爲您的客戶端受I/O限制，正在等待頁面加載！ –

首先，你不應該存儲在ViewState中大量的數據。那不是ViewState的是專爲，它會殺死您頁面的性能。

您應儘量限制命中數據庫的數量，而不是在一切的代價。您在Web服務器上施加了巨大的壓力，迫使其發佈併爲每個請求提供5MB頁面。

如果數據是特定於用戶，然後將其存儲在會話中。如果數據不是用戶特定的，那麼它可能非常適合緩存。無論如何，不要把它放在ViewState中。將數據移至Session應該可以解決問題。

來源

2011-09-30 14:40:15

我已經在上面留下了另一條評論。在回發之前，我正在壓縮視圖狀態。它會減少到幾百KB的每個請求。如果我使用Session變量，那麼我認爲這些變量存儲在服務器上？那麼請求這與壓縮和解壓有關的成本是多少？ – user676767

你似乎仍然錯過了這一點。即使在壓縮之後，一個5MB的數據集可能會是3MB，這是樂觀的。你的ViewState不應該超過100KB，即使這是推動它。默認的InProc會話存儲在服務器的內存中，更適合存儲這樣的大對象。如果您可以將其存儲在緩存中，這將是理想的，但由於數據是用戶特定的，因此會話是存儲它的最佳位置。 –

壓縮率實際上是10X，已檢查。然而，截斷可能發生在45kb，但是又是不正常的（1500次回傳中有1次）。我問上述問題的原因是，我們的6個刀片服務器和一個sqlserver相當緊張。這不僅僅是「適當」的情況，而是確保一切運行良好的一個例子。有很多併發用戶，所以如果我要考慮更改會話，我需要知道兩種實現的替代成本。如果它意味着99％的速度更好，我可以處理一個不穩定的異常。 – user676767

視圖狀態無效長度錯誤

回答

相關問題