.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组数据，将处理

在我的观察，我们能够避免DB for循环调用。循环之前获取的所有数据。当我检查了查询，有子查询，不存在（select * from table）等可以替换为连接，不存在（从表中选择1）

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

如

• 如果有100 rows.there将100项，以XML文件（XBRL）
• 所以我会让50,50和两个线程，这将产生两个xml文件运行。最后我会将两个文件合并成一个xml文件。

因此，第0个问题和第50个问题的处理可以同时开始。目前在For循环中，第0个将处理，第99个将在最后处理。我不确定这个想法。任何可以提出/分享你的想法。任何帮助将不胜感激。在此先感谢

Answer 1

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

我会删除你的计划，多线程，除非UBmatrix公司API称它是线程安全的，所有的光盘的思想I/O当生成XBRL时。

让您的应用程序对内存使用进行配置吗？我正在考虑加载的15-30K行数据，然后可能在处理和写入文件之前转移到对象模型中。如果你开始达到2GB的限制（32位），那么你的进程将进行大量的分页，这是非常流利的。

这个选择是否可能？ 预先生成数据到文件，可能以xml格式。然后，希望UBMatrix有一个接受文件路径和流数据的API，你可以传递文件数据的路径。 （如果数据查询长时间运行，这可能会增加速度）。

Answer 2

30分钟30k查询每秒只有16个查询。这不是很多，除非查询很昂贵。

为了找出答案，运行SQL Profiler并检查每个查询的执行时间。与查询的数量相乘。如果这相当接近30分钟，如果您可以将所有这些查询重写为联接并将结果放入Dictionary或ILookup，那么您很幸运。

如果你需要求助于多线程。检查是否可以升级到.NET 4.然后，您可以在TPL中使用Parallel.ForEach或其他合适的方法来并行处理您的工作。

Answer 3

没有看到代码我不能告诉你正在使用什么类的数据访问，但从你提到的DataTable.Rows我假设你正在使用DataSet/DataTable。如果切换到使用IDataReader和CommandBehavior.SequentialAccess，则可以避免DataSet/DataTable附带的大量不必要的开销。

Answer 4

我建议分析器，但为.NET应用程序。检查大部分时间花在哪里并攻击那个地方。如果是从数据库中获取数据的调用，则可以查看数据库并可能添加一些新的索引和/或重新设计查询。如果它正在拨打UBMatrix，那么除了向谁给你这个任务的人解释外，你可以做的不多。但是在你放弃之前，你可以尝试并行处理，首先确保UBMatrix是线程安全的，就像Simon指出的那样。如果不是，或者你不能告诉你可以作为单独的AppDomain运行并行处理来模拟线程安全。尽管如此，这将花费资源和更复杂的代码。并行处理只有在正常应用程序运行期间可以观察到CPU使用率低于70％并且磁盘没有被过度使用（请查看资源监视器），因此有足够的资源可供使用。

如果使用了很多磁盘，另一种方法可能是检查是否将xml文件写入RAM驱动器会改善任何事情。

无论如何，从分析你的.NET应用程序开始 - 这应该给你一个很好的起点。这里是一个免费的.NET分析器：http://www.eqatec.com/tools/profiler/