根据这里的图表,我应该注意什么才能找出瓶颈?正如您所看到的,请求在负载下平均接近14秒,并且大部分时间归因于New Relic的分析数据中的CLR。在特定页面的性能细分中,它将大部分时间归因于WebTransaction / .aspx页面。
答案 0 :(得分:3)
我看到数据库也被重新加入(橙色),这是由于会话在页面上进行锁定而导致其中一个页面延迟其余页面的接缝。
你也可以阅读: Replacing ASP.Net's session entirely我的建议是完全删除会话调用,如果这是不可能的,找到另一种方法将它们保存在数据库中的某个地方。
实际上,在我的页面中,我提出了所有三种可能的选择。我在没有会话的情况下调用该页面。 2我完成了自定义会话,这些会话是连接到用户cookie的值,最后是3.我已经创建了远离会话的线程,他们在后台进行计算,完成后我会显示结果。
在某些情况下,计算是在没有会话的情况下调用页面的iframe完成的,稍后我会显示结果。
答案 1 :(得分:1)
在Pro版本中,您可以使用“事务跟踪”,它可以帮助确定问题的确切位置。