为什么 UpdatePanel 响应大小会根据替代请求而变化?

发布于 2024-07-15 09:11:26 字数 504 浏览 4 评论 0原文

我们在大页面的一小部分中使用 UpdatePanel,并注意到 IE7 受到 CPU 限制且 UpdatePanel 中的控件需要很长时间(最多 30 秒)才能呈现的性能问题。 我们还注意到,Firefox 似乎没有受到这些延迟的影响。

我们运行了 Fiddler(针对 IE)和 Firebug(针对 Firefox),并注意到真正的问题在于更新面板响应中返回的数据量。 UpdatePanel 控件内有一个表,其中包含许多 ListBox 控件。 真正的问题是,每次响应(从列表框选择中)都会从 30K 变为 430K。 Firefox 在合理的时间内处理 400+K 响应。 无论出于何种原因,IE7 在处理这些数据时都会受到 CPU 限制。

因此,无论我们是否应该使用 UpdatePanel,我们都想弄清楚为什么其他每个异步回发响应都比前一个大 10 倍以上。 当响应在30K范围内时,IE会在一秒内更新显示。 在交替时间,响应时间要长 10 倍以上。 知道为什么 UpdatePanel 会发生这种交替行为吗?

We are using UpdatePanel in a small portion of a large page and have noticed a performance problem where IE7 becomes CPU bound and the control within the UpdatePanel takes a long time (upwards of 30 seconds) to render. We also noticed that Firefox does not seem to suffer from these delays.

We ran both Fiddler (for IE) and Firebug (for Firefox) and noticed that the real problem lied with the amount of data being returned in update panel responses. Within the UpdatePanel control there is a table that contains a number of ListBox controls. The real problem is that EVERY OTHER TIME the response (from making ListBox selections) alternates from 30K to 430K. Firefox handles the 400+K response in a reasonable amount of time. For whatever reason, IE7 goes CPU bound while it is presumably processing this data.

So irrespective of whether or not we should be using an UpdatePanel or not, we'd like to figure out why every other async postback response is larger by a factor of more than 10 than the previous one. When the response is in the 30K range, IE updates the display within a second. On the alternate times, the response time is well over 10 times longer. Any idea why this alternating behavior should be happening with an UpdatePanel?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文