Принципи і техніки аналізу та підвищення продуктивності IBM Rational ClearCase Частина 1: Аналіз і моніторинг продуктивності, Комерція, Різне, статті

Зміст



Введення


Скільки разів за день ваша група розробників підтверджує взяття на редагування і реєструє здачу на контроль артефактів бази версій об'єктів (VOB) з вашого примірника IBM Rational ClearCase? Як багато збірок продукту вони виконують? Якщо ви задумалися над питанням, скільки дій з Rational ClearCase виконує ваша група розробників за життєвий цикл проекту, то легко зрозумієте, що навіть невелике збільшення швидкості цих операцій допоможе значно заощадити час.


За минулі вісім років я працював з групами різного складу і місця розташування, допомагаючи їм більш дієво і раціонально використовувати Rational ClearCase для управління конфігурацій ПЗ (SCM). Я думаю, справедливо буде сказати, що всі вони будуть вдячні за будь-яку допомогу, яка дозволить їм виконати більшу кількість роботи за день, і, звичайно ж, швидше закінчити самі проекти. Ким би ви не були – адміністратором Rational ClearCase, вирішальним проблеми продуктивності, або ж ви всього лише оцінюєте можливості підвищення продуктивності для поліпшення ефективності праці групи розробників – завжди корисно мати план.


Ця стаття, яка є Частиною I із серії опису принципів і технік щодо поліпшення продуктивності IBM Rational ClearCase, надає огляд принципів оцінки продуктивності, а також поради, як застосувати ці оцінки в середовищі Rational ClearCase. Тут представлений підхід, добре себе зарекомендував при діагностиці проблем продуктивності та знаходженні відповідного рішення, і використаний практичний приклад для ілюстрації описаного підходу.


У Частині II цієї серії будуть обговорюватися прийоми використання певних інструментів і практик для аналізу і поліпшення продуктивності IBM Rational ClearCase у вашій організації.


Початок роботи


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



Раптове гальмування системи зазвичай простіше діагностувати і виправити, так як подібні ефекти зазвичай пов'язані з недавніми змінами в робочому оточенні IBM Rational ClearCase. Проблеми продуктивності, проявляються за тривалий інтервал часу – іноді за рік чи більше – розпізнати значно складніше.


У багатьох випадках питання, які слід поставити для діагностики проблем продуктивності, схожі на ті, які вирішуються при налагодженні програми. Вони подібні питань, які лікар може задати пацієнту для виявлення джерела болю. Чи є проблема повторюється або короткочасною? Чи є вона періодичної? Відбувається вона в певний час дня? Асоційована вона з певною командою або дією? Наприклад, при роботі з IBM Rational ClearCase, чи виникає проблема тільки тоді, коли складання виконується з використанням clearmake або деяких інших засобів? І також як і у випадку з програмними помилками, легше все працювати з проблемами продуктивності, які можна легко відтворити, наприклад, пов'язаними з певними командами. Періодично виникають проблеми за своєю природі значно складніші.


У міру того, як у вас з'явиться краще розуміння, які саме ефекти викликає проблема, ви можете почати більш глибоке вивчення того, що саме відбувається в різних системах, що знаходяться у віданні IBM Rational ClearCase.


Перший принцип аналізу та моніторингу продуктивності


Системи являють собою вільну ієрархію незалежних ресурсов2:



Перший принцип аналізу продуктивності полягає в тому, що в більшості випадків низька продуктивність викликана нестачею одного або декількох подібних ресурсів. При аналізі використання цих ресурсів у середовищі IBM Rational ClearCase, перш за все я звертаю увагу на явні патологічні симптоми і конфігурації – тобто на речі, які просто несумісні один з одним. Як приклад наведу нещодавно проведений аналіз проблем продуктивності, що виникли у замовника. При швидкому перегляді процесів, які виконуються на хості, було виявлено виконання 192 процесів Oracle, на додаток до завдань Rational ClearCase. Незалежно від того, чи насправді це викликало проблеми продуктивності, відразу стало зрозуміла необхідність оцінки можливостей комп'ютера для підтримки такого кількості інтенсивно використовують пам'ять процесів.


