添加 SessionEnd 管道处理器会影响 Sitecore Analytics？
今天早上，我在查看每月的 Sitecore 分析报告时发现了一个令人不安的异常情况。本月我们的平均“现场时间”达到平均 9 分钟左右。这比上个月的平均约 1-2 分钟有所增加。
我的第一反应是“太棒了，看起来我们这个月做得更好了”，但经过进一步调查，似乎每次访问该网站都会记录 20-25 分钟的“现场时间”统计数据 - 即使对于单页访问量。
以前有人经历过吗？看起来好像添加 SessionEnd 处理器会导致 Sitecore 在 20 分钟的默认持续时间内使每个会话保持活动状态。如果这是真的，如何添加自定义 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] 表中的列。这里有趣的是，进入会话表的最新记录似乎具有它们插入表中的实际时间的[LastPageTimestamp] 。就好像 INSERT 语句使用 GETDATE() 在将每条记录插入数据库时对其进行标记。如果这是真的，那么我想我找到了罪魁祸首。我相信我遇到了性能问题，更糟糕的是，排队的会话被错误地插入数据库。
I discovered a troubling anomaly this morning while reviewing our monthly Sitecore Analytics reports. Our average 'time on site' this month reach an average of about 9 minutes. This is up from an average of around 1-2 minutes for the previous month.
My first reaction was "great, looks like we're doing better this month", but after further investigation, it appears as though each and every visit to the site is recording a 20-25 minute 'time on site' statistic - even for single page visits.
Has anyone experienced this before? It appears as though the addition of a SessionEnd processor causes Sitecore to keep each and every Session alive for the default duration of 20 minutes. If that's true, how does one add a custom SessionEnd pipeline processor without affecting the 'time on site' statistic for every visit?
Sitecore version: 6.4.1 Update 1
UPDATE
Unfortunately, site traffic is still being recorded above 20 minutes for each visit... and this is with the custom SessionEnd processor completely removed. I am currently investigating other possible causes.
UPDATE 2
We are seeing many Analytics warning message appear in our logs that look like the following:
Analystics: Max size of insert queue reached. Dropped 3826.
I now believe this is somehow related...
UPDATE 3
I discovered that the 'time on site' statistics would go back to normal after restarting the Sitecore application. From there, the average time on site would gradually climb at a rate of about 1 minute every 10 minutes or so until leveling out around 20 minutes. I believe that's around the same time we start seeing the 'Max size of insert queue reached' warnings in our logs.
I also discovered that the actual 'time on site' figure is calculated from the average time-span between the [Session].[Timestamp] and [Session].[LastPageTimestamp] columns in the [Sessions] table. What's interesting here is that the newest records entering the Session table appear to have a [LastPageTimestamp] of the actual time they are inserted into the table. It's as if the INSERT statement uses GETDATE() to stamp each record as they are inserted into the database. If that's true, then I think I found the culprit. I believe I have a performance issue on my hands, and to make matters worse, the queued Sessions are being inserting into the database incorrectly.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不知道这个问题的答案......但我要做的第一件事就是用 Reflector 拆开现有的 sessionEnd 管道代码，看看它是否做了一些棘手的事情，而您实际上是通过添加另一个处理器来撤销的。
在我的 web.config 中，唯一的处理器似乎是 Sitecore.Pipelines.SessionEndSaveRecentDocuments。
Don't know the answer to this question... but the first thing I would do is take apart the existing sessionEnd pipeline code with Reflector and see if it's doing something tricky that you are essentially undoing by adding another processor.
In my web.config, the only processor seems to be Sitecore.Pipelines.SessionEndSaveRecentDocuments.