Повышение производительности при проектировании схем в IBM Rational ClearQuest

Эта статья представляет собой руководство по применению передовых методов проектирования схем в IBM Rational ClearQuest.

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

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

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

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

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

В этой статье рассматриваются передовые методы для двух задач:

Пользовательская настройка схем;
Общие соображения по перехвату событий.

Если не указано иное, все рекомендации являются общими и не относятся к базам данных, операционным системам или платформам каких-либо конкретных производителей.

Пользовательская настройка схем

Минимизация количества полей для каждого типа записи

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

Большее количество полей увеличивает объем данных, передаваемых по сети между клиентами и серверами. Например, при отображении формы в окне Web-интерфейса ClearQuest вычисляются все свойства полей (типы полей, списки выбора, длины полей, их обязательность). Некоторые часто используемые операции API ClearQuest, например, LoadEntity и GetEntity, запрашивают все поля базы данных.

Поскольку нагрузка на Web-сервер ClearQuest возрастает, потенциальная стоимость большого количества полей возрастает с увеличением числа подключаемых пользователей системы. Серверная база данных с увеличением числа полей будет расти с большей скоростью, что увеличит использование дискового пространства на сервере базы данных. В крупной базе данных, кроме того, увеличится время поиска записи, поскольку при поиске необходимо обойти больше строк и столбцов.

Рекомендации:

Везде, где есть такая возможность, объединяйте поля;
Не создавайте избыточных полей, если в них нет необходимости;
Используйте программу ClearQuest Designer для удаления неиспользуемых полей, а не просто удаляйте их из форм. Никогда не удаляйте поля или столбцы непосредственно из базы данных на сервере;
По возможности избегайте вызовов методов API LoadEntity и GetEntity; лучше выполните запрос по типу записи, чтобы получить только нужные поля.

Соответствие длины типов данных в полях характеру данных

Определение длины поля в соответствии с характером данных может сократить объем данных, передаваемых между приложением и сервером базы данных. Это может быть особенно выгодно, если вы работаете в сети с высоким временем ожидания. Кроме того, этот метод поможет уменьшить размер базы данных и объем памяти, выделяемой для каждого поля. Правильный выбор типа данных для полей (например, использование SHORT_STRING вместо MULTILINE_TEXT, или INT вместо SHORT_STRING) также может способствовать повышению общей производительности базы данных. У каждого производителя баз данных свои требования к этому аспекту использования, поэтому за подробной информацией советую вам обратиться к документации производителя вашей системы управления базами данных.

Рекомендации:

Задайте для всех полей типа SHORT_STRING подходящую длину поля;
Старайтесь как можно меньше использовать типы MULTILINE_TEXT и совсем откажитесь от них, если можно применить другой тип данных. Если в поле не планируется использовать более 255 символов, лучше выбрать тип SHORT_STRING;
У каждого производителя систем баз данных свои рекомендации по использованию типов данных и оптимизации производительности. Изучите рекомендации производителя базы данных по поводу использования типов данных и управления ими.

Использование отдельных форм Submit и Record

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

Ограничение количества списков выбора в формах

Форма, содержащая несколько списков выбора, может оказать существенное отрицательное влияние на производительность. Это особенно актуально в среде ClearQuest Web, в которой отображаемые в списках выбора данные перед тем, как появиться в форме, должны преодолеть определенный путь по сети. Следовательно, ограничение их использования позволит ускорить отклик.

При первичной загрузке формы компьютер, на котором запущен браузер, посылает запрос приложению ClearQuest Web. Этот запрос передается от Web-приложения серверным компонентам Clear Quest. Затем запрос пересылается серверу базы данных, а результаты передаются обратно через тот же набор компонентов, показанных на рисунке 1. Данные передаются в формате XML, и в сети с высоким временем ожидания представление данных в форме списка выбора может занять довольно много времени.

Рисунок 1. Путь, который преодолевают данные списков выбора
Маршруты HTTP, XML и SQL данных показаны в виде стрелок

Рекомендации:

Чтобы сократить объем передаваемых данных, используйте в формах как можно меньше списков выбора;
Не дублируйте поля в формах;
Используйте отдельные формы Submit и Record, чтобы уменьшить количество полей в каждой из них.

Ограничение объема данных в списках выбора

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

Рекомендации:

Избегайте добавления в формы полей со ссылками, которые ссылаются на объемные типы записей (типы записей, имеющие много полей);
Используйте процедуру перехвата (hook) значений списков выбора, чтобы ограничить объем данных, которые будут внесены в список;
Сократите количество элементов в динамически создаваемых списках выбора (динамические списки выбора, содержащие больше 100 элементов, могут быть неэффективными, поэтому использовать их не рекомендуется);
Используйте отдельные формы Submit и Record, чтобы уменьшить количество полей в каждой из них.

Ограничение использования опции Recalculate choicelist (Перерасчет списков выбора)

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

Рекомендации:

