.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/