我需要了解一些有关 ASP.NET 会话状态的信息，因为它适用于 IIS 7 和 ASP.net 3.5。
如果应用程序配置为使用进程内会话状态，那么如果有多个工作进程，该应用程序是否可以正常工作？换句话说，工作进程是否共享会话状态？
IIS 7 的默认配置是使用进程内会话状态并分配最多 10 个工作进程。那么看起来这个默认配置应该可以工作。我正在与一家生产 ASP.NET MVC Web 应用程序的公司打交道，该应用程序遇到了一些问题，他们将问题归咎于服务器环境。据称，因为我使用 10 个工作进程的默认设置，所以破坏了它们的会话状态。我需要知道这是否确实是一个准确的说法。我从来不知道 ASP.NET 应用程序不能使用默认配置，所以我有点困惑，需要澄清这一点。
I need to understand something about ASP.NET session state, as it applies to IIS 7 and ASP.net 3.5.
If an application is configured to use in-process session state, will that work OK if there are multiple worker processes? In other words, do worker processes share session state?
The default configuration for IIS 7 is to use in-process session state and to allocate a maximum of 10 worker processes. It would seem likely then, that this default configuration should work. I'm dealing with a company that has produced an ASP.NET MVC web app that is having some problems, they're blaming the server environment. The claim is that because I'm using the default settings of 10 worker processes, that is breaking their session state. I need to know whether this is in fact an accurate claim. I've never known an ASP.NET app to not work with the default configuration, so I'm a bit confused and need to have this clarified.
发布评论
评论（4）
拥有多个工作进程和使用 InProc 似乎不兼容。
请参阅这个：
Having multiple worker processes and using InProc does not seem to be compatible.
See this:
多个工作进程就是一个“网络花园”。进程内会话状态将无法正常工作。您需要为 Web 应用程序使用单个工作进程，或者使用会话状态服务器或 SQL Server 作为会话状态。
More than one worker process is a "web garden." In-process session state will not work correctly. You'll need to use either a single worker process for your web app, or use a session state server, or SQL Server for session state.
我可能是错的，但据我所知，默认情况下每个应用程序域只有 1 个工作进程，并有多个工作线程来处理请求。在这种情况下，进程内会话状态应该可以正常工作（默认设置）。
但是，如果您确实有多个工作进程（不仅仅是工作线程，而是实际的工作进程），您确实需要进程外会话状态。
我认为在 ASP.NET 中拥有超过 1 个工作进程被称为网络花园模式，您必须专门启用它，如果您这样做，那么您需要进程外状态管理。请参阅进程中的此页面上的评论框模式标题。
I may be wrong, but as far as I know, by default you only have 1 worker process per application domain with multiple worker threads to handle requests. In this case In-Proc Session State should work just fine (the default settings).
But if you do have multiple worker processes (not just worker threads, actual worker processes) you do need out of process session state.
I think having more than 1 worker process in ASP.NET is referred to web garden mode which you have to specifically enable and if you do, then you need out of process state management. See the comment box on this page under the In-Process Mode heading.
我遇到了会话丢失的问题，最后努力找到根本原因。
最近我收到了几个关于会话丢失的错误报告。如果网站负载较低，则一切正常。如果网站负载很高，就会出现会话丢失的问题。这很奇怪。
根本原因在于Worker进程设置和Session状态之间。这里我们有5个工作进程，这意味着当网站负载较高时会有5个独立的进程在运行。当会话存储在进程中时，IIS 无法保证客户端用户将使用相同的工作进程。
例如，用户客户端第一次访问Web时使用进程A，当他第二次访问Web时，可能会使用进程B。进程B中没有存储会话，因此他的会话丢失。
为什么网站负载低的时候还可以？因为当负载较低时，IIS只会设置一个工作进程。所以不会发生会话丢失的问题。这就解释了为什么我部署新版本晚上测试没问题，但是明天早上又出现这个错误。因为晚上网站负载低。
请小心在 Process 中使用会话状态，当您的网站负载较高并考虑多个工作进程时，它会不稳定。尝试类似 State Serversession state 的东西。
I experienced session lost problem and finally struggled to find the root cause.
Recently I received several bug reprot about the session lost. If the website load is low, everything is OK. If the website load is high, the session lost issue happens. This is very weird.
The root cause is between Worker process setting and Session state. Here we have 5 worker processes, which means it will have 5 independent processes running when the website load is high. While the session is stored in process, IIS cannot guarantee that a client user will use the same worker process.
For example, the user client uses Process A when first visiting the web, and when he second visit the web, it may use Process B. There is no session stored in Process B, so his session is lost.
Why it is OK when the website load is low? Because IIS will only setup one worker process when the load is low. So the session lost issue will not happen. This explains why it is OK when I deploy a new version and test it OK at night, but the error happens again tomorrow morning. Because the website load is low at night.
Be careful to use session state in Process, it is unstable when your website load will be high and considering with mutiple worker processes. Try something like State Serversession state.