Blu*_*Fox 20 internet-explorer iis-7 session-state integrated-pipeline-mode
这是我的环境:Win 7上的IIS7.5,.NET 4,App Pool Integrated
web.config中
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
</configuration>
Run Code Online (Sandbox Code Playgroud)
Test.aspx文件
<%@ Page Language="C#" %>
<!DOCTYPE html>
<script runat="server">
protected void OnAction(object sender, EventArgs e)
{
int count;
status.Text = (int.TryParse(status.Text, out count) ? count + 1 : 0).ToString();
Session["test"] = count;
}
</script>
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title>IIS Session Hang Test</title>
<script>
var mutiPostback = function () {
var e = document.getElementById('LinkButton1');
e.click();
e.click();
};
</script>
</head>
<body>
<form id="Form1" method="post" runat="server">
<asp:ScriptManager runat="server" ID="SM">
</asp:ScriptManager>
<asp:UpdatePanel ID="UpdatePanel1" runat="server">
<Triggers>
<asp:AsyncPostBackTrigger ControlID="LinkButton1"/>
</Triggers>
<ContentTemplate>
<asp:Label runat="server" ID="status" />
</ContentTemplate>
</asp:UpdatePanel>
<input type="button" id="button1" onclick="mutiPostback();" value="MultiPostback"/>
<div style="display: none">
<asp:Button ID="LinkButton1" runat="server" OnClick="OnAction" Text="Click" />
</div>
</form>
</body>
</html>
Run Code Online (Sandbox Code Playgroud)
是的,多次回发是故意的,我们注意到这种行为会导致许多请求卡在RequestAcquireState中,并最终阻止服务器接受任何新请求.但是,这个问题只能在IE下观察,而不能在Chrome或FF上观察到.
要测试,请连续单击多个回发按钮.这将更新状态编号.然后,当使用IE时,您将能够观察到该数字停止增加,表明请求卡住了问题.
我能够通过以下IIS和IE版本产生此问题:
IIS版本已经过测试
IE版测试
我观察到的一个异常现象是,当访问本地IIS时,Windows Server 2008 R2上的8.0.7600.16385不会导致此阻塞问题.但是,如果我使用浏览器访问远程IIS,则可以重现该问题.在IE 9上,无论IIS是远程还是本地,我都可以重现该问题.
这是一个屏幕截图,显示了挂起的请求在工作进程的请求列表中的样子.
现在我们已经找到了解决这个问题的几种方法,但在我们的情况下没有一个是可以接受的:
注意:我们还发现,即使我们不直接使用Session,如示例所示,问题仍然存在.IE:如果我们添加一个Global.asax.cs并添加一个空的Session_Start事件处理程序,该请求仍将挂起在RequestAcquireState中.
有没有人知道为什么会发生这种情况?我们如何解决这个似乎只在集成管理管道模式下发生的问题?
从您的描述中,当它尝试获取您的请求的会话对象时,它看起来像IIS死锁.我不会在浏览器中寻找原因,因为这只能是服务器端问题.也许你做不了多少.如果它是一个死锁,那么它就是一个多线程,时序相关的问题.因此,如果不同的浏览器发送时间略有不同的请求,您会得到不同的结果 此外,如果您在本地或远程运行浏览器,您的时间会略有不同.清空会话无济于事,因为问题出在会话获取上.完全禁用会话确实有帮助,因为根本不会获取会话.将AppPool更改为Classic会有所帮助,因为它具有不同的会话管理实现,并且没有死锁.要测试该假设,您可以尝试在客户端的回发之间插入一个人工延迟.这将创建不同的时序条件,并应该影响问题.
我不得不说这些只是基于你的描述和我对IIS的经验的推测.我建议您将AppPool更改为Classic,因为性能下降不是那么大.
我的网站上有类似的问题.在我的情况下,我有一个页面,其中包含许多网格,每个网格都调用一个asmx webservice来检索他们的数据.如果所有的Web请求之前导航离开该页面的用户已经完成,则该用户的会话可能会变得非常慢(至少一两分钟加载页面),但其他用户的会话将是缓慢的影响.对我来说,当我在服务器上安装.NET 4.5时,问题就开始了.
我发现了一个页面在这里:http://forums.asp.net/t/1888889.aspx/1?Question+regarding+a+possible+bug+within+NET+4+5认为这个会谈是一个已知的问题.NET 4.5.如果站点使用集成模式并且浏览器在等待使用ASP.NET会话的页面时断开连接,则可以触发该错误.(有关详细信息,请参阅帖子).
我相信你的双回发案例可能会导致浏览器放弃其中一个请求,所以看起来这样会适用.此外,我和其他人已经注意到这个bug在使用IE时似乎更常见(虽然这只是巧合 - 它不是IE的bug)
该帖子还描述了一种解决方法(调整web.config中的uploadReadAheadSize设置),该解决方法为我解决了问题.
好消息!安装.Net 4.5.1后,会话阻塞问题似乎已得到解决
我已将安装了 .Net 4.5 的 Windows Server 2008 R2 上的测试机器 7.5.7600.16385 升级到 4.5.1,问题就消失了!
| 归档时间: |
|
| 查看次数: |
8178 次 |
| 最近记录: |