Iis “应用程序池回收后”；“固定请求数”；

IIS的应用程序池设置在“固定请求数”之后循环使用会产生什么影响

假设这个数字是100，第99个人连接到我的网站，那么第100个人来了，将触发应用程序池回收

---

这是否意味着会话1-99的所有会话信息都将丢失（进程内会话将在应用程序池工作进程重新启动时过期）？

您基本上是对的，但不是人，而是请求。应用程序上调用的每个aspx页面都将累加起来，当达到阈值时，应用程序池将被回收，应用程序域（如果使用.Net）将被卸载，所有内容都将重新启动。您将丢失会话、应用程序和任何静态变量。如果您使用的是经典的asp或php，那么每个会话和全局变量也会丢失

---

点击数阈值有点过分了。您应该禁用它或将其设置为一个巨大的数字。默认情况下，如果我回忆得很清楚，IIS6应用程序池在没有请求的情况下每15分钟进行一次回收，您还可以对应用程序用于触发回收的总内存设置阈值。

这是非常正确的。如果不使用某种会话场或会话信息的数据库备份，则在回收应用程序池时，会话场或会话信息将丢失。我建议尽量不需要任何会话信息-这将使您的应用程序更具可扩展性和可靠性，因为它更接近底层HTTP的无状态特性。

还有一个问题，我们还可以在特定时间设置IIS工作进程回收，这是否意味着（1）在特定时间IIS将回收，或者它意味着（2）在特定时间如果没有用户访问IIS（没有活动连接），工作进程将回收？进一步的问题，我们还可以在特定时间设置IIS工作进程回收，这是指（1）在特定时间IIS将回收，还是意味着（2）在特定时间如果没有用户访问IIS（无活动连接），工作进程将回收？IIS届时将回收-应用程序池将刷新所有未完成的请求，不接受任何新请求，然后停止。同时将启动一个新实例来处理新请求。效果相同-现有进程内会话将被销毁？正是如此。会话状态是一种邪恶的东西它需要跨服务器重启和服务器场以及所有其他方面进行映射stuff@1800信息，1.我认为在固定时间或特定数量的请求进行回收是非常危险的设置，为什么人们需要这样做？2.如果我们在特定时间禁用回收，并且在特定数量的请求处理时禁用回收，是否存在si去效果？