Фактично подібна ситуація приводить нас до іншого принципу аналізу продуктивності: будьте обережніше з висновками. Часто одна явна проблема буде маскувати менш очевидну, причому остання і буде явною причиною зниження продуктивності. Крім того, будьте обережні і не дозволяйте кому-небудь підштовхувати вас до висновку, наприклад, у випадку, якщо хтось вже має ідею про те, що ж саме викликало проблему. Важливо усвідомлювати, що ця ідея є всього лише здогад і може не бути реальною причиною проблеми.


При аналізі продуктивності я часто згадую слова відомого фізика Ричарда Фейнмана: "Перший принцип полягає в тому, що ви не повинні обдурити самого себе, і серед кандидатів на обдурення ви є найбільш доступним ". Особливо важливо пам'ятати про головну пастці – вірі в те, що саме перша виявлена ​​причина і є головною проблемою.


Поуровневом підхід до вивчення


Вивчення проблеми продуктивності IBM Rational ClearCase може бути досить складним завданням. Я виявив, що велику допомогу приносить розбиття проблеми на три рівня, які складають "стек продуктивності", як показано на малюнку 1. На самому нижньому рівні знаходяться операційна система й апаратне забезпечення, таке як пам'ять, процесори та диски. Вище цього розташовуються настроюються параметри IBM Rational ClearCase, такі як розмір кеша. І на самому верхньому рівні розташовані приложения. У Rational ClearCase, простір додатків включає скрипти, що виконуються при операціях Rational ClearCase, і тригери Rational ClearCase, автоматично виконуються до або після операції Rational ClearCase.

Малюнок 1: стек продуктивності IBM Rational ClearCase


Виходячи з мого досвіду – і виключаючи явно патологічні ситуації – у міру переміщення вгору за рівнями стека продуктивності, ви можете очікувати десятикратного збільшення викликаного вашими зусиллями зростання продуктивності. Витративши тиждень на настройку та відшліфовування параметрів ядра операційної системи, ви зможете домогтися деякого збільшення продуктивності. Але якщо ви витратите якийсь час на настройку параметрів кешу IBM Rational ClearCase, то отримаєте десятикратне збільшення продуктивності, в порівнянні з тим, чого ви домоглися, налаштовуючи ядро. При роботі з ще більш високорівневих ланкою, та внесення поліпшень на рівні додатків, ваш виграш в продуктивності буде приблизно на два порядки більше, ніж досягнутий при роботі з низьким рівнем. Якщо ви зможете оптимізувати скрипти і тригери, або ж взагалі усунути їх, то ефект буде досить значний. У Частині II цієї серії буде більш докладно показано, як оптимізувати прикладний рівень для підвищення продуктивності.


Враховуючи вищесказане, ви можете вирішити, що непогано було б почати з прикладного рівня. Але з принципових міркувань при виконанні аналізу продуктивності я завжди починаю роботу з нижньої ланки стека. Аналіз починається з рівня апаратних засобів і операційної системи, і потім з'ясовується, чи немає патологічних ситуацій. Потім я переходжу до налаштованим параметрами бази даних, а прикладний рівень розглядаю в останню чергу. Подібний порядок вивчення обумовлений цілою низкою причин. Перш за все, насправді найбільш просто подивитися на апаратні засоби і операційну систему, щоб подивитися, чи не відбувається там що-небудь незвичайного. Є досить загальні інструменти, прості і досить швидкі в роботі, і будь-які нестандартні ситуації не сховаються від вашої уваги – наприклад, такі, як 192 процесу Oracle. Подібним чином, на більш верхньому рівні, IBM Rational ClearCase надає утиліти, які покажуть вам частоту звернень до кешу і пристосувати та кеш. Ці утиліти також дуже прості у використанні.


І останнім я вивчаю прикладний рівень, так як це пов'язане з багатьма труднощами. Цей рівень технічно більш складний, тому що він складається з багатьох взаємопов'язаних компонентів. Крім того, це може бути значно більш складно з політичної точки зору, так як скрипти і тригери зазвичай мають своїх власників, які створили їх за деякою причини і чиї підходи до вирішення питань можуть не збігатися з вашими. Деякі стають в оборонну позицію навіть при натяку на те, що вони могли щось зробити неправильно. Але часто немає нічого "неправильного"; просто справа в тому, що за самою своєю природі скрипт зроблений повільним.


