【发布时间】:2023-04-07 02:18:01
【问题描述】:
我们在生产环境中有一个应用程序 (ASP Dot Net , Framework 4.0),部署在 IIS 7.5 window server 2012 上。这个应用程序每天都在4000 requests 附近出现,但过去几天我们面临的问题是一些用户抱怨他们的会话过期。我们检查了应用程序,没有看到任何可能导致会话过期的错误。我们检查了 IIS 设置和池设置,但我们认为没有任何理由足以解决问题。
请在这方面帮助我们解决这个问题。
我可能需要提供更多细节来帮助您解决我的问题。 我们在专业组织中工作,我们在 IIS 上为我们的客户运行许多应用程序。我们收到的问题来自我们为新客户端构建并部署在 IIS 8.0 服务器 2012 上的同一应用程序之一。
在我们的应用程序的 web 配置中超时是一小时,并且我们进一步确保如果出现任何其他错误,我们不应该将用户路由到会话过期页面。现在,在进行这些更改之后,我们非常确定问题不应该是由于应用程序配置或它的结构造成的。 现在我们关心的是IIS。这次不同的是,我们使用的是 IIS 8.0 而不是 IIS 7.5,我们在所有不同的服务器上针对不同的应用程序使用了 IIS 7.5。 您可能感兴趣的一些 IIS 配置
- 我们为应用程序设置了专用池,进一步的池配置为 2.0,因为应用程序位于 3.5 框架上。
- 最大工作进程 = 1
- 28 小时内池回收
如果与 IIS 8.0 相关,请告诉我您能否具体指导我,因为我们正在考虑恢复到 7.5,我们的生产应用程序和客户一直在抱怨它。
【问题讨论】:
-
这不足以给你答案。因为没有人能理解。您可以通过检查任何人在某天之内可以在服务器上进行的活动来进行逆向工程,例如新框架安装、窗口更新、安装热修复、安装新软件等,这样您就可以卸载并重试。
-
您必须添加或启用应用程序级别的日志记录才能查看所有会话的实际到期时间和内容。如果没有这些初始数据,您将无法开始