Оптимизация производительности для настольных приложений .net 3.5 и SQL Server 2008

Question

Мне нужно улучшить производительность настольного приложения (.net), которое было разработано для чтения базы данных и создания XML-файлов на основе XBRL (расширяемый язык отчетности Bussiness).Он использует UBMatrix для создания таксономий XBRL.

Приложение работает нормально, если размер определенных данных невелик.Но для создания файлов приложению потребуется более 30 минут, если объем данных большой.Данные клиента всегда огромны / велики.Таким образом, приложению требуется больше времени для генерации файлов.

Моя задача - оптимизировать приложение, чтобы сократить время, затрачиваемое на создание XML-файлов.Когда я проверил приложение, я обнаружил, что приложение работает таким образом.

Запускает

• Создание соединения с БД
• получает первый набор данных (этотаблица (table1) слишком большая).И запрос вернет около 15-30 K строк в dataTable
• для цикла 0 в datatable.Rows.count
  • проверяет некоторые условия
  • получить данные из базы данных.(эта таблица (таблица2) также слишком велика, чем (таблица1).
  • отправка данных в форму xbrl и запись в xml (это выполняется сторонним приложением под названием UBMatrix). Редактировать код невозможнокоторый создает файл xbrl-xml.

Аналогичным образом будет обрабатываться 3–4 набора данных

По моим наблюдениям, мы можем избежать вызовов БД дляцикл. Получить все данные до цикла. Когда я проверил запросы, были подзапросы, не существует (выберите * из таблицы) и т. д. можно заменить на объединения, не существует (выберите 1 из таблицы)

НоТем не менее, приложение должно обрабатываться в цикле. Я также думаю об использовании потоков, чтобы я мог создавать потоки на основе размера данных и обрабатывать их одновременно.

Например

• если есть 100 строк. будет 100 записей в xml-файле (XBRL)
• Так что я сделаю 50,50 и запустлю два потока, которые сгенерируют два xml-файла. В конце я объединю два водин XML-файл.

Таким образом, обработка 0-го вопроса и 50-го вопроса может быть начата одновременно.В настоящее время в цикле for 0th будет обрабатываться, а 99th - только в конце.Я не уверен насчет идеи.Может ли кто-нибудь предложить / поделиться своими идеями.любая помощь будет оценена.Заранее спасибо

Answer 1

Я предлагаю профилировщик, но для приложения .NET.Проверьте, где он проводит большую часть времени и атакуйте это место.Если это вызовы для получения данных из БД, вы можете посмотреть базу данных и, возможно, добавить новые индексы и / или изменить дизайн запросов.Если это касается звонков в UBMatrix, вы, вероятно, ничего не можете сделать, кроме как получить объяснение тому, кто дал вам эту задачу.Но прежде чем сдаться, вы можете попробовать параллельную обработку, сначала убедившись, что UBMatrix является поточно-ориентированным, как указал Саймон.Если это не так или вы не можете сказать, что вы можете запустить параллельную обработку в виде отдельных доменов приложений, чтобы имитировать безопасность потоков.Это будет стоить ресурсов и более сложного кода.Параллельная обработка будет иметь смысл только в том случае, если во время нормального запуска приложения вы можете наблюдать загрузку ЦП ниже 70%, а диск не используется чрезмерно (проверьте с помощью Resource Monitor), поэтому есть запасные ресурсы для использования.

Если дискчасто используется другой способ проверить, улучшит ли создание xml-файлов для записи на RAM-диск что-либо.

В любом случае, начните с профилирования вашего .NET-приложения - это должно дать вам хороший стартточка.Вот бесплатный профилировщик .NET: http://www.eqatec.com/tools/profiler/

Answer 2

30 тыс. Запросов за 30 минут - это всего 16 запросов в секунду.Это не очень много, если запросы не дорогие.

Чтобы узнать, запустите SQL Profiler и проверьте время выполнения каждого запроса.Умножьте на количество запросов.Если это достаточно близко к 30 минутам, вам повезет, если вы сможете переписать все эти запросы в объединение и поместить результат в Dictionary или ILookup.

, если вам нужно использовать многопоточность.Проверьте, есть ли у вас возможность обновления до .NET 4. Затем вы можете использовать Parallel.ForEach или другой подходящий метод в TPL для распараллеливания вашей работы.

Answer 3

Не видя код, я не могу сказать, какие классы вы используете для доступа к данным, но из вашего упоминания DataTable.Rows я предполагаю, что вы используете DataSet / DataTable. Если вы переключитесь на использование IDataReader с CommandBehavior.SequentialAccess , вы сможете избежать многих ненужных накладных расходов, связанных с DataSet / DataTable.

Answer 4

Не совсем ответ, просто очень большой комментарий:

Я бы убрал многопоточность из ваших планов, если только API UBMatrix не заявит, что оно поточно-ориентированное, думая обо всех дисковых операциях ввода-вывода при созданииXBRL.

Профилировали ли вы ваше приложение для использования памяти?Я имею в виду загружаемые 15-30 тыс. Строк данных, которые затем можно перенести в объектную модель перед обработкой и записью в файл.Если вы начнете достигать предела в 2 ГБ (32 бита), то ваш процесс будет выполнять много пейджинга, что является sooo slooow.

Будет ли эта альтернатива возможной?Предварительно сгенерируйте данные в файл, возможно в формате XML.Затем, надеясь, что UBMatrix имеет API, который принимает путь к файлу и передает данные, вы можете просто передать путь к данным вашего файла.(Это больше в случае, если это проблема с памятью, но она может ускорить процесс, если запросы данных выполняются долго.)