Before I start using Session State server for the benefit of making session state more robust in my apps compared to InProc state, I'd like to find a list of Pros and Cons for evaluation.
在开始使用会话状态服务器之前，为了使我的应用程序中的会话状态比InProc状态更强大，我想找到一个优点和缺点列表进行评估。
Update 1: Also about surviving application pool recycles?
更新1：还有关于幸存的应用程序池回收？
Update 2: What about longevity of sessions and their endings?
更新2：会话的长寿及其结局如何？
6 个解决方案
#1
28
Here's the canonical analysis of the pros and cons of your three options, from Rob Howard's ASP.NET Session State article:
以下是Rob Howard的ASP.NET Session State文章对您的三个选项的优缺点的规范分析：
In process. In process will perform best because the session state memory is kept within the ASP.NET process. For Web applications hosted on a single server, applications in which the user is guaranteed to be re-directed to the correct server, or when session state data is not critical (in the sense that it can be re-constructed or re-populated), this is the mode to choose.
正在进行中。在进程中将表现最佳，因为会话状态内存保留在ASP.NET进程中。对于托管在单个服务器上的Web应用程序，保证用户可以重定向到正确服务器的应用程序，或者会话状态数据不重要的应用程序（从某种意义上说，它可以重新构建或重新填充） ，这是可供选择的模式。
Out of process. This mode is best used when performance is important but you can't guarantee which server a user will request an application from. With out-of-process mode, you get the performance of reading from memory and the reliability of a separate process that manages the state for all servers.
过程中。当性能很重要时，最好使用此模式，但无法保证用户从哪个服务器请求应用程序。使用进程外模式，您可以获得从内存中读取的性能以及管理所有服务器状态的单独进程的可靠性。
SQL Server. This mode is best used when the reliability of the data is fundamental to the stability of the application, as the database can be clustered for failure scenarios. The performance isn't as fast as out of process, but the tradeoff is the higher level of reliability.
SQL Server。当数据的可靠性对应用程序的稳定性至关重要时，最好使用此模式，因为数据库可以针对故障情况进行集群。性能不如过程快，但权衡是更高的可靠性。
The out-of-process (aka "StateServer") and SQL-Server options both survive web application restarts (including application pool cycling) and both make session data available to multiple servers in a cluster / farm.
进程外（也称为“StateServer”）和SQL-Server选项都可以在Web应用程序重新启动（包括应用程序池循环）后继续运行，并且可以使会话数据可用于群集/服务器场中的多个服务器。
Finally, it may go without saying, but the basic in-process setup is the easiest to configure, which is a meaningful "pro" in many environments.
最后，可能不言而喻，但基本的进程内设置是最容易配置的，在许多环境中这是一个有意义的“专业”。
Tim Sneath's ASP.NET Session State: Architectural and Performance Considerations adds some additional information, and the MSDN topic on Session State Modes is a reliable, up-to-date source.
Tim Sneath的ASP.NET会话状态：架构和性能注意事项添加了一些其他信息，会话状态模式的MSDN主题是一个可靠的最新源。
#2
7
State Server is a great(!) choice to get started with. Why? Because it means that your application is now compatible with any out-of-process storage modes.
State Server是一个很棒的（！）入门选择。为什么？因为这意味着您的应用程序现在与任何进程外存储模式兼容。
If you currently develop your site with InProc and wanted to move into StateServer or SqlServer at a later time, you can have issues with serialization. Not always, but it is does happen.
如果您当前使用InProc开发站点并希望稍后迁移到StateServer或SqlServer，则可能会出现序列化问题。并非总是如此，但它确实发生了。
Some examples include (some already mentioned):
一些例子包括（一些已经提到过）：
- Ops start scheduling regular IIS application pool recycles without your knowledge
- Ops在您不知情的情况下开始调度常规IIS应用程序池的循环
- Memory is running low on a regular basis
- 内存定期运行不足
- You will be working with a load balancer on production and cannot guarantee the same website will receive the same request.
- 您将在生产中使用负载均衡器，并且不能保证同一网站将收到相同的请求。
Therefore, its best to get this sorted out sooner rather than later. Its only a config change and a service start; Boom!
因此，最好尽早解决这个问题。它只是配置更改和服务启动;繁荣！
What is also means, is if you decide to go down a completely different route of session storage, such as using Redis (Distributed Key/Value Store) or RavenDB (Document Database), you are already sorted.
同样意味着，如果您决定使用完全不同的会话存储路径，例如使用Redis（分布式键/值存储）或RavenDB（文档数据库），则您已经排序。
Its really is a good investment of 1 minute's work. You are now ready for web farms, load balancers and any other session management systems that you decide to prototype against.
它真的是1分钟工作的好投资。您现在已准备好使用Web场，负载平衡器以及您决定进行原型设计的任何其他会话管理系统。
#3
4
Advantages:
1. You can access the same session state across machines.
2. Same session state is available after reloading the app_pool.
优点：1。您可以跨机器访问相同的会话状态。 2.重新加载app_pool后，可以使用相同的会话状态。
Disadvantages:
1. Slower than in process mode.
2. All objects in the session state have to be serializable.
缺点：1。比过程模式慢。 2.会话状态中的所有对象都必须是可序列化的。
#4
4
I'd say one of the big disadvantages of using In_Proc is that session state can be lost if the app pool or domain is recycled. This can happen any time, for instance if the server is low on memory etc. I personally never rely on In_Proc session for anything you don't want to lose. I've spent hours debugging sites with sporadic problems only to find it was because session state was being lost due to a server that was low on resources recycling (and, of course, the more you store in session the lower the more server resources you use up. Remember, if it can go wrong then it probably will go wrong at some point!
我想说使用In_Proc的一大缺点是，如果应用程序池或域被回收，会话状态可能会丢失。这可能在任何时候发生，例如，如果服务器内存不足等等。我个人从不依赖In_Proc会话来做任何你不想丢失的事情。我花了几个小时调试有零星问题的网站，但却发现这是因为会话状态由于服务器资源回收率低而丢失（当然，你在会话中存储的越多，服务器资源越多你就越少记住，如果它可能出错，那么它可能会在某些时候出错！
That's why I now normally use State Server for anything but trivial session data. The only real disadvantage I've found is you need to mark classes as serializable, but this is usually trivial. It's also a bit slower, too, but that is negligible in most cases.
这就是为什么我现在通常使用State Server来处理除了琐碎的会话数据之外的任何事情。我发现的唯一真正的缺点是你需要将类标记为可序列化，但这通常是微不足道的。它也有点慢，但在大多数情况下这可以忽略不计。
There's a good article about this on the IIS MSDN blog.
在IIS MSDN博客上有一篇关于此的好文章。
#5
3
Disadvantages of Sessions in ASP.NET
ASP.NET中Sessions的缺点
-
Every variable is stored as Object. That means you need to convert Object to certain type when read session variable.
每个变量都存储为Object。这意味着您需要在读取会话变量时将Object转换为特定类型。
-
In addition to this, if session is empty, Object will be null. Before reading session variable, you need to check it for null. Even if variable is initialized before, it could be null because session is expired. An attempt to use null session value could return an exception. If value of session variable is null, common practice is to use some default value instead of meaningless null. If value is not null, you must convert it to appropriate type because all session variables are type of object. When do all this things, you should pay attention to avoid hard coding. More about reading and writing of session variables on scalable and maintainable way you can read in How To Write, Read and Delete Session State Variables tutorial.
除此之外，如果session为空，则Object将为null。在读取会话变量之前，需要将其检查为null。即使变量在之前被初始化，它也可能为null，因为会话已过期。尝试使用空会话值可能会返回异常。如果会话变量的值为null，则通常的做法是使用一些默认值而不是无意义的null。如果value不为null，则必须将其转换为适当的类型，因为所有会话变量都是对象的类型。什么时候做这些事情，你应该注意避免硬编码。有关以可伸缩和可维护的方式读取和写入会话变量的更多信息，请参阅如何编写，读取和删除会话状态变量教程。
-
Variable name is type of string. If you hard code name of the variable, there is an option to make type mistake somewhere. The problem is, if you try to read session variable that doesn't exist, ASP.NET will not return any exception or warning. It will simply create new variable with wrong name which has null value. These types of errors could be hard to find.
变量名是字符串的类型。如果您对变量的名称进行硬编码，则可以选择在某处进行类型错误。问题是，如果您尝试读取不存在的会话变量，ASP.NET将不会返回任何异常或警告。它将简单地创建具有错误名称的新变量，该变量具有空值。这些类型的错误很难找到。
-
Session data should not be used for storing of sensitive data. There is a possibility that malicious user obtain regular visitor's session id. If session state is used to store information like: "allow access to administration area or not" or something like that, attacker could see website's sensitive data, other's private data, edit database, delete content etc.
会话数据不应用于存储敏感数据。恶意用户有可能获得常规访问者的会话ID。如果会话状态用于存储以下信息：“允许访问管理区域”或类似信息，攻击者可以看到网站的敏感数据，其他人的私人数据，编辑数据库，删除内容等。
-
If InProc mode is used, sessions easily exhaust all server resources and thus decrease website performances.
如果使用InProc模式，会话很容易耗尽所有服务器资源，从而降低网站性能。
StateServer
的StateServer
SQL Server is most reliable of all modes. Session data are intact if ASP.NET restarts, but also if SQL Server restarts.
SQL Server在所有模式中都是最可靠的。如果ASP.NET重新启动，会话数据完好无损，但SQL Server重新启动时也是如此。
SQL Server is also most scalable option.
SQL Server也是最具扩展性的选项。
SQL Server is often available in shared hosting scenario
SQL Server通常在共享主机方案中可用
Custom mode
自定义模式
You have complete control over sessions. It is possible to create even custom session id.
您可以完全控制会话。甚至可以创建自定义会话ID。
You can support different data sources. That could be useful to store session data on other database, like Oracle, MySQL, MS Access etc.
您可以支持不同的数据源。这对于将会话数据存储在其他数据库（如Oracle，MySQL，MS Access等）上非常有用。
for any other details you can click here to view ASP.NET Session state advantages. hope my answer helped you.! :)
对于任何其他详细信息，您可以单击此处查看ASP.NET会话状态优势。希望我的回答能帮到你。 :)
#6
0
1 other disadvantage is you probably will have a single point of failure if you do 1 remote state-server across a farm. Even if not a farm, its still worth running locally just to survive app_pool IMO. We got caught up on the serializable part, so do watch that.
另一个缺点是，如果跨服务器场执行1个远程状态服务器，则可能会出现单点故障。即使不是一个农场，它仍然值得在本地运行只是为了生存app_pool IMO。我们遇到了可序列化的部分，所以请注意。
Also, keep an eye out for Windows Server AppFabric to release, as it will have a replicated / distributed state server replacement. Supposedly RTM in 1H2010.
另外，请密切注意Windows Server AppFabric的发布，因为它将替换复制/分布式状态服务器。据称是2010年上半年的RTM。
#1
28
Here's the canonical analysis of the pros and cons of your three options, from Rob Howard's ASP.NET Session State article:
以下是Rob Howard的ASP.NET Session State文章对您的三个选项的优缺点的规范分析：
In process. In process will perform best because the session state memory is kept within the ASP.NET process. For Web applications hosted on a single server, applications in which the user is guaranteed to be re-directed to the correct server, or when session state data is not critical (in the sense that it can be re-constructed or re-populated), this is the mode to choose.
正在进行中。在进程中将表现最佳，因为会话状态内存保留在ASP.NET进程中。对于托管在单个服务器上的Web应用程序，保证用户可以重定向到正确服务器的应用程序，或者会话状态数据不重要的应用程序（从某种意义上说，它可以重新构建或重新填充） ，这是可供选择的模式。
Out of process. This mode is best used when performance is important but you can't guarantee which server a user will request an application from. With out-of-process mode, you get the performance of reading from memory and the reliability of a separate process that manages the state for all servers.
过程中。当性能很重要时，最好使用此模式，但无法保证用户从哪个服务器请求应用程序。使用进程外模式，您可以获得从内存中读取的性能以及管理所有服务器状态的单独进程的可靠性。
SQL Server. This mode is best used when the reliability of the data is fundamental to the stability of the application, as the database can be clustered for failure scenarios. The performance isn't as fast as out of process, but the tradeoff is the higher level of reliability.
SQL Server。当数据的可靠性对应用程序的稳定性至关重要时，最好使用此模式，因为数据库可以针对故障情况进行集群。性能不如过程快，但权衡是更高的可靠性。
The out-of-process (aka "StateServer") and SQL-Server options both survive web application restarts (including application pool cycling) and both make session data available to multiple servers in a cluster / farm.
进程外（也称为“StateServer”）和SQL-Server选项都可以在Web应用程序重新启动（包括应用程序池循环）后继续运行，并且可以使会话数据可用于群集/服务器场中的多个服务器。
Finally, it may go without saying, but the basic in-process setup is the easiest to configure, which is a meaningful "pro" in many environments.
最后，可能不言而喻，但基本的进程内设置是最容易配置的，在许多环境中这是一个有意义的“专业”。
Tim Sneath's ASP.NET Session State: Architectural and Performance Considerations adds some additional information, and the MSDN topic on Session State Modes is a reliable, up-to-date source.
Tim Sneath的ASP.NET会话状态：架构和性能注意事项添加了一些其他信息，会话状态模式的MSDN主题是一个可靠的最新源。
#2
7
State Server is a great(!) choice to get started with. Why? Because it means that your application is now compatible with any out-of-process storage modes.
State Server是一个很棒的（！）入门选择。为什么？因为这意味着您的应用程序现在与任何进程外存储模式兼容。
If you currently develop your site with InProc and wanted to move into StateServer or SqlServer at a later time, you can have issues with serialization. Not always, but it is does happen.
如果您当前使用InProc开发站点并希望稍后迁移到StateServer或SqlServer，则可能会出现序列化问题。并非总是如此，但它确实发生了。
Some examples include (some already mentioned):
一些例子包括（一些已经提到过）：
- Ops start scheduling regular IIS application pool recycles without your knowledge
- Ops在您不知情的情况下开始调度常规IIS应用程序池的循环
- Memory is running low on a regular basis
- 内存定期运行不足
- You will be working with a load balancer on production and cannot guarantee the same website will receive the same request.
- 您将在生产中使用负载均衡器，并且不能保证同一网站将收到相同的请求。
Therefore, its best to get this sorted out sooner rather than later. Its only a config change and a service start; Boom!
因此，最好尽早解决这个问题。它只是配置更改和服务启动;繁荣！
What is also means, is if you decide to go down a completely different route of session storage, such as using Redis (Distributed Key/Value Store) or RavenDB (Document Database), you are already sorted.
同样意味着，如果您决定使用完全不同的会话存储路径，例如使用Redis（分布式键/值存储）或RavenDB（文档数据库），则您已经排序。
Its really is a good investment of 1 minute's work. You are now ready for web farms, load balancers and any other session management systems that you decide to prototype against.
它真的是1分钟工作的好投资。您现在已准备好使用Web场，负载平衡器以及您决定进行原型设计的任何其他会话管理系统。
#3
4
Advantages:
1. You can access the same session state across machines.
2. Same session state is available after reloading the app_pool.
优点：1。您可以跨机器访问相同的会话状态。 2.重新加载app_pool后，可以使用相同的会话状态。
Disadvantages:
1. Slower than in process mode.
2. All objects in the session state have to be serializable.
缺点：1。比过程模式慢。 2.会话状态中的所有对象都必须是可序列化的。
#4
4
I'd say one of the big disadvantages of using In_Proc is that session state can be lost if the app pool or domain is recycled. This can happen any time, for instance if the server is low on memory etc. I personally never rely on In_Proc session for anything you don't want to lose. I've spent hours debugging sites with sporadic problems only to find it was because session state was being lost due to a server that was low on resources recycling (and, of course, the more you store in session the lower the more server resources you use up. Remember, if it can go wrong then it probably will go wrong at some point!
我想说使用In_Proc的一大缺点是，如果应用程序池或域被回收，会话状态可能会丢失。这可能在任何时候发生，例如，如果服务器内存不足等等。我个人从不依赖In_Proc会话来做任何你不想丢失的事情。我花了几个小时调试有零星问题的网站，但却发现这是因为会话状态由于服务器资源回收率低而丢失（当然，你在会话中存储的越多，服务器资源越多你就越少记住，如果它可能出错，那么它可能会在某些时候出错！
That's why I now normally use State Server for anything but trivial session data. The only real disadvantage I've found is you need to mark classes as serializable, but this is usually trivial. It's also a bit slower, too, but that is negligible in most cases.
这就是为什么我现在通常使用State Server来处理除了琐碎的会话数据之外的任何事情。我发现的唯一真正的缺点是你需要将类标记为可序列化，但这通常是微不足道的。它也有点慢，但在大多数情况下这可以忽略不计。
There's a good article about this on the IIS MSDN blog.
在IIS MSDN博客上有一篇关于此的好文章。
#5
3
Disadvantages of Sessions in ASP.NET
ASP.NET中Sessions的缺点
-
Every variable is stored as Object. That means you need to convert Object to certain type when read session variable.
每个变量都存储为Object。这意味着您需要在读取会话变量时将Object转换为特定类型。
-
In addition to this, if session is empty, Object will be null. Before reading session variable, you need to check it for null. Even if variable is initialized before, it could be null because session is expired. An attempt to use null session value could return an exception. If value of session variable is null, common practice is to use some default value instead of meaningless null. If value is not null, you must convert it to appropriate type because all session variables are type of object. When do all this things, you should pay attention to avoid hard coding. More about reading and writing of session variables on scalable and maintainable way you can read in How To Write, Read and Delete Session State Variables tutorial.
除此之外，如果session为空，则Object将为null。在读取会话变量之前，需要将其检查为null。即使变量在之前被初始化，它也可能为null，因为会话已过期。尝试使用空会话值可能会返回异常。如果会话变量的值为null，则通常的做法是使用一些默认值而不是无意义的null。如果value不为null，则必须将其转换为适当的类型，因为所有会话变量都是对象的类型。什么时候做这些事情，你应该注意避免硬编码。有关以可伸缩和可维护的方式读取和写入会话变量的更多信息，请参阅如何编写，读取和删除会话状态变量教程。
-
Variable name is type of string. If you hard code name of the variable, there is an option to make type mistake somewhere. The problem is, if you try to read session variable that doesn't exist, ASP.NET will not return any exception or warning. It will simply create new variable with wrong name which has null value. These types of errors could be hard to find.
变量名是字符串的类型。如果您对变量的名称进行硬编码，则可以选择在某处进行类型错误。问题是，如果您尝试读取不存在的会话变量，ASP.NET将不会返回任何异常或警告。它将简单地创建具有错误名称的新变量，该变量具有空值。这些类型的错误很难找到。
-
Session data should not be used for storing of sensitive data. There is a possibility that malicious user obtain regular visitor's session id. If session state is used to store information like: "allow access to administration area or not" or something like that, attacker could see website's sensitive data, other's private data, edit database, delete content etc.
会话数据不应用于存储敏感数据。恶意用户有可能获得常规访问者的会话ID。如果会话状态用于存储以下信息：“允许访问管理区域”或类似信息，攻击者可以看到网站的敏感数据，其他人的私人数据，编辑数据库，删除内容等。
-
If InProc mode is used, sessions easily exhaust all server resources and thus decrease website performances.
如果使用InProc模式，会话很容易耗尽所有服务器资源，从而降低网站性能。
StateServer
的StateServer
SQL Server is most reliable of all modes. Session data are intact if ASP.NET restarts, but also if SQL Server restarts.
SQL Server在所有模式中都是最可靠的。如果ASP.NET重新启动，会话数据完好无损，但SQL Server重新启动时也是如此。
SQL Server is also most scalable option.
SQL Server也是最具扩展性的选项。
SQL Server is often available in shared hosting scenario
SQL Server通常在共享主机方案中可用
Custom mode
自定义模式
You have complete control over sessions. It is possible to create even custom session id.
您可以完全控制会话。甚至可以创建自定义会话ID。
You can support different data sources. That could be useful to store session data on other database, like Oracle, MySQL, MS Access etc.
您可以支持不同的数据源。这对于将会话数据存储在其他数据库（如Oracle，MySQL，MS Access等）上非常有用。
for any other details you can click here to view ASP.NET Session state advantages. hope my answer helped you.! :)
对于任何其他详细信息，您可以单击此处查看ASP.NET会话状态优势。希望我的回答能帮到你。 :)
#6
0
1 other disadvantage is you probably will have a single point of failure if you do 1 remote state-server across a farm. Even if not a farm, its still worth running locally just to survive app_pool IMO. We got caught up on the serializable part, so do watch that.
另一个缺点是，如果跨服务器场执行1个远程状态服务器，则可能会出现单点故障。即使不是一个农场，它仍然值得在本地运行只是为了生存app_pool IMO。我们遇到了可序列化的部分，所以请注意。
Also, keep an eye out for Windows Server AppFabric to release, as it will have a replicated / distributed state server replacement. Supposedly RTM in 1H2010.
另外，请密切注意Windows Server AppFabric的发布，因为它将替换复制/分布式状态服务器。据称是2010年上半年的RTM。