Viewstate无效长度错误

Question

我一直试图找到Base-64 char数组的旧Invalid长度和Base-64字符串中的无效字符的底部。

这是一个大型ViewState，因为我在那里存储了大量数据，我不希望用户每三秒钟从数据库请求一次。因为它太大了（在某些情况下是4兆），我用Gzip压缩它，并覆盖LoadPageStateFromPersistenceMedium（）和SavePageStateToPersistenceMedium（ByVal pageViewState As Object）并创建自定义视图状态。

问题是，偶尔会出现上述错误。我试图找到它的底部，因此在调用SavePageStateToPersistenceMedium时将Session存储在初始View状态长度中，并将其与LoadPageStateFromPersistenceMedium中的新视图状态长度进行比较。我注意到的是Viewstate的长度已被严重削减，我想知道是什么原因引起的。

我还注意到第二个字符串中出现了+字符（我正在拍摄最右边的10个字符以查看最初是否添加了任何内容）。对于一个用户来说，它肯定比其他用户更多地发生，这表明他处理的数据存在问题，或者他与系统的物理连接（速度，软件，浏览器等）。

有没有人有任何想法？我们还有许多刀片服务于用户，所以我想知道它是否可以作为用户从一个推送到另一个，但我需要检查这个。

我也听说过这可能与渲染有关，但我认为viewstate是在渲染之前加载的？

Answer 1

正如我在上面的评论中所建议的那样，您应该分析，理解并确定是否真的需要在每次页面加载时来回发送数据量;如果它属于该页面并被某些用户控件使用，或者它只是由您在某种手工制作的缓存机制中的代码中使用。

我不会重复您可以在网上找到的所有文章，替代方案是ViewState，仅用于少量数据，仅与该页面和每个请求相关，Session根据用户缓存和Cache按应用程序缓存。

阅读本文了解更多详情：How to Choose From Viewstate, Session, Application, Cache, and Cookies

Answer 2

首先，您不应该在ViewState中存储大块数据。这不是ViewState的设计目标，它将杀死页面的性能。

您应该始终尝试限制数据库的命中数，但不能以牺牲其他所有内容为代价。您通过强制每个请求发布并提供5MB页面，对Web服务器施加了巨大的压力。

如果数据是特定于用户的，则将其存储在会话中。如果数据不是特定于用户的，那么它可能非常适合缓存。无论如何，不​​要把它放在ViewState中。将数据移动到Session应该可以解决问题。