.net 3.5桌面应用程序和SQL Server 2008的性能优化

Question

我需要提高桌面应用程序（.net）的性能，该应用程序旨在读取数据库并基于XBRL（可扩展业务报告语言）创建xml文件。 它使用UBMatrix创建XBRL分类法。

如果特定数据的大小很小，则该应用程序可以正常运行。 但是，如果数据很大，则应用程序将花费30分钟以上的时间来生成文件。 客户数据总是很大/很大。 因此，应用程序需要更多时间来生成文件。

我的任务是优化应用程序，以减少创建xml文件所需的时间。 当我检查应用程序时，我发现该应用程序正在以这种方式运行。

开始

• 创建与数据库的连接
• 获取第一组数据（此表（表1）太大）。 查询将返回大约15-30 K行到dataTable
• for循环0到datatable.Rows.count
  • 检查一些状况
  • 从数据库获取数据。 （此表（table2）也比（table1）大。
  • 发送数据以形成xbrl并写入xml（这是通过名为UBMatrix的第三方应用程序完成的）。 无法编辑创建xbrl-xml文件的代码。

同样，将处理3到4组数据

在我看来，我们可以避免在for循环中进行db调用。 在循环之前获取所有数据。 当我检查查询时，有子查询，不存在（从表中选择*）等可以替换为联接，不存在（从表中选择1）

但是仍然需要应用程序进行循环处理。 我也在考虑使用线程，以便我可以根据数据大小创建线程并同时处理它。

例如

• 如果有100行，那么xml文件（XBRL）会有100个条目
• 所以我将使50,50并在两个线程中运行，这将生成两个xml文件。 最后，我将把两者合并为一个xml文件。

因此，第0个问题和第50个问题的处理可以同时开始。 当前在for循环中，第0个将处理，第99个将仅在最后处理。 我不确定这个主意。 可以提出任何建议/分享您的想法。 任何帮助将不胜感激。 提前致谢

Answer 1

并不是真正的答案，只是一个非常大的评论：

我会从您的计划中删除多线程，除非UBMatrix API声明它是线程安全的，并在生成XBRL时考虑所有光盘I / O。

您是否已针对您的应用配置了内存使用情况？ 我正在考虑要加载15-30K的数据行，然后在处理和写入文件之前将其转移到对象模型中。 如果您开始达到2GB的限制（32位），那么您的进程将进行大量分页，这太慢了。

这种选择是否可能？ 将数据预生成为文件，可能是xml格式。 然后，希望UBMatrix有一个可以接受文件路径并传输数据的api，您可以将路径传递给文件数据。 （这更多地是为了解决内存问题，但是如果数据查询长时间运行，它仍然可以加快速度。）

Answer 2

30分钟内进行3万次查询仅每秒16次查询。 除非查询很昂贵，否则这不是很多。

要找出答案，请运行SQL Profiler并检查每个查询的执行时间。 乘以查询数量。 如果在30分钟左右可以比较合理，那么您很幸运，可以将所有这些查询重写为ILookup并将结果放入Dictionary或ILookup 。

如果您需要诉诸多线程。 检查是否可以升级到.NET4。然后可以使用Parallel.ForEach或TPL中的其他合适方法来并行化工作。

Answer 3

没有看到代码，我无法告诉您正在使用哪些类进行数据访问，但是从您提到的DataTable.Rows开始，我假设您正在使用DataSet / DataTable。 如果将IDataReader与CommandBehavior.SequentialAccess一起使用，则可以避免DataSet / DataTable附带的许多不必要的开销。

Answer 4

我建议使用Profiler，但适用于.NET应用。 检查大部分时间都花在哪里，然后攻击那个地方。 如果是从数据库获取数据的调用，则可以查看数据库并添加一些新索引和/或重新设计查询。 如果它是在UBMatrix的调用中，则除了向向您提供此任务的人员提供解释外，您可能无能为力。 但是在放弃之前，您可以尝试并行处理，如Simon所指出的，首先要确保UBMatrix是线程安全的。 如果不是，或者您不能告诉您可以将并行处理作为单独的AppDomain运行，以模仿线程安全性。 但是，这将以资源和更复杂的代码为代价。 并行处理仅在正常运行应用程序时可以观察到CPU使用率低于70％且磁盘未过度使用（请与Resource Monitor一起检查），因此有可用的备用资源才有意义。

如果大量使用磁盘，另一种方法可能是检查将xml文件写入RAM驱动器是否可以改善任何情况。

无论如何，从配置.NET应用程序开始-应该为您提供一个良好的起点。 这是一个免费的.NET探查器： http : //www.eqatec.com/tools/profiler/