重新启用导致 IIS 挂起的 ASP.NET 会话
我正在尝试在客户端的 Web 服务器上实现一些故障保护，该服务器正在运行两个最重要的站点（IIS7 上的 ASP.NET）。我将设置应用程序池限制，以便如果任何 w3wp 进程使用 90% 以上的 CPU 时间超过一分钟，那么它就会被终止（向任何访问者生成临时 503 服务不可用消息），并且根据我的本地测试将一分钟内重新启动 - 这是一个比让一个占用 CPU 的进程在任意时间内关闭整个服务器更好的解决方案。
这似乎有效，但是在我摆弄本地 IIS7 实例期间，我注意到如果请求调用我的“Kill.aspx”，即使站点重新启动，IIS 也不会为导致其挂起的会话提供服务。我只能从不同的会话重新启动测试站点 - 但一旦我清除“杀手”浏览器上的 cookie，我就可以再次访问该站点。
因此，无论 IIS 试图以此遏制什么恶意行为，对于哪怕是意志坚定的对手来说，都无法奏效。在大多数情况下，如果排泄物确实碰到了风扇，那将是编码/配置错误，而不是当时碰巧请求页面的用户的错误。
因此，我想关闭此功能，因为理论上用户不知道他们需要清除 cookie，然后才能再次访问该网站。我真的很感激任何有关如何实现这一点的想法。
I'm trying to implement some fail safes on a client's web server which is running two of their most important sites (ASP.NET on IIS7). I'm going to set up application pool limiting so that if any w3wp process uses 90%+ CPU for longer than a minute then it gets killed (producing a temporary 503 Service Unavailable message to any visitors), and based on my local testing will be restarted within a minute - a much better solution than having one CPU-hogging process taking down the whole server for any length of time.
This seems to work, however during my fiddling on my local IIS7 instance I've noticed that if a request calls my "Kill.aspx", even when the site comes back up IIS will not serve the session that caused it to hang. I can only restart the test site from a different session - but as soon as I clear my cookies on the "killer" browser I can get to the site again.
So, whatever malicious behaviour IIS is trying to curb with this would not work against an even slightly determined opponent. In most cases, if excrement does hit fan it will be coding/configuration error and not the fault of the user who happened to request a page at that time.
Therefore, I'd like to turn this feature off as the theoretical user would have no idea that they need to clear their cookies before they can access the site again. I would really appreciate any ideas on how this might be possible.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您应该使用 ASP.Net Session StateServer 而不是 In-Proc（请参阅 msdn 详细信息）。这样，您的会话将在不同的进程中运行，并且不会受到 IIS 崩溃的影响。
Yous should be using ASP.Net Session StateServer instead of In-Proc (see msdn for details). That way, you session will run in different process and won't be affected by IIS crash.
关闭什么“功能”？如果工作进程被重置（并且您使用进程内会话），那么该会话将在重置时消失。
您可能想要研究将会话存储移动到状态服务器或其他一些进程外场景。
此外，您可能希望将应用程序池设置为使用多个工作进程（又名：网络花园），这样如果一个进程被终止，其他进程将继续提供内容。
接下来，作为另一个选项，您可能想要设置多个 Web 服务器并对它们进行负载平衡。
最后，您可能想要对应用程序进行分析，以准确了解它们是如何导致其崩溃的。我的猜测是，您只是用这个想法掩盖了许多代码问题。
Turn what "feature" off? If the worker process is reset (and your using in-proc session) then the session is blown away on a reset.
You might want to investigate moving your session storage to a state server or some other out of process scenario.
Also, you might want to set the application pool to use several worker processes (aka: web garden) this way if one process is killed the others continue serving content.
Next, as another option you might want to set up multiple web servers and load balance them.
Finally, you might want to profile the app to see exactly how they are causing it to spin into nothingness. My guess is that there are a number of code issues you are simply covering up with this idea.