Іншою причиною початку роботи на самому нижньому рівні є проста обачність. Вам слід переконатися в правильності виконання системою основних операцій. Хоча я починаю саме з цього місця, зовсім необов'язково витрачати тут багато часу – ви не отримаєте достатньо серйозного результату від ваших зусиль. Також я не буду витрачати багато часу на настроюються параметри IBM Rational ClearCase. Зазвичай перевірка роботи кешей проходить досить швидко, і після налаштування параметрів можна рухатися далі.


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


Ітерація, ітерація, ітерація


Налаштування продуктивності є ітеративним процесом:



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


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


Де дивитися


IBM Rational ClearCase є розподіленим додатком. У його роботи залучено безліч хостової комп'ютерів, а також деякі загальні мережеві ресурси. Для вирішення проблем продуктивності я волію сприймати Rational ClearCase як трикутник, чиїми кутами є VOB-хости (машини, що виконують процес vob_server), хости перегляду (машини, виконують процес view_server), і клієнт (див. малюнок 2). При проведенні аналізу продуктивності я перевіряю кожен кут трикутника. Перевіряю стек продуктивності для кожного з цих хостів для впевненості, що кожен має достатню кількість пам'яті та інших низькорівневих ресурсів, і шукаю аномальні ситуації.

Рисунок 2: Середа IBM Rational ClearCase


Хост VOB


У середовищі IBM Rational ClearCase постійна репозитарій програмних артефактів містить один або більшу кількість об'єктів VOB, розташованих на одному або більше об'єктах VOB.


VOB-сервери особливо чутливі до обсягу оперативної пам'яті, так як продуктивність поліпшується при кешуванні баз даних VOB. Використовуючи більший обсяг пам'яті, VOB-сервер може зберігати велику частину бази в оперативній пам'яті. Як результат, при цьому буде потрібно рідше запитувати дані з жорсткого диска, уникаючи таким чином процесу, який в тисячі разів повільніше, ніж доступ до пам'яті. Для VOB-хоста, Інструкції з експлуатації BM Rational ClearCase рекомендує мінімальний обсяг оперативної пам'яті 128 Мбайт, або ж половину розміру баз даних VOB, які хост буде підтримувати. Зверніть увагу на рада з Керівництва адміністратора: "Достатній обсяг фізичної пам'яті є найбільш важливим фактором для продуктивності VOB; збільшення розміру основної оперативної пам'яті хостів VOB є найбільш простим (і найбільш економічним) способом, щоб прискорити доступ до VOB і збільшити кількість паралельно працюючих користувачів без зниження продуктивності системи ".


Зазвичай у VOB-хоста IBM Rational ClearCase є не так багато параметрів, що настроюються. Існують установки, які ви можете використовувати для контролю за кількістю серверних процесів, але вони рідко бувають потрібні. Існують інші параметри блокування (lockmgr), які можна змінити при виявленні помилок в log-файлі Rational ClearCase. У подібному випадку зверніться до документації Rational ClearCase або в службу технічної підтримки IBM Rational, фахівці якої постараються дати докладні вказівки, що саме вам слід робити.


View-хости


View-сервер управляє завданням конкретного уявлення Rational ClearCase. На практиці view-сервер не повинен бути запущений на тому ж самому фізичному комп'ютері, що і VOB-сервер. У деяких випадках view-сервер і клієнт можуть працювати на одній і тій же машині, що визначається конфігурацією.


Як і у випадку VOB-хоста, перші області для перевірки залишаються фундаментальними – пам'ять, інші запущені процеси, і т.д. Але разом з тим view-сервер має більшу кількість параметрів Rational ClearCase, які можуть бути скориговані. Подання мають асоційовані з ними кеші, і для збільшення продуктивності ви можете збільшити розмір цих кешів.


Клієнт


Я був в деяких офісах замовників, у яких чудово працювали як VOB-хост, так і view-хост, але клієнтські машини при роботі відчували гостру нестачу пам'яті. Користувачі скаржилися на проблеми при складанні, оскільки компілятор, який вони використовували, витрачав всі доступні ресурси на машині клієнта. Тому якщо ваші операції взяття на редагування і здачі на контроль не викликають ніяких проблем, але при цьому процеси складання йдуть повільно, то непогано було б перевірити клієнтські машини. З VOB-хостом спостерігається інша ситуація, тому що складання, особливо збірки з використанням clearmake, навантажують VOB-сервер на більш тривалі періоди часу, ніж операції взяття на редагування і здачі на контроль. Як звичайно, перш за все перевірте операційну систему і апаратний рівень. Крім того, якщо користувач працює з динамічними уявленнями, клієнтська машина матиме кеш під управлінням MVFS (файлова система з підтримкою множинних версій), який можна збільшити для поліпшення проізводітельності.3


