平面文件中的视图状态与 SQLserver 中的视图状态
我基于 SessionPageStatePersister 编写了自己的 PageStatePersister 类，该类将会话的最近 10 个 Viewstate 写入共享磁盘。我认为这比在会话中保持 Viewstate 更好，因为所有 Web 服务器都可以访问它，它们不必处理过期问题，并且使用更少的内存。
当用户关闭浏览器时，它会通知服务器，服务器会删除那些两小时内未访问的文件。到目前为止一切顺利，但我想知道将 Viewstate 存储在 SQL Server 数据库中是否会更快、更高效。
- 每个
ViewState文件平均为 30k。 - 目前它只是读取隐藏字段来获取 Viewstate 键并直接访问文件并反序列化。无需排序或搜索。
- 每小时大约有 2000 个并发用户，并且保存最近 20 个 Viewstate 会话将是每小时大约 20k 临时视图文件。
- 它必须定期遍历文件并删除最旧的文件。
那么在这种情况下哪个更好：平面文件系统还是数据库？
I wrote my own PageStatePersister class based on SessionPageStatePersister which writes the most recent 10 Viewstates for a session to a shared disk. I figure this will scale better than keeping Viewstate in session since all web servers have access to it, they won't have to deal with expiration, and use less memory.
When a user closes the browser it notifies the server and the server deletes those files which have not been accessed for two hours. So far so good but I'm wondering if it will be faster and more efficient to store Viewstate in an SQL server database instead.
- Each
ViewStatefile is 30k on average. - Currently it just reads a hidden field to get a Viewstate key and access the file directly and deserialize. There's no need to sort or search.
- There will be about 2000 concurrent users each hour and saving last recent 20 Viewstate sessions will be about 20k temp view files per hour.
- It must periodically iterate through files and delete the oldest file.
So which is better in this case: a flatfile system or a database?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
将 ViewState 存储在 SQL Server 中会更好地扩展。例如，如果您最终希望从最近 10 个增加到最近 50 个，则数据库负载的增加相对较小。通常应尽可能避免磁盘 I/O，而不是 DB I/O。清理操作也会工作得更好，因为在磁盘上废弃文件的荒地中寻找可能比 WHERE DateInserted > 重得多。 20 分钟前。
It would scale much better to store the ViewState in SQL Server. If you eventually want to increase from 10 most recent to 50 most recent, for example, it would be a relatively trivial increase in DB load. Disk I/O should generally be avoided whenever possible, moreso than DB I/O. Cleanup operations would also work much better, as seeking across a wasteland of abandoned files on disk is probably much heavier than
WHERE DateInserted > 20 minutes ago.