“固定数量的请求”后应用程序池回收
IIS的应用程序池设置为“固定请求数”后回收有什么影响？
假设这个数字是100，第99个人连接到我的网站，那么第100个人来了，就会触发应用程序池回收。
这是否意味着会话 1-99 的所有会话信息都将丢失（进程内会话将在应用程序池工作进程重新启动时过期）？
What are the effects of IIS's app pool setting for recycling to recycle after "Fixed number of requests"?
Suppose this number is 100, and the 99th person connects to my web site, then the 100th person comes and will trigger an application pool recycle.
Does this mean all session information for sessions 1-99 will be lost (in-process session will expire when application pool worker process restarts)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你基本上是对的，但问题不是人，而是要求。 应用程序上调用的每个 aspx 页面都会累加，当达到阈值时，应用程序池将被回收，应用程序域（如果您使用 .Net）将被卸载，并且所有内容都会重新启动。 您会丢失会话、应用程序和任何静态变量。 如果您使用经典的 asp 或 php，每个会话和全局变量也会丢失。
命中数阈值有点大材小用了。 您应该禁用它或将其设置为一个很大的数字。 默认情况下，如果我没记错的话，如果没有请求，IIS6 应用程序池每 15 分钟回收一次，您还可以对应用程序使用的总内存设置阈值来触发回收。
You basically have it right, but it's not the person, it's the request. Each aspx page called on your application will add up and when the threshold is reached, the application pool is recycled, the application domain (if your using .Net) is unloaded and everything starts up again. You lose Session, Application and any static variables laying around. If your using classic asp or php, every session and global variables are lost too.
A number of hits threshold is a bit overkill. You should either disable it or set it to a huge number. By default, if I recall well, the IIS6 application pool recycles every 15 minutes if there were no request and you can also put threshold on the total memory used by your application to trigger recycling.
这是非常正确的。 如果您不使用某种会话场或会话信息的数据库支持，那么当应用程序池被回收时，它将丢失。 我建议尽量不要要求任何会话信息——这将使您的应用程序更具可扩展性和可靠性，因为它更接近于底层 HTTP 的无状态性质。
That is quite correct. If you do not use some kind of Session farm, or database backing of the session information, it will be lost when the application pool is recycled. I would recommend trying hard to not require any session information - this will make your application more scalable and reliable as it maps more closely to the stateless nature of the underlying HTTP.