Про те, як перевіряти ресурси і налаштовувати IBM Rational ClearCase, буде розказано докладніше в другій частині цієї серії.


Спільно використовувані мережеві ресурси


На малюнку 2 показано хмара спільно використовуваних мережевих ресурсів, які також дуже важливі для продуктивності IBM Rational ClearCase. Подібні ресурси включають контролери домену, сервери NIS, сервери доменних імен, сервери реєстрів і сервери ліцензій. Перед тим, як вирішити будь-які операції, Rational ClearCase повинна зареєструвати користувачів. Якщо підключення до розподілених ресурсів, вимагаються для цієї реєстрації, є повільним, то відповідно і аутентифікація користувачів Rational ClearCase буде повільною. Сервер реєстру і сервер ліцензій вимагають мало ресурсів і часто виконуються на VOB-хості, тому швидкість мережевого з'єднання з цими ресурсами зазвичай не є проблемою.


При оптимізації часу виконання не забувайте про латентності


Кути трикутника на малюнку 2 також дуже важливі. Вони представляють мережеві з'єднання між VOB-хостами, view-хостами і клієнтом. У середовищі IBM Rational ClearCase, не всі метрики мережевий продуктивності створені рівними. Латентність мережі – час, потрібний від даних для прибуття до місця свого призначення – має значно більший вплив на продуктивність Rational ClearCase, ніж пропускна здатність мережі, що є кількістю даних, які можуть бути передані через мережу в заданий діапазон часу. Це обумовлено тим, що в більшості випадків Rational ClearCase не перекидає по мережі великого кількості файлів. Замість цього виробляється велика кількість віддалених викликів процедур, або RPC.


Говорячи спрощено, RPC є певним типом повідомлення, яке працює як виклик підпрограми між двома процесами, який може виконуватися на різних машинах. Коли клієнтський процес викликає підпрограму на сервері, дані RPC, включаючи аргументи для підпрограми, пересилаються через низькорівневий протокол, такий як TCP або UDP. Сервер отримує RPC, виконує відповідний код, і відсилає відповідь клієнту. Потім клієнт отримує відповідь від сервера і продовжує обробку. RPC є синхронними; це означає, що клієнт не продовжує обробку до тих пір, поки не отримає відповідь. Важливо відзначити, що тут є виклик і повернення – кожна RPC є вулицею з двостороннім рухом. Якщо для RPC необхідно 10 мс (мілісекунд) для пересилання даних від клієнта на сервер, то загальний час проходження RPC буде дорівнює 20 мс, плюс час обробки.


У типовій транзакції IBM Rational ClearCase, або MVFS або клієнт будуть посилати RPC на view-сервер. View-сервер, в свою чергу, викликає RPC на VOB-сервері. Відповідь має прибути спочатку на view-сервер, і потім друга відповідь надсилається назад клієнтові.

Рисунок 3: Виклики віддалених процедур в типовій транзакції IBM Rational ClearCase


Кожен процес має два рівні RPC, кожен з викликом і відповіддю. Якщо латентність вашої мережі становить 10 мс між кожною машиною, то ця конкретна транзакція буде вимагати 40 мс. Хоча це і не виглядає великою втратою часу, підсумовування подібних затримок швидко призводить до значного уповільнення. Операція взяття на редагування може містити більш ніж 200 RPC, наприклад, таких як реєстрація користувача в IBM Rational ClearCase, виявлення VOB, виявлення уявлення і т.д. Тому в подібному випадку, навіть з відносно невеликою латентністю в 10 мс, на виконання всієї операції Rational ClearCase витратить більше ніж секунду на очікування, поки дані пройдуть через мережу.


Латентність збільшується з появою кожної ланки – або роутера – через який повинні пройти дані від свого джерела до місця призначення. Кожен роутер повинен обробити пакет для визначення місця його призначення, і ця обробка займає час. Тому, чим менше ланок у мережі, тим краще. Пам'ятайте про те, що при налаштуванні продуктивності Rational ClearCase особливе значення має латентність, а не пропускна здатність мережі. У вас може бути мережа з гігабітної пропускною спроможністю, але якщо виклик RPC проходить через дюжину роутерів, то ви заплатите за це серйозною втратою продуктивності.


