为什么 ASP.NET Sitecore 站点会在 7 或 8 分钟后断开会话？

Question

我有一个使用两个前端 CD 服务器和一个带有粘性会话的负载平衡器构建的 Sitecore 7.5 站点。负载均衡器的默认超时为 5 分钟。 Sitecore 站点的 ASP.NET 默认会话超时值为 20 分钟。我一直在收到有关该网站随机注销人员的报告。我刚刚进行了以下实验：

• 在新浏览器中开始新会话
• 在我的手机上启动了一个计时器
• 几乎不断地点击站点中的不同页面。我最长的空闲时间大概是 30 秒。
• 大约 10 到 15 分钟后，我突然注意到我不再登录应用程序

我不知道为什么会这样。这是我用来登录的代码。

        protected void ButtonLogin_Click(object source, EventArgs e)
    {
        bool loginSuccess = Sitecore.Security.Authentication.AuthenticationManager.Login("extranet\\" + TextLoginUsername.Text, TextLoginPassword.Text, CheckKeepLoggedIn.Checked) || (Sitecore.Security.Authentication.AuthenticationManager.Login("sitecore\\" + TextLoginUsername.Text, TextLoginPassword.Text, CheckKeepLoggedIn.Checked));
        if (loginSuccess)
        {
            LabelLoginError.Visible = false;
            Sitecore.Analytics.Tracker.Current.Session.Identify(Sitecore.Context.GetUserName());
            Sitecore.Analytics.Tracker.Contact.Tags["Full Name"] = Sitecore.Context.GetUserName();
            Response.Redirect(ButtonLogin.PostBackUrl);
            return;
        }

        //Otherwise log as error.
        LabelLoginError.Text = "Username/password combination was incorrect.";
        LabelLoginError.Visible = true;
    }

有什么想法吗？

Answer 1

检查您的数据文件夹是否在您的 webroot 之外。如果您的数据在您的 webroot 中，则可能会由于数据文件夹、日志文件、视图状态缓存、lucene 索引等中更改的文件数量而重置应用程序池...

有关详细信息，请参阅此帖子：http://www.sitecorenutsbolts.net/2015/06/01/Application-Pool-Restarts-when-Data-folder-is-in-Webroot/ - 确保您的数据文件夹不在您的

Answer 2

检查日志以查看您的应用程序域或应用程序池是否由于文件活动而重新启动，从而丢失了 inProc 会话状态。在日志中查找“关闭”或“Sitecore 已启动”。

之前的回答误读了问题

您正在登录机器 A，但 5 分钟后，您 在负载均衡器上 的粘性会话到期，您的下一个请求将启动一个新的粘性会话，并且有 50% 的机会被路由再次到服务器 A。如果它被分配给服务器 A，您的体验不受影响，因为您仍然登录到服务器 A。如果相反，新的粘性会话被分配给服务器 B，那么，您没有登录服务器 B，所以您将以为您已“注销”，但实际上您从未登录过服务器 B。

要解决此问题，请将负载平衡器会话超时设置为与服务器会话超时相同 - 即 20 分钟。

粘性会话的存在是为了确保您的请求被发送到同一台服务器。通过将负载平衡器会话长度设置为比服务器会话超时更短，如果您在原始服务器上仍存在活动会话时可能会被定向到错误的服务器，则会缩短 15 分钟。

在您的网页中使用服务器名称或 IP 地址设置 html 评论将确认此行为。

Answer 3

您是否检查了对 CD 服务器的分配？您可以在浏览器控制台中检查。 也许您的 cookie 已过期并且您的负载均衡器刚刚切换了您的用户一直在使用的服务器？

还有一件事 - 您是否使用 SSL 来保护连接？在过去我的一个 同事/管理员在使用 SSL 正确配置 LB 时遇到了一些问题。