今天早上我在查看我们每月的 Sitecore Analytics 报告时发现了一个令人不安的异常情况。我们本月的平均“现场停留时间”平均约为 9 分钟。这比上个月的平均约 1-2 分钟有所增加。
我的第一 react 是“太好了，看来我们这个月做得更好了”，但经过进一步调查，似乎每次访问该网站都记录了 20-25 分钟的“现场停留时间”统计数据——即使对于单页访问。
有谁之前经历过这个吗？看起来好像添加 SessionEnd 处理器会导致 Sitecore 在默认的 20 分钟持续时间内保持每个 session 处于事件状态。如果这是真的，如何在不影响每次访问的“现场时间”统计数据的情况下添加自定义 SessionEnd 管道处理器？
Sitecore 版本:6.4.1 更新 1
更新
不幸的是，每次访问的站点流量仍然记录在 20 分钟以上……这是完全删除自定义 SessionEnd 处理器的情况。我目前正在调查其他可能的原因。
更新 2
我们在我们的日志中看到许多 Analytics 警告消息，如下所示:
Analystics: Max size of insert queue reached. Dropped 3826.
我现在相信这在某种程度上是相关的......
更新 3
我发现在重新启动 Sitecore 应用程序后，“现场时间”统计数据会恢复正常。从那里开始，现场的平均时间将以每 10 分钟左右大约 1 分钟的速度逐渐攀升，直到大约 20 分钟趋于平稳。我相信大约在同一时间，我们开始在日志中看到“已达到插入队列的最大大小”警告。
我还发现实际的“现场时间”数字是根据
[Session].[Timestamp] 表中 [Session].[LastPageTimestamp] 和 [Sessions] 列之间的平均时间跨度计算的。有趣的是，进入 Session 表的最新记录似乎具有 实际插入表 的 [LastPageTimestamp] 。就好像 INSERT 语句使用 GETDATE() 在每条记录插入数据库时标记它们。如果这是真的，那么我想我找到了罪魁祸首。我相信我有一个性能问题，更糟糕的是，排队的 session 被错误地插入到数据库中。 最佳答案
不知道这个问题的答案......但我要做的第一件事是用 Reflector 拆开现有的 sessionEnd 管道代码，看看它是否正在做一些棘手的事情，你实际上是通过添加另一个处理器来撤消。
在我的 web.config 中，唯一的处理器似乎是 Sitecore.Pipelines.SessionEndSaveRecentDocuments。
关于analytics - 添加 SessionEnd 管道处理器会影响 Sitecore Analytics？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/7324364/