Perfmon ASP.Net 应用程序“会话活动”计数器答案

【问题标题】：Perfmon ASP.Net Apps "Sessions Active" CounterPerfmon ASP.Net 应用程序“会话活动”计数器
【发布时间】：2011-05-05 10:36:07
【问题描述】：

编辑：我们意识到我们目前正在审查的会话是 inproc 的，这绝对没问题。简而言之，问题是在 inproc 计数器中报告的活动会话在交付时是否可靠？或者它们是否因任何原因看起来比实际更高（我读过一篇关于它的文章，由于安装了 ASP.Net 3.5，它似乎在 4 亿左右，但我说的不是那么高）。

在我的工作地点，我们正试图确定有多少人有一个活动会话，因为活动会话的数量是激活设备的负载平衡软件的触发器。我们正在查看 Asp.Net 应用程序“会话活动”计数器，当我们比较看起来有多少人正在浏览我们的网站与我们实际在做多少业务时，它似乎给出了一些稍微奇怪的读数。例如，有可能只注册 1600 个活跃会话，但大约每两分钟销售一次商品，或者像今天早上一样，活跃会话达到 3000 个，但每 15 分钟才进行一次销售。

我们完全有可能只是有很多潜伏者，但可以肯定的是，我想知道是否有人知道这个计数器实际上是如何得出它的数字的，以及它是否容易受到任何类型的误报行为的影响。几个小时以来，我一直在关注性能数据，活跃的会话在 3100 到 2700 之间变化，但在这段时间里，我们已经完成了大约 10 次实际销售。我们是否应该将我们只有很多浏览器视为福音？

【问题讨论】：

您能否提及您在应用程序中使用的会话模式？谢谢！ ;)
为什么，会有什么不同？
一个好的：如果它在进程中，如果 IIS 应用程序池被回收，IIS 被重置，甚至 Windows 被重新启动，无论如何，会话将无法生存，而 SQL Server 或状态服务器（或自定义服务器）将在执行任何这些操作后恢复会话。
我快速浏览了一下，我认为我在谈论 InProc 会话，如果 inproc 是默认设置，那么没有人曾经更改过它。
我们对 InProc 的会话没有问题。我们不一定需要它们才能在您描述的行为中幸存下来。

标签： asp.net session perfmon

【解决方案1】：

好吧，假设您使用的是进程内会话状态模式，首先，我建议您切换到 SQL Server 或状态服务器模式，因为您似乎需要良好的活动会话跟踪。

正如我在您的回答中的评论中所说...

如果它在进程中，如果 IIS 应用程序池是回收，IIS被重置，甚至 Windows 重新启动，无论如何，会话将无法生存，而 SQL 服务器或状态服务器（或自定义一）将在任何之后恢复会话这些操作。

...通过使用建议的模式，您将能够编写一些会话跟踪代码，例如，SQL Server 模式将会话存储在可以查询的某个表中，以便实时确定正在发生的事情.

我没有使用 State Server 的经验，也不知道如何从中检索会话，但应该可以。

谈到 SQL Server 模式，我可以成功地进行定期维护，这样我就可以删除幻像会话，检查在最后 X 分钟内执行了某些操作的实际会话（意味着它们处于活动状态......）等等。

【讨论】：

嗨，是的，我想如果我们真的需要“审查”实时会话，另一种模式会更好。然而，我们真正关心的是“进程内会话真的是真实的还是出于任何原因人为地膨胀？”不过，谢谢你，这是一件有用的事情。
好吧，认为每个没有关联会话的 Web 请求都会启动一个会话。由于某些应用程序池回收或某些其他操作可能会改变活动会话，因此您可以拥有 30k 活动会话，然后是 0，再过一秒 4k，依此类推。这就是为什么我建议一种更可靠的会话处理方式：D
我们根本不明白，实际上它相当稳定。只是，有时比我们预期的要高一点。考虑到正在完成的业务量，这实际上与我们预期的相差约 1000 个会话。所以在计算上没有什么，但在统计上很多。
我尽力了哈哈，你会发现使用进程内模式计算会话数没有可靠的方法。
不，这是一个很好的答案，除了，为什么 inproc 数字不可靠？仅仅是它们容易受到应用程序池刷新、iis 重启和 Windows 重启的影响吗？如果是这样，我们喜欢这个答案，那么这些都是我们可以处理的事情。如果还有其他任何可能使它们不可靠的原因，您知道这一点会很有帮助。