От: Турбонаддув Скорость вашего отчета - Общие правила и рекомендации
Одно преимущество в качестве технического директора (и создателя) на Наветренный состоит в том, что я видел практически все и все, что кто-то может сделать с отчетами, генерацией документов, панелями мониторинга и т. Д. И с тем, что Windward является свободной формой, Я, наверное, видел больше вариантов, чем мой противоположный номер у наших конкурентов. С этой точки зрения я изучил ряд основных приемов и запретов, которые, на мой взгляд, применимы ко всем системам отчетности, документооборота и панели мониторинга.
Дизайн отчета
- Если ничто иное не следует этому правилу - не боритесь с дизайнером отчетов Если вы используете систему, которая предполагает объединенные отчеты (Crystal, SSRS и т. Д.), То создайте объединенный отчет. Если вы попытаетесь работать с разными целями, вам будет сложно, разочарование, и окончательный дизайн будет представлять собой серию компромиссов.
- Используйте соответствующий подход. Например, с Windward вы можете создавать в Word или Excel (или PowerPoint). Тем не менее, у нас есть клиенты, разрабатывающие электронные таблицы с использованием таблиц Word и документы с несколькими таблицами в Excel. Когда они переключаются с Word на Excel (или наоборот), то что-то сложное становится очень легко.
- Поймите и примите ограничения вашего дизайнера. Например, SSRS рассматривает подотчеты как отдельные отчеты, поэтому вы не можете отобразить подотчет в контексте извлекающего его отчета. Это необходимо учитывать при разработке структуры шаблона.
- K.I.S.S. - Держать его просто глупо). У меня были многочисленные случаи, когда при рассмотрении проблем, с которыми сталкивался клиент, основной проблемой было то, что они не понимали, какую информацию они пытаются донести, и какие данные представляют эту информацию. Постарайтесь очень четко понять, что вы представляете и что это за информация .
- Круговые диаграммы - зло.
Системная архитектура
- Если механизм отчетов работает в контексте вашего приложения, создайте несколько потоков для нескольких одновременных запросов отчетов. Генерация отчетов обычно сильно связана с вводом / выводом, поэтому вы получаете здесь большую победу. Наше практическое правило - иметь в два раза больше потоков, чем у вас ядер в вашей системе. (И Hyper-Threading считается как отдельные ядра для этой меры.)
- Купите достаточно памяти. Если вы создаете отчет на 10000 страниц, вам нужно больше ½Gig.
- Следите за своей зависимостью от сетевого ввода-вывода. Если вы загружаете изображения или вложенные отчеты по сети, это сетевое соединение может легко стать определяющим фактором вашей скорости.
- Запустите профилировщик для вашей системы под нагрузкой. Как правило, самый большой удар по времени будет сюрпризом, часто к которому вы можете обратиться.
Доступ к данным
- Получите только те данные, которые вам нужны. Выбор SQL почти никогда не должен начинаться с «select *…», потому что вам редко нужны все столбцы. Выберите только те столбцы, которые необходимо отобразить в отчете.
- Вам не нужно выбирать столбцы, которые вы используете в своих объединениях, сортировать по или где критерии (я вижу это часто). Вы можете использовать столбцы в select, не возвращая их.
- Для сложного объединения добавьте его в базу данных, если это возможно. Если это невозможно, создайте его как набор данных. База данных оптимизирована для обработки сложных объединений в качестве представления, и большинство систем отчетов строят набор данных как временное представление.
- Для данных XML минимизируйте размер набора данных XML. Использование XPath или XQuery требует, чтобы вся структура XML считывалась в память как оптимизированная для DOM или XPath структура. Чем больше набор данных, тем больше использование памяти и больше узлов для обхода в запросе. (Для Windward мы обнаружили, что несколько сотен мегабайт обычно бывают быстрыми, но когда вы получаете гигабайты, это начинает оказывать влияние.)
- Donтянуть данные дважды. Если вы выполняете итерацию по строкам данных (или узлам в XML), то для каждой итерации извлекайте все необходимые данные для этой строки / узла в главном итераторе и затем обращайтесь к ним напрямую. В редких случаях у вас есть оператор выбора внутри итеративного цикла.
- Для SQL убедитесь, что все столбцы, используемые для объединений, и ключевые части сортировки или где индексируются предложения. (Большинство людей скажут все, и дисковое пространство дешево. Но если вы всегда сортируете по last_name, first_name, тогда когда last_name должно быть проиндексировано, first_name должно быть проиндексировано, если пространство позволяет. Жизнь - компромисс.)
- Для XML создайте схему с типизацией данных. Это позволяет избежать двусмысленности, когда XPath / XQuery не только должен делать предположения, но и выполнять дополнительную обработку, определяя, что им следует предполагать.