ПРИМЕЧАНИЕ

Однажды из третьих рук до меня дошла история об отчете, выдаваемом по правовым причинам, который с самого начала работал неправильно: он заполнял множество страниц содержимым системной памяти при каждом запуске. Так как никто на самом деле не использовал этот отчет, то никто и не заметил, что он не работал. Однако все бумажные версии системной памяти были старательно сохранены, а работник архива исправно ставил галочку в форме, указывающей, что формальное требование создать и сохранить отчет в архиве бьшо выполнено. При перестройке системы, наконец, было обнаружено, что отчет был неисправен, и его удалили. Команда, занимавшаяся перестройкой, сделала вывод, что на самом деле отчет никогда не был нужен. Однако даже когда человеку, ответственному за выставление галочки на старой форме о создании и архивировании отчета, сказали о том, что отчет никогда не работал и не создавался, он потребовал, чтобы отчет вернули на место в старой, неисправной форме.

Способы запуска отчетов

Специальные запросы.

Когда отчет запускается специально вручную, высоки шансы, что инициатор запуска знает о действительной необходимости получения хотя бы части этого отчета. Также вполне вероятно, что его волнует, сколько времени придется ждать, пока отчет будет создан, и большое время вьшолнения отчета может принести бизнесу убытки. Когда отчет нужен пользователю как можно скорее, ему должен быть назначен высокий приоритет. Возможно даже, придется разбить его на параллельные процессы, которым, чтобы уложиться в поставленный срок, придется занять большую часть системных ресурсов. В противном случае полезно убедиться, что запросы не вьшолняются параллельно, таким образом, не снижая производительность процесса с высоким приоритетом. Кроме того, выполнение отчетов с низким приоритетом должно быть автоматически отложено до периода функционирования системы с низкой загрузкой. Этого обычно достаточно, чтобы исключить любое воздействие этих отчетов на производительность.

Автоматические запросы.

Большая часть пакетной нагрузки на бизнес-системы создается автоматически в форме отчетов, для которых давным-давно было создано расписание запусков, и они вьшолняются автоматически каждые день, неделю, или через какой-то другой определенный период времени. Эти периодические пакетные процессы особенно коварны в плане создания нагрузки, так как о них так легко забыть или проигнорировать. Большинство заказчиков отчетов получают намного больше материалов, чем они когда-либо могут прочитать, даже если считать только материалы, созданные людьми, и не учитывать ужасающие автоматические отчеты с обширными наборами неинтересных чисел. Так или иначе, большинство людей, занятых в бизнесе, чувствуют себя несколько неудобно из-за невозможности прочитать и проанализировать огромное количество информации, поступающей на их адрес. Таким образом, вместо того, чтобы жаловаться, что они никогда не читают какой-то страшный отчет, получаемый ежедневно или еженедельно, и доказывать, что это лишь напрасная трата ресурсов, они продолжают смиренно молчать о своей постыдной неспособности совершить невозможное. (Я знаю, я тоже

так поступал. А вы?) Если вы хотите сократить частоту, с которой выдаются огромные отчеты, или удалить их совсем, не ждите, что адресаты отчета пожалуются, что они им не нужны!

Один из способов избавиться от отчетов - задать наводящий вопрос: Мы подозреваем, что отчет больше не требуется, а как вы думаете? Другая стратегия предлагает заявить: Мы собираемся удалить этот отчет, который, по нашему мнению, больше не нужен, если только кто-либо из вас не сообщит, что ему этот отчет требуется. Если же вам нужен этот отчет, то хотите ли вы получать его с той же частотой, или можно выдавать его несколько реже? Моя любимая стратегия - удалить из списка получателей отчета всех кроме себя и посмотреть, будет ли кто-нибудь жаловаться. Если кто-либо проявит себя, отправить ему копию и сохранить отчет, добавив этого человека обратно в список адресатов. Если же никто не пожалуется, то я просто удаляю запланированный отчет через безопасный промежуток времени. Конечно, я бы не рекомендовал делать это, не имея соответствующих полномочий. Для отчетов, получаемых по требованию, вы можете добиться тех же результатов, сделав файл недоступным и подождав жалоб.