У частині II цієї статті буде більш детально обговорено, як оцінити латентність мережі і як вирішувати інші проблеми з мережею.


Приклад застосування


Для ілюстрації щойно обговорених деяких принципів аналізу продуктивності та налаштування IBM Rational ClearCase давайте розглянемо випадок з реальної практики. Я працював із замовником, який близько року використовував Rational ClearCase. Вони впровадили свій власний процес, який включав додаткове відстеження та авторизацію – вони не використовували UCM (Unified Change Management – уніфіковане управління ізмененіямі4). Всі VOB були розташовані на одному сервері Solaris, в якому були встановлені чотири процесори і 4 ГБайт оперативної пам'яті. View-сервер – який вони також використовували для виконання збірок – був на окремій, але абсолютно такий же машині. Навіть працюючи з цими потужними комп'ютерами, замовник скаржився на низьку продуктивність при виконанні операцій взяття на редагування і здачі на контроль.


Рівень 1: Операційна система / апаратна середу


Коли ми розмовляли з системними адміністраторами, вони були переконані, що VOB і view-сервери працювали просто чудово. Вони вірили, що проблема полягала саме в IBM Rational ClearCase. Тому ми почали вивчення зі стека продуктивності, рухаючись з самого низу вгору. Ми провели наш первісний аналіз з нижньої ланки, відшукуючи патологічні випадки – такі як незвичайні конфігурації або дивні процеси, що виконуються на машинах, – так само як і стандартною варіації метрик ресурсів – пам'яті, процесора, диска, і так далі. Ми виявили, що VOB-хост працював відмінно, але з view-хостом були проблеми.


З'ясувалося, що був клієнт, що виконував 192 процесу Oracle на view-хості! Ці процеси споживали 12 Гбайт віртуальної пам'яті в системі, мала лише 4 ГБайт фізичної пам'яті. Звичайно, деяка кількість пам'яті, зайнятої кожним процесом, використовувався в режимі спільного доступу, що зменшувало загальну кількість використовуваної пам'яті до рівня трохи меншого 12 Гбайт – але, тим не менш, це було значно більше, ніж мала система. В результаті наших спостережень швидко з'ясувалося, що система вичерпала всю доступну пам'ять, а рівень завантаженості процесора був дуже високий – процесор мав нульовий час очікування. Центральною проблемою була не потужність процесора, а оперативна пам'ять.


Ми рекомендували, щоб замовник видалив процеси Oracle з комп'ютера, на якому виконувався view-сервер. Після цього, ми рекомендували наростити оперативну пам'ять, якщо це все ще було необхідно, і змінити їх модель взаємодії з користувачем, щоб компіляція не виконувалася на view-хості. Так як замовник не відзначав проблем з продуктивністю до того, як встановив Rational ClearCase (разом з деякими скриптами прикладного рівня, які вони розробили), то вони не поспішали вносити будь-які зміни, тому що все ще підозрювали, що саме Rational ClearCase, а не їхня система, була причиною проблеми.


Рівень 2: Параметри Rational ClearCase


Нашим наступним кроком було переміщення вгору по стеку продуктивності, і пошук способів настройки Rational ClearCase з метою підвищення продуктивності. Ми визначили, що MVFS і view-кеші мали занадто малий розмір. Наша друга рекомендація полягала у поліпшенні розміру цих кешів, але разом з тим ми попередили замовника про небезпеку, притаманної цьому кроці. Виділення більшого розміру пам'яті під кеші може швидше привести до нестачі пам'яті, тому що ми виробляємо цю установку, ігноруючи той факт, що системі і так не вистачає пам'яті. Ми просувалися вперед, усвідомлюючи, що не враховуємо проблему з оперативною пам'яттю. Продуктивність покращилася, але незначно.


Рівень 3: Простір програми