Используйте опцию Recalculate choicelist только в тех полях, которые действительно зависят от других изменений формы;
Используйте процедуру перехвата Value Change в сочетании с вызовом метода API InvalidateChoiceList для принудительного обновления поля только при изменении родительского поля;
Используйте отдельные формы Submit и Record, чтобы уменьшить количество полей в каждой из них.

Ограничьте использование зависимых списков выбора

По возможности следует избегать использования зависимых списков выбора с несколькими уровнями зависимостей. Зависимые списки выбора ведут к возникновению той же проблемы, о которой шла речь в рекомендации по использованию опции пересчета списков выбора. В частности, при использовании Web-интерфейса и изменении значения Web-зависимых полей, на сервер посылается цепочка запросов. Эти множественные запросы серверу и от сервера вызывают задержки в представлении данных списка выбора. Изменения взаимно накладываются, если опция Recalculate choicelist выбрана для других несвязанных полей, поскольку они тоже инициируют процедуры пересчета своих списков выбора.

Рекомендации:

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

Ограничение использования журнала аудита Audit Trail

Audit Trail - это пакет, отслеживающий момент смены или изменения состояния полей. Каждое такое изменение записывается в поле журнала аудита, который хранится в базе данных. В ClearQuest можно указать, какие поля нужно отслеживать, а какие нет. Если для отслеживания выбрано больше полей, чем это необходимо, возможны следующие отрицательные эффекты:

Ускорится разрастание базы данных, потому что будет отслеживаться больше данных. Это может отрицательно повлиять на время поиска записей, а также на объем дискового пространства на компьютере сервера базы данных;
Процедуры перехвата BASE-операций для ведения журнала аудита потребляют больше памяти и ресурсов процессора;
В зависимости от количества отслеживаемых полей, ведение журнала аудита может занимать до 10-15% общих временных затрат на изменение родительской записи.

Рекомендации:

Ограничьте аудит только необходимыми полями.

Отказ от использования в формах больших изображений

Изображения, отображаемые в формах, вызывают дополнительную нагрузку на систему при передаче по сети от сервера базы данных к клиентскому компьютеру или Web-компонентам. Чем больше такое изображение, тем больше данных придется передать по сети. В сетях с большим временем ожидания, в том числе во многих глобальных средах, изображения могут ухудшить производительность при загрузке форм.

Рекомендации:

Удалите из форм ненужные изображения;
Убедитесь, что размер изображений не превышает 1 Мбайт;
Используйте отдельные формы Submit и Record, чтобы, по-возможности, сократить количество изображений в каждой форме.

Общие вопросы применения процедур перехвата

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

Многократное использование переменных;
Ограничение использования циклических конструкций;
Ликвидация объектов после того, как они выполнили свою задачу.

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

Сокращение количества процедур перехвата изменений значений полей

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

Каждая процедура перехвата может продуцировать независимый обмен данными между браузером, Web-сервером и сервером приложений. Каждый обмен данными может вызвать необходимость идентификации различными свойствами повторно вычисляемых полей изменений в формах, в том числе, процедур перехвата значений в списках выбора;
Для пользователей в сетях с высоким временем ожидания это выразится в снижении производительности;
Дополнительные непроизводительные издержки из-за процедур перехвата изменений значений полей могут составлять до 15% общего времени создания новых записей.

Рекомендации:

Сократите количество процедур перехвата изменений значений, оставив только те, которые действительно необходимы;
Объедините процедуры перехвата изменений значений в одну процедуру перехвата проверки корректности BASE-операций везде, где только можно. Это увеличит количество процедур перехвата операций, но сократит объем запросов, передаваемых между браузером и Web-сервером ClearQuest.

Сокращение количества процедур перехвата проверки корректности значений в полях

Процедуры перехвата проверки корректности запускаются при смене фокуса в полях собственных клиентов, а также при нажатии кнопок Save или Apply в Web-клиенте или собственном клиенте. Если вы дублируете эти процедуры, когда в них нет необходимости, они вызывают несколько сеансов обмена данными между сервером базы данных и клиентом или сервером ClearQuest Web, поэтому по возможности от них следует отказаться. Если можно, весь повторяющийся код следует собрать в одной процедуре перехвата проверки корректности значений.

Рекомендации:

Сократите количество процедур перехватов проверок корректности значений в полях везде, где только можно;
Объедините несколько процедур перехватов проверок корректности значений в полях в одной процедуре перехвата корректности или перехвата BASE-операции, чтобы сократить обмен данными между браузером и сервером ClearQuest Web.

Сокращение количества процедур перехвата отдельных BASE-операций

Процедуры перехвата операций типа BASE инициируются при каждом выполнении операции любого другого типа (изменение состояния, изменение, запись псевдонима сценария). Как и в двух предыдущих рекомендациях, возможны дополнительные непроизводительные издержки, связанные с несколькими процедурами перехвата отдельных BASE-операций. Результат применения процедур перехватов BASE-операций включает следующие моменты:

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

Рекомендации:

По возможности объединяйте процедуры перехвата BASE-операций в одну процедуру перехвата BASE-операций.

Ограничение использования вызовов объекта Admin session в коде процедуры перехвата

API ClearQuest позволяет создавать в коде процедуры перехвата объекты admin session, когда необходимо использование методов и функций, требующих полномочий администратора, например, администрирование пользователей или базы данных. В использовании этих объектов для стандартных задач (например, для создания или редактирования записи) нет необходимости, поэтому следует избегать таких решений, чтобы предотвратить непроизводительные издержки, появляющиеся при создании экземпляров таких объектов в коде процедур перехвата.

Рекомендации:

Старайтесь избегать создания объектов admin session в коде процедуры перехвата;
Создайте глобально определенный объект admin session в коде процедуры перехвата, чтобы предотвратить создание нескольких admin session.

Отказ от использования методов OutputDebugString и Msgbox в коде перехвата

OutputDebugString - это метод объекта сеанса, который позволяет администраторам ClearQuest вводить отладочную информацию в окне консоли. Этот метод очень полезен во время отладки сценариев в вашем приложении, но он может стать источником непроизводительных издержек для пользователей. Старайтесь использовать метод OutputDebugStrings только в случае необходимости. Чтобы повысить производительность строк OutputDebugString, не удаляя их, добавьте константу в модуль Perl. Константы анализируются в процессе компиляции, а не в процессе выполнения, поэтому производительность повышается, а ветви никогда не учитываются, если значение DEBUG равно false. В листинге 1 показан пример такой ситуации.

Листинг 1. Отладочные значения пересылаются на вывод только тогда, когда значение DEBUG равно 1

                
                # Отладочные значения пересылаются на вывод только тогда, 
                когда значение DEBUG равно 1.
# Пример использования
use constant DEBUG => 1;
if (DEBUG) {
		$session->OutputDebugString("Для целей отладки");
}

Функция Msgbox - это еще одна полезная методика отладки, которую следует использовать с осторожностью. Функция Msgbox отображает диалоговое окно на клиентской машине, которое пользователь должен закрыть для продолжения работы. Однако в Web-интерфейсе диалоговое окно будет отображаться на машине Web-сервера (и не будет видимым, если только на сервере не задана опция обмена данными с рабочим столом Interact with desktop). Пока пользователь не закроет это диалоговое окно, оно будет тормозить один из доступных свободных потоков, используемых приложением. Если эта функция будет вызвана несколько раз через Web-интерфейс, она вполне может занять все доступные потоки, что выразится в кажущемся "зависании" Web-интерфейса. По возможности избегайте использования функции Msgbox или программируйте обход этой ситуации при помощи кода из листинга 2.

Листинг 2. Как предотвратить затормаживание Web-сервера

                
                VBScript:
Dim MySession
Dim CheckWebSession

Set MySession = GetSession
CheckWebSession = Mysession.NameValue("_CQ_WEB_SESSION")

if CheckWebSession = FALSE then
   		msgbox "Информация, которую вы хотите вывести в окне сообщения " 
end if

PERL:
If ( $session->HasValue("_CQ_WEB_SESSION") ) {
	# Мы в рамках Web-сессии, поэтому нам нужен соответствующий код
}
Else {
	# Мы за пределами Web-сессии, поэтому использование окна сообщения 
        # Win32::MsgBox допустимо
Win32::MsgBox ("Информация, которую вы хотите вывести в окне сообщения")
}

Ограничение количества вызовов сторонних приложений в коде процедуры перехвата

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

Рекомендации:

Обязательно напишите код для обхода любых сбоев при помощи вызовов процедур перехвата ошибок, например On Error Resume Next для VBScript и Die для Perl.

Правильное оформление функций в блоки Sub/End Sub

По умолчанию ClearQuest Designer оформляет код процедуры перехвата в схеме (определенной в сетке полей и операций) при помощи блоков заголовков Sub/End Sub и Function/End.

Однако данное значение по умолчанию не задано для глобальных процедур перехвата. Глобальные процедуры перехвата загружаются в оперативную память при запуске приложения ClearQuest. В ClearQuest Web они загружаются при первом входе пользователя в систему базы данных. Если вы не оформите код глобальных процедур перехвата с использованием блоков Sub/End Sub и Function/End, то приложение будет хранить этот код в памяти даже после выхода пользователя из системы. Объем памяти, занимаемый приложением, может значительно вырасти, если несколько пользователей выполнят вход и выход в систему, а код процедур не будет удаляться.

Отказ от частого использования сеансовых переменных

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

Рекомендации:

По возможности используйте сеансовые переменные только там, где это действительно необходимо;
По возможности используйте вместо сеансовых локальные переменные;
По возможности ликвидируйте объекты путем установки их в nothing в VBScript; в PERL можно установить их равными undef и вызвать соответствующий деструктор.

Заключение

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