Почему производительность пакетных запросов может стать проблемой

Если долго выполняющаяся пакетная задача не создает перегрузки системы или каким-либо другим образом не приносит убытки, не беспокойтесь о ней. В противном случае есть несколько причин, по которым нужно рассмотреть производительность процесса, с разными решениями для каждой причины.

Конечные пользователи ожидают получения результата.

Когда процесс требует, чтобы конечный пользователь запросил создание отчета, а следующая важная задача, которую пользователь может вьшолнить, требует вывода этого отчета, то время создания отчета является узким местом. Распараллеливание процесса создания отчета может стать одним из возможных решений, позволяя нескольким процессорам одновременно решать поставленную задачу. Также можно добиться этого на уровне сервера базы данных при помощи параллельных планов вьшолнения (которые за время моей работы никогда не оказывались полезными) или на уровне приложения, породив несколько прикладных процессов, одновременно решающих задачу, и в конце объединив результаты. Однако намного чаще решение заключается в удалении всего отчета или отдельных его частей. Это самый правильный способ, так как подобный процесс, представляющий собой узкое место в работе, редко требует, чтобы пользователь обработал огромный объем данных; есть лишь небольшая вероятность, что хотя бы несколько строчек отчета действительно нужны конечному пользователю.

Отчет не успевает выполняться за установленный период.

Многим периодически выполняющимся процессам для работы отведено специальное временное окно, обычно в середине ночи или во время выходных. В оставшейся части главы описаны стратегии сокращения времени вьшолнения, позволяющие уложиться в данное временное окно. Однако чаще все-

го самым простым решением оказывается ослабление временных ограничений. Если вы сделаете шаг назад и изучите основные требования бизнеса, то границы временных окон окажутся более гибкими, чем это может показаться с первого взгляда. Обычно период, предназначенный для одного процесса, располагается внутри другого периода большего размера, предназначенного для целого набора процессов. Размер большого периода может оказаться меньше, чем необходимо. Даже если это не так, практически всегда можно реорганизовать процессы в пределах этого набора, чтобы выделить достаточно времени любому данному процессу, если остальные процессы разумно настроены.

Отчет перегружает систему.

Время вьшолнения отчета само по себе может не представлять проблемы, так как отчет никому не нужен мгновенно. Просто убедитесь, что отчет во время вьшолнения захватывает лишь небольшие объемы ресурсов, которых всегда не хватает. Избегайте запуска параллельных процессов, ускоряющих отчет с низким приоритетом за счет более приоритетной работы. Практически всегда можно найти способ, как отложить такие низкоприоритетные процессы на часы бездействия, когда системных ресурсов хватает, и когда воздействие на производительность других процессов достаточно мало.

Типы информации в получаемых отчетах

Каждый запрос определяется (или должен определяться) одним или несколькими требованиями бизнеса. Если отчет никогда не влияет на поведение его получателей, то это всего лишь бесполезная трата ресурсов. В идеальном мире отчет просто сказал бы: Сделай следующее ... и был бы так хорошо разработан, что вы могли бы слепо последовать советам. Так как рекомендуемые действия не нужно было бы подробно описывать, длинные отчеты просто не существовали бы. В реальном мире отчет помогает какому-то человеку прийти к тому же заключению, опираясь на информацию в отчете. Однако все же вероятно, что если отчет намного длиннее описания предлагаемого решения, то он не настолько хорошо отфильтровывает данные, как следовало бы. Поняв, как сократить объем данных до разумного предела, вы не только сделаете запросы быстрее, но также сможете создать намного более полезный отчет.

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

Пользователя интересуют только итоги, средние показатели и прочие агрегации, а строки с деталями ему неинтересны.

В этом случае удалите детальные строки и выдавайте только агрегации. Рассмотрите стратегии, как лучше настроить итоговые запросы, в следующем разделе, Агрегация множества деталей .

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

Бедному менеджеру приходится просматривать детальные записи, чтобы на глаз определить средние значения или их суммы. Это напрасная трата человечес-