Нашим наступним кроком було вивчення прикладного рівня. Замовник встановив скрипти, за допомогою яких здійснювалася підтримка додаткової аутентифікації та реєстрації операцій взяття на редагування і здачі на контроль. Ми поставили ці скрипти на профілювання, з метою з'ясування того, де ж саме витрачалися час, і потім періодично протягом усього дня виконували їх. Вимірювання показали, що фактичний час для операцій взяття на редагування і здачі на контроль Rational ClearCase в середньому становило 0.5 с, навіть у випадку, якщо на view-хості була повністю вичерпана оперативна пам'ять. Останнє же час обробки скриптів становило 17.4 с. Журналювання та інші функції, що виконуються на прикладному рівні, вимагали приблизно в тридцять п'ять разів більше часу, ніж функції Rational ClearCase. І це було досить сталим відношенням. В інший час дня, виконання функцій Rational ClearCase займало до 0.7 с, але для виконання скриптів вже потрібно було до 25 с. І це було саме тим, на що скаржилися співробітники замовника.


Ми почали роботу з самого низу стека продуктивності. Займаючись апаратним рівнем, ви необов'язково отримаєте хороший ефект, але цей рівень потрібно проаналізувати для виявлення патологій. Ми швидко виявили процеси Oracle, виявили, що машина також використовувалася для компіляції, і визначили, що view-хостам серйозно не вистачало пам'яті. На наступному кроці ми вивчили настроюються параметри IBM Rational ClearCase, і потім відзначили відчутне – але не така вже велика – поліпшення при їх коригуванню. Цей ефект був досягнутий при роботі c прикладним рівнем. При швидкому вивченні перших двох рівнів у нас було достатньо часу для повного аналізу прикладного простору, і ми виявили, що для поліпшень продуктивності в цій сфері існує багато можливостей.


Замовник проаналізував функціональність, яка досягалася за допомогою скриптів прикладного рівня, і вони виявив, що деякі з цих функцій вже були в IBM Rational ClearCase. Крім того, деякі із створених ними більш складних функцій відстеження були вбудовані в Unified Change Management, тому вони прийняли рішення запровадити UCM. Це призвело до скорочення кількості часу, необхідного на виконання процесів прикладного рівня, тому час, необхідний для операцій взяття на редагування і здачі на контроль значно зменшилася – і співробітники припинили скаржитися.


Що? Де? Коли?


До теперішнього часу я говорив про те, на що потрібно дивитися при аналізі та налаштування продуктивності IBM Rational ClearCase, і про те, на що саме слід дивитися. У частині II розглянемо, як поліпшити продуктивність Rational ClearCase, використовуючи інструменти та утиліти, які, можливо, у вас вже є.

Частина II


Примітки


1Продуктивність IBM Rational ClearCase, як і всякого іншого застосування, залежить від середовища, в якому вона працює, включаючи операційну систему, обладнання, та інші програми, що виконуються в тому ж середовищі. Крім того, кожна організація має свої нормативи та очікування щодо продуктивності. Через подібне широкого діапазону потенційних середовищ і очікувань, практично неможливо дати точні вказівки по досягненню прийнятного рівня продуктивності. Якщо вам потрібна допомога у визначенні того, чи є продуктивність Rational ClearCase достатньою для вашої конкретної середовища та конфігурації, то можливо, ви захочете звернутися до служби технічної підтримки IBM Rational. Крім того, за рамками цієї статті залишилося обговорення докладних процедур по налаштуванню параметрів ядра операційної системи, NFS (мережевої операційної системи), Samba і інших низькорівневих технологій.

2За прекрасною і докладної дискусією з цієї теми зверніться до роботи Configuration and Capacity Planning for Solaris Servers, Брайан Л. Вонг (Brian L. Wong), (Sun Microsystems Press, 1997).

3MVFS є функціональністю IBM Rational ClearCase, яка підтримує динамічні уявлення. Динамічні подання використовують MVFS для відображення обраних комбінацій локальних і віддалених файлів в такому вигляді, як якби вони зберігалися у власній файлової системи. MVFS також виконує аудит цільових об'єктів clearmake і підтримує кілька кешей для максимізації продуктивності.

4Unified Change Management представляє собою створену IBM Rational систему "найкращих практик" для управління змінами, починаючи від вимог і закінчуючи релізом. Інтегрована з IBM Rational ClearCase і IBM Rational ClearQuest, UCM визначає послідовний, заснований на виконанні окремих завдань процес управління змінами, який безпосередньо може застосовуватися групами для роботи над проектами розробки ПЗ.

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


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

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

Ваш отзыв

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

*

*