【发布时间】：2013-11-03 05:28:07
【问题描述】：
我一直在对供应商编写的生产 Web 应用程序 (.NET 4) 进行故障排除。
在过去的几周里，我们在这个网站上遇到了一些速度问题。
最初，重点一直放在数据库方面。现在我觉得排除这部分方程式很舒服......我今天花了很多时间调试 Web 应用程序，看看实际的速度问题来自哪里。
我发现，在 Web 应用程序的这个特定部分中，它会打开一个新的 Internet Explorer 窗口以显示从数据库返回的大量 XML 数据。
查看代码并使用调试器尝试找出发生了什么...这是我发现的：
当这个特定页面上的代码完成填充所有内容时，iexplore 进程拥有一个 692,044K 的私有工作集。这似乎是 msxml3.dll 的许多进程中 activex 控件的结果。
经过一番研究，我发现了这篇微软文章： http://support.microsoft.com/?scid=kb%3Ben-us%3B815112&x=15&y=14
它指出： “Microsoft 不支持在 .NET 应用程序中使用 MSXML（Microsoft 基于 COM 的 XML 解析器）。 MSXML 使用与 .NET Framework 不兼容的线程模型和垃圾收集机制。通过 COM 互操作性在 .NET 应用程序中使用 MSXML 可能会导致难以调试的意外问题。 Microsoft 不推荐或不支持在 .NET 代码中直接实例化和使用 MSXML 对象，也不推荐或支持跨互操作边界编组 MSXML 接口指针。”
这是创建 activex 对象的代码的一部分：
var oTmp = new ActiveXObject("MSXML2.Domdocument");
oTmp.loadXML('<plan_data>' + returnValue + '</plan_data>');
随着内存的增加，进程资源管理器会拾取几个加载到 iexplore 进程中的 MSXML3.dll。即使在关闭此特定窗口之后，它似乎也无法正确清理自身，因为它仍然使用大约 220,000 K 的内存。（可能是由于上面列出的垃圾收集机制）。
所以，我的问题是...这里有熟悉此内容的人可以就这是否看起来像是 Web 应用程序中设计不佳的部分提供一些建议吗？
我希望能够将此信息提供给开发人员并让他们查看，但我希望有人可以先给我一些专业建议。
谢谢。
【问题讨论】：
-
为什么在测量瓶颈之前将重点放在数据库方面？ ;-) 优化的第一条规则是“先衡量”。
-
一个问题：为什么需要“显示从数据库返回的大量 XML 数据”？用户不会以任何明智的方式阅读大量 XML....这个 XML 最终会在哪里？
-
嗯，这就是为什么开发者（不是我）使用大量的activex对象来显示数据的原因。它正在以更小的集合的形式回归，显然是大量的单线程 MSXML 容器。
-
废话！近 20 年来，有很多东西一直在愉快地使用 MSXML！你发现了一个瓶颈......现在你需要弄清楚如何处理它。盲目地说“MSXML 不好”要么是虚伪的……要么是愚蠢的。实际问题比“MSXML 与无 MSXML”更深。恕我直言...
-
我关心的不是 MSXML 本身，而是 .NET 代码中的实现，这似乎与上面列出的微软建议背道而驰。