.ashx 处理程序中的视图状态?
我有一个处理程序(例如 list.ashx),它有一个方法可以检索大型数据集,然后仅获取将在任何给定数据“页面”上显示的记录。我们允许用户对这些结果进行排序。因此,在任何给定的页面运行中,我将检索几秒/分钟前刚刚获得的数据集,但对它们重新排序,或显示下一页数据等。
我的观点是我的数据集确实没有改变。通常,数据集会被困在页面的视图状态中,但由于我使用的是处理程序,所以我没有那么方便。至少我不这么认为。
那么,在使用处理程序时存储与当前用户的给定页面关联的视图状态的常用方法是什么?有没有办法获取数据集,以某种方式对其进行编码并将其发送回用户,然后在下一次调用时将其传回,然后从这些位重新水化数据集?
我认为 Session 不是存储它的好地方,因为我们可能有 1000 个用户都在查看不同数据的不同数据集,这可能会使服务器崩溃。至少我是这么认为的。
有没有人有过这种情况的经验,可以给我一些建议吗?
I've got a handler (list.ashx for example) that has a method that retrieves a large dataset, then grabs only the records that will be shown on any given "page" of data. We are allowing the users to do sorting on these results. So, on any given page run, I will be retrieving a dataset that I just got a few seconds/minutes ago, but reordering them, or showing the next page of data, etc.
My point is that my dataset really hasn't changed. Normally, the dataset would be stuck into the viewstate of a page, but since I'm using a handler, I don't have that convenience. At least I don't think so.
So, what is a common way to store the viewstate associated with a current user's given page when using a handler? Is there a way to take the dataset, encode it somehow and send that back to the user, and then on the next call, pass it back and then rehydrate a dataset from those bits?
I don't think Session would be a good place to store it since we might have 1000 users all viewing different datasets of different data, and that could bring the server to its knees. At least I think so.
Does anyone have any experience with this kind of situation, and can you give me any advice?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
为什么不实现服务器端缓存?
AI 理解,您正在检索大量数据,然后仅将这些数据中的必要记录返回给不同的客户端。因此,您可以使用 HttpContext.Current.Cache 属性来实现此目的。
例如,可以使用封装数据检索逻辑的属性(通过第一个请求从原始数据存储获取,然后放入缓存并通过每个下一个请求从缓存获取)。在这种情况下,所有必要的数据操作(分页等)可能比通过每个请求检索大量数据更快地完成。
当客户端有不同的数据源(即每个客户端有自己的数据源)时,也可以实现上述方案。我想每个客户端至少有标识符,因此您可以为不同的客户端使用不同的缓存(客户端标识符作为缓存键的一部分)。
Why don't you implement a server side caching?
A I understand, you're retrieving a large amount of data and then returns only necessary records from this data to different clients. So you could use
HttpContext.Current.Cache
property for this.E.g. a property which encapsulates a data retrieving logic (gets from the original data store with the first request, then puts to cache and gets from cache with every next request) could be used. In this case all the necessary data manipulations (paging, etc.) may be done much more quicker than retrieving a large amount of data with the each request.
In the case when clients have different data sources (mean each client have its own data source) the solution above may also be implemented. I suppose each client has at least identifier, so you could use different caches for different clients (client identifier as a part of cache key).
您能做的最好的事情就是通过将序列化数据集包含在对 ASHX 处理程序的请求正文中来“扩展您自己的”。然后,您的处理程序将通过检查
Request.ContentLength
然后从Request.InputStream
读取来检查请求是否确实具有正文,以及是否将该正文序列化回来进入数据集而不是从数据库中读取。The best you could do is "grow your own" by including the serialized data set in the body of the request to the ASHX handler. Your handler would then check to see if the request does indeed have a body by checking
Request.ContentLength
and then reading fromRequest.InputStream
, and if it does serializing that body back into the data set instead of reading from your database.在这种情况下,我将使用某种类型的用户和查询信息作为键的缓存。原因是你说它是一个大数据集。就有些东西你不想不断地在管道上推来推去。请记住,如果数据处于 ViewState 中,您的服务器仍然必须接收数据并处理它。我会做这样的事情,它会为特定用户缓存它并有一个短暂的过期时间:
当你说 1000 个用户时,这是否意味着并发用户?如果您的过期时间为 1 分钟,那么一分钟内有多少并发用户会进行该调用并需要排序。我认为将数据卸载到类似于 ViewState 的东西只是用一些缓存内存来交换带宽和来回处理大型请求的负载。我认为来回传输越少越好。
In this situation I would use a cache with some type of user and query info as the key. The reason being is you say it is a large dataset. Right there is something you don't want to be pushing up and down the pipe constantly. Remember your server still has to received the data if it is in ViewState and handle it. I would do something like this which would cache it for a specific user and have a short expiry:
When you say 1000's of users, does that mean concurrent users? If your expiration time was 1 minute how many concurrent users would make that call in a minute and require sorting. I think offloading the data to something like similar to
ViewState
is just trading some cache memory for bandwidth and processing load of larget requests back and forth. The less you have to transmit back and forth the better in my opinion.