ASP.NET 是否根据 SessionID 做出请求调度决策？
我知道正确实现的 SessionStateStoreProvider 在请求期间维护会话数据的独占锁。然而，考虑到多个请求可能同时到达（例如通过 IFRAME），除了一个请求之外的所有请求都能够取得进展。所有其他请求都会阻塞一段时间，并减少这段时间内可用的工作线程数量。
看来，如果 ASP.NET 尽早“查看”请求的会话 ID，它可以避免在同一会话上同时运行请求。这将提高不想放弃使用 IFRAME 的页面在负载下的吞吐量。
这似乎很有道理，可能是真的。
I know that a properly implemented SessionStateStoreProvider maintains an exclusive lock on session data for the duration of a request. However, considering that multiple requests could arrive simultaneously (e.g. via IFRAMEs) all but one would be able to make forward progress. All the other requests would block for a bit and reduce the number of worker threads available during that time.
It seems if ASP.NET "peeked" at the session IDs on the requests early on, it could avoid running requests simultaneously that were on the same session. This would improve throughput under load for pages that didn't want to give up using IFRAMEs.
This seems plausible enough that it might be true.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
根据第 10 章“提高 Web 服务性能、状态管理”，MSFT p&p，2004 年 5 月（链接text):
"[...] 如果将数据保持在会话状态，则一个客户端发出的 Web 服务调用将由 ASP.NET 运行时序列化。来自同一客户端的两个并发请求将在同一服务器上排队Web 服务中的线程 [...]”
According to Chapter 10, Improving Web Services Performance, State Management, MSFT p&p, May 2004 (link text):
"[...] If you keep data in session state, Web services calls made by one client are serialized by the ASP.NET runtime. Two concurrent requests from the same client are queued up on the same thread in the Web service [...]"