CPU 密集型 XmlTextWriter
我有一个 Web 应用程序,它根据通过查询字符串传入的条件动态创建 XML 提要。
这是一个非常简单的应用程序:它读取查询字符串变量,并使用它们将数据(数据库中的缓存数据)格式化为适当的 XML 格式。
返回的XML文件大约有25MB...数据很多。
我使用 XmlTextWriter 构建 XML,然后将其作为“应用程序/八位字节流”返回给请求者 - 他们可以下载的附件。
问题是:构建 XML 似乎使用了 100% 的 CPU,并且导致我的其他应用程序出现问题。
有人有构建如此大的 XML 文件的经验吗?有什么建议可以减少进程对 CPU 的占用吗?
代码示例是:
map.WriteRaw("<?xml version=\"1.0\" encoding=\"UTF-8\"?>");
map.WriteStartElement("rss");
map.WriteAttributeString("version", "2.0");
map.WriteAttributeString("xmlns:g", "http://base.google.com/ns/1.0");
map.WriteStartElement("channel");
map.WriteElementString("link", "http://www.mywebsite.com...");
ProductCollection items = Product.GetCachedSiteProducts();
foreach (Product p in items)
{
map.WriteStartElement("item");
........
map.WriteElementString("description", p.Description);
map.WriteElementString("g:id", p.SiteSku);
map.WriteElementString("g:condition", "new");
map.WriteElementString("g:price", p.Price.ToString() + " USD");
...............
map.WriteEndElement(); //item
}
}
map.WriteEndElement();//channel
map.WriteEndElement();//rss
Response.Write(sw.ToString());
更新:我正在回答我自己的问题..感谢那些要求我发布更多代码的人,当我仔细观察时,这是一个简单的问题。
代码使用“Response.write(map.ToString())”来输出 xml。哇,这效率太低了。将更新代码。谢谢大家!
I have a web application that creates XML feeds on the fly, depending on criteria passed in via the query string.
It is a very simple application: it reads the query string variables, and uses them to format data (cached data from the database) into the appropriate XML format.
The returned XML file is about 25MB... there is a lot of data.
I am using an XmlTextWriter to build the XML, and then returning that to the requestor as an "application/octet-stream" - an attachment they can download.
Question is: Building the XML seems to use 100% of the CPU and is causing problems with my other applications.
Does anyone have experience with building such large XML files? Any tips on making the process less CPU intensive?
Code sample is:
map.WriteRaw("<?xml version=\"1.0\" encoding=\"UTF-8\"?>");
map.WriteStartElement("rss");
map.WriteAttributeString("version", "2.0");
map.WriteAttributeString("xmlns:g", "http://base.google.com/ns/1.0");
map.WriteStartElement("channel");
map.WriteElementString("link", "http://www.mywebsite.com...");
ProductCollection items = Product.GetCachedSiteProducts();
foreach (Product p in items)
{
map.WriteStartElement("item");
........
map.WriteElementString("description", p.Description);
map.WriteElementString("g:id", p.SiteSku);
map.WriteElementString("g:condition", "new");
map.WriteElementString("g:price", p.Price.ToString() + " USD");
...............
map.WriteEndElement(); //item
}
}
map.WriteEndElement();//channel
map.WriteEndElement();//rss
Response.Write(sw.ToString());
UPDATE: I am answering my own question.. thanks to those who asked me to post more code, this was an easy one when I looked more carefully.
Code was using "Response.write(map.ToString())" to output the xml. Wow, that's inefficient. Will update the code. Thanks all!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
立即浮现在脑海中的一个问题是 Response.Writer(sw.ToString())
看起来您正在先写入 StringWriter 然后发送到输出流,为什么这里不直接写入输出流吗?
我不认为仅此一项会对 CPU 使用率产生太大影响或导致 100% CPU 使用率。
什么是
ProductCollection
,当您循环查看时,它看起来是 CPU 使用率高的最可能原因。如果您的代码正确执行IEnumerable
并获取产品 JIT,如果您正在获取某些持久存储的产品(例如,每次迭代都需要一些独立的数据库调用),则可能会导致大量 CPU使用率查看更多源代码很难判断问题的原因是什么。
One immediate concern that springs to mind is
Response.Writer(sw.ToString())
This looks like you are writing to a
StringWriter
first then sending to the output stream, why not write directly to the output stream here?I wouldn't expect that alone to make much difference to CPU usage or cause 100% CPU usage.
What is
ProductCollection
, as you loop over that looks to be the most likely cause of the high CPU usage. If your code is properly doingIEnumerable<Product>
and obtaining products JIT this may cause a lot of CPU usage if you are obtaining the products for some persistent storage (e.g. each iteration requires some independent database calls)Without seeing further source code it's hard to tell what might be the cause of the problem.