Підвищення продуктивності при проектуванні схем в IBM Rational ClearQuest, Комерція, Різне, статті

Огляд


Ця стаття являє собою керівництво по застосуванню передових методів проектування схем в IBM Rational ClearQuest.


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


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


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


Варто також відзначити, що хоча ClearQuest являє собою гнучку і персоналізовану систему управління змінами, цей програмний продукт не призначений для використання як комплексної середовища розробки програм. Його завдання – допомога розробнику в налаштуванні готових схем, а не повна переробка лежачого в основі реалізації програми бази даних.


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


У цій статті розглядаються передові методи для двох завдань:



Якщо не вказано інше, всі рекомендації є загальними і не відносяться до баз даних, операційним системам або платформ-яких конкретних виробників.


Користувацька настройка схем


Мінімізація кількості полів для кожного типу запису


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


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


Оскільки навантаження на Web-сервер ClearQuest зростає, потенційна вартість великої кількості полів зростає зі збільшенням числа підключаються користувачів системи. Серверна база даних із збільшенням числа полів буде рости ще швидше, що збільшить використання дискового простору на сервері бази даних. У великій базі даних, крім того, збільшиться час пошуку записи, оскільки при пошуку необхідно обійти більше рядків і стовпців.


Рекомендації:



Відповідність довжини типів даних в полях характеру даних


Визначення довжини поля у відповідності з характером даних може скоротити обсяг даних, переданих між додатком і сервером бази даних. Це може бути особливо вигідно, якщо ви працюєте в мережі з високим часом очікування. Крім того, цей метод допоможе зменшити розмір бази даних і об’єм пам’яті, що виділяється для кожного поля. Правильний вибір типу даних для полів (наприклад, використання SHORT_STRING замість MULTILINE_TEXT, Або INT замість SHORT_STRING) Також може сприяти підвищенню загальної продуктивності бази даних. У кожного виробника баз даних свої вимоги до цього аспекту використання, тому за детальною інформацією раджу вам звернутися до документації виробника вашої системи управління базами даних.


Рекомендації:



Використання окремих форм Submit і Record


Програма ClearQuest Designer дозволяє створити два унікальних типу форм для кожного типу запису: Submit і Record. Кожна з цих форм може включати свій набір полів і зображень. Якщо необхідно, щоб в формах було багато полів і зображень, краще створити окремі форми Submit і Record. Такий поділ дозволить скоротити обсяг непотрібних даних, які доводиться відображати для користувачів при кожній передачу або зміну запису. Воно також сприяє скороченню часу за рахунок відмови від завантаження непотрібних даних в списках вибору, які обчислюються при завантаженні форм і зміну значень.


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


Форма, що містить декілька списків вибору, може зробити істотний негативний вплив на продуктивність. Це особливо актуально в середовищі ClearQuest Web, в якій відображаються в списках вибору дані перед тим, як з’явитися в формі, повинні подолати певний шлях по мережі. Отже, обмеження їх використання дозволить прискорити відгук.


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


Рисунок 1. Шлях, який долають дані списків вибору

Рекомендації:



Обмеження обсягу даних у списках вибору


Наявність великої кількості даних в списках вибору форми також може привести до зниження продуктивності, оскільки дані передаються за допомогою тієї ж багатоетапної процедури, описаної в попередньому розділі. Цей обсяг важко висловити в точних цифрах, адже кожна середа унікальна. Найкраще самому протестувати використовувану середовище, щоб визначити порогове значення допустимого обсягу даних. Крім того, важливо не допускати наявності зайвих даних в списках вибору не тільки тому, що це призводить до проблем з продуктивністю, але ще й тому, що користувачам нелегко знайти в них потрібний варіант.


Рекомендації:



Обмеження використання опції Recalculate choicelist (Перерахунок списків вибору)


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


Рекомендації:



Обмежте використання залежних списків вибору


По можливості слід уникати використання залежних списків вибору з кількома рівнями залежностей. Залежні списки вибору ведуть до виникнення тієї ж проблеми, про яку йшла мова в рекомендації по використанню опції перерахунку списків вибору. Зокрема, при використанні Web-інтерфейсу і зміні значення Web-залежних полів, на сервер надсилається ланцюжок запитів. Ці множинні запити сервера і від сервера викликають затримки в поданні даних списку вибору. Зміни взаємно накладаються, якщо опція Recalculate choicelist обрана для інших незв’язаних полів, оскільки вони теж ініціюють процедури перерахунку своїх списків вибору.


Рекомендації:



Обмеження використання журналу аудиту Audit Trail


Audit Trail – це пакет, що відслідковує момент зміни або зміни стану полів. Кожне таке зміна записується в поле журналу аудиту, який зберігається в базі даних. В ClearQuest можна вказати, які поля потрібно відслідковувати, а які ні. Якщо для відстеження вибрано більше полів, ніж це необхідно, можливі наступні негативні ефекти:



Рекомендації:



Відмова від використання у формах великих зображень


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


Рекомендації:



Загальні питання застосування процедур перехоплення


Процедури перехоплення займають значне місце в проектах схем. При написанні коду процедури перехоплення завжди рекомендується використовувати кращі практичні методи. Погано продуманий об’ємний код процедур перехоплення може привести до нестійкої продуктивності схеми, а Web-інтерфейс додатково посилить ситуацію. Деякі методи можуть сприяти зменшенню обсягу пам’яті, займаної вашим додатком, і його часу виконання, в тому числі:



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


Скорочення кількості процедур перехоплення змін значень полів


Процедури перехоплення змін значень полів запускаються кожен раз, коли значення поля змінюється, а користувач переміщає фокус на інше поле. Якщо у вас кілька полів, асоційованих з об’ємними процедурами перехоплення значень, це гарантує непродуктивні витрати. Описаний ефект багаторазово посилюється Web-інтерфейсом. Негативні наслідки використання великої кількості процедур перехоплення змін значень такі:



Рекомендації:



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


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


Рекомендації:



Скорочення кількості процедур перехоплення окремих BASE-операцій


Процедури перехоплення операцій типу BASE ініціюються при кожному виконанні операції будь-якого іншого типу (зміна стану, зміна, запис псевдоніма сценарію). Як і в двох попередніх рекомендаціях, можливі додаткові непродуктивні витрати, пов’язані з декількома процедурами перехоплення окремих BASE-операцій. Результат застосування процедур перехоплень BASE-операцій включає наступні моменти:



Рекомендації:



Обмеження використання викликів об’єкта Admin session в коді процедури перехоплення


API ClearQuest дозволяє створювати в коді процедури перехоплення об’єкти 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 працює повільніше, ніж можна було очікувати.


Рекомендації:



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


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


Проте дане значення за замовчуванням не задано для глобальних процедур перехоплення. Глобальні процедури перехоплення завантажуються в оперативну пам’ять при запуску програми ClearQuest. В ClearQuest Web вони завантажуються при першому вході користувача в систему бази даних. Якщо ви не оформите код глобальних процедур перехоплення з використанням блоків Sub/End Sub і Function/End, То додаток буде зберігати цей код в пам’яті навіть після виходу користувача з системи. Об’єм пам’яті, займаний додатком, може значно зрости, якщо кілька користувачів виконають вхід і вихід в систему, а код процедур не буде віддалятися.


Відмова від частого використання сеансових змінних


Сеансові змінні не слід використовувати дуже часто. Сеансові змінні, як видно з їх назви, залишаються в пам’яті протягом усього сеансу. Якщо створювати їх без необхідності, то обсяг пам’яті, займаної додатком, і навантаження на сервер під час роботи в Web-оточенні, зростуть.


Рекомендації:



Висновок


Проектування схеми – важлива складова процесу розгортання рішення ClearQuest. Це ітеративний процес, який вимагає ретельного планування і тестування для забезпечення безперебійної роботи на кожному етапі проекту. Важливо тестувати схему не тільки в процесі первинного розгортання, а й при кожній зміні в схемі, щоб мінімізувати можливі наслідки погано продуманого проекту. Рекомендації у цій статті можна використовувати при створенні нового проекту схеми, а також для вже існуючих проектів при уточненні схеми. Проектування схеми з урахуванням передового досвіду допоможе уникнути непередбачених реакцій системи і буде сприяти створенню більш стійкою в роботі і передбачуваною реалізації.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*