© Том Милли (Tom Millie), Джек Уилбер (Jack Wilber), IBM Rational
Вы можете также рассмотреть использование экспресс-сборок для повышения производительности сборки. Если вы незнакомы с концепцией экспресс-сборок, то ниже будет приведено краткое описание.
Во время обычной контролируемой сборки IBM Rational ClearCase, тот факт, что был создан производный объект (например, foo.o), наряду с другой информацией, такой как версия исходных файлов и команды, использованные для генерации производного объекта, – все это регистрируется в VOB. Все это делается для обеспечения работы принятого в IBM Rational ClearCase механизма исключения сборок (или совместного использования двоичных файлов). Рассмотрим проект, над которым совместно работают несколько разработчиков, и некоторые разработчики снова и снова собирают один и тот же программный продукт. Когда один разработчик собирает foo.o с использованием ciearmake в динамическом представлении, ciearmake "идет в магазин" – то есть, запрашивает VOB, не собрал ли кто-нибудь foo.o с использованием той же самой версии foo.c и всех других исходных файлов, и используя тот же самый набор параметров сборки. Если кто-нибудь это уже сделал, тогда нет необходимости в повторной сборке foo.o, поэтому ciearmake просто начинает использовать оригинальный foo.o, который перемещается в специальный пул внутри VOB, называемый пулом производных объектов. Когда какие-либо сборки используют одни и те же параметры, то они будут использовать foo.o из пула производных объектов. Эта операция известна как "winkin", и как правило происходит быстрее, чем непосредственная компиляция foo.c.
С точки зрения производительности это означает то, что всякий раз, когда я использую ciearmake или omake для сборки версии проекта в динамическом представлении, эти утилиты говорят VOB, что именно я собираю. Это генерирует значительное число удаленных вызовов процедур и транзакций записи в VOB, которые снижают производительность.
Тем не менее, во время экспресс-сборки эти утилиты не говорят VOB о том, что нечто было собрано. Я все еще могу получить доступ к VOB, пулу производных объектов и совместно использовать существующие объекты, но я не могу сказать VOB что именно я делаю — поэтому я не смогу предоставить результаты своей сборки для общего использования.
Это выглядит довольно эгоистично, но при этом может ускорить процесс сборки двумя способами. Во-первых, во время экспресс-сборки производные объекты "регистрируются" в VOB. Это означает, что база данных VOB не блокируется при доступе на запись; поэтому другие пользователи могут получить более быстрый доступ к VOB во время проведения сборок, и на имеющемся оборудовании хост VOB сможет работать с большим количеством пользователей. Во-вторых, мой процесс сборки выполняется быстрее, так как устраняются требующие много времени транзакции записи в VOB. Я обнаружил, что в зависимости от проекта индивидуальные экспресс-сборки могут выполняться быстрее вплоть до 20 процентов.
На рисунке 11 вы можете увидеть, что время отклика увеличивается при увеличении количества фоновых пользователей, выполняющих сборки в стандартном режиме. Для экспресс-сборок, эта кривая становится значительно более пологой. Таким образом, используя то же самое аппаратное обеспечение, вы можете поддерживать значительно большее число пользователей, так как экспресс-сборки снижают объем входящего трафика в VOB, а вместе с тем и объем работы, которую VOB-сервер должен будет выполнить.
Рис. 11. Экспресс-сборки ухудшают время отклика системы при увеличении количества пользователей
Адаптация экспресс-сборок в качестве практики коллективной работы обычно требует изменений в способах взаимодействия разработчиков друг с другом. Если я использую экспресс-сборки, то тогда я должен явно сделать общими результаты своей сборки или же функция исключения сборки не будет работать для остальных разработчиков. Я могу это сделать вручную с использованием команды winkin. Кроме того, я могу использовать команду cieartooi is -long для определения того, является ли объект совместно используемым, или нет. Например,
указывает, что объект foo не является совместно используемым для остальных сотрудников группы разработки. Важно помнить, что совместно используемый производный объект не может иметь закрытых для совместного использования частей. Если я собираю целое приложение, то я, например, не могу разрешить совместное использование только самого приложения; я должен разрешить использовать все объекты, которые в него входят.
Обычно, когда группа разработки принимает эту модель, то в качестве общего значения по умолчанию будет установлено создание представлений, использующих экспресс-сборки. При этом будет также установлено одно стандартное представление (normal view), которое не является представлением экспресс-сборки. Вместо предоставления всем сотрудникам группы разработки возможности явного совместного использования производных объектов, они используют это стандартное представление для выполнения еженощных сборок — и даже ежечасных сборок, если в этом имеется необходимость. Целью является заполнение VOB производными объектами, с помощью которых любой разработчик может провести экспресс-сборку (winkin). Таким образом, разработчик все еще может использовать преимущества совместного использования двоичных файлов, но без замедления, связанного с записью в VOB каждый раз при проведении сборки.
Для создания нового представления, использующего экспресс-представления, можно просто использовать опцию -nsnareabie_dos в cieartooi. Например, вы можете использовать следующую команду: cieartooi mkview -nshareable_dos <остальная командная строка>. Для преобразования существующего представления в представление с экспресс-сборками, используйте ту же опцию с cnview. Например, используйте следующий формат команды: cieartooi cnview - nshareable_dos <остальная командная строка>. После этого, просто используйте clearmake ИЛИ omake для обычной сборки.
В проектах, использующих Unified Change Management (унифицированное управление изменениями), или UCM5, представления с экспресс-сборкой создаются по умолчанию. В не-UCM проектах они не создаются. Тем не менее, вы можете использовать команду cieartooi setsite для установки во всей локальной сети значения по умолчанию для создания представлений, использующих экспресс-сборки. Для дополнительной информации по экспресс-сборкам, см. Building Software with Rational ClearCase6 (Сборка программного обеспечения с помощью Rational ClearCase).
Не зависимо от того, решите вы использовать экспресс-сборки или нет, но если вы захотите использовать такие преимущества IBM Rational ClearCase, как исключение сборки и возможности совместного использования двоичных файлов, то администраторы Rational ClearCase могут увеличить производительность сборки путем удаления устаревших представлений, когда они уже более не нужны. Процесс "приобретения" соответствующих производных объектов для экспресс-сборки ("winkin") может негативно влиять на производительность, когда Rational ClearCase будет вынуждена для поиска возможного соответствия проверять несколько конфигурационных записей7. Поэтому группам, практикующим экспресс-сборку, следует вычищать VOB от устаревших производных объектов. Под этим, в свою очередь, подразумевается удаление более не используемых представлений. Утилита scrubber, чья работа заключается в удалении производных объектов, не будет удалять производный объект до тех пор, пока одиночное представление сохраняет на него ссылку. Со временем количество ссылок уменьшается до тех пор, пока не остаются только представления, их создавшие, и поэтому содержащие на них ссылку, что достаточно для удержания в VOB производного объекта. Удаляя неиспользуемые представления, администратор позволяет утилите scrubber удалять из пула старые производные объекты, что ускоряет процесс "приобретения" для сборок с динамическими представлениями.
Прикладной уровень является самым верхним уровнем стека производительности. Он состоит из скриптов и триггеров процессов, выполняющих операции, относящиеся к функциям IBM Rational ClearCase. Он также содержит вызовы ciearmake — для сборки приложений — и make-файлы, содержащие зависимости для ciearmake. Как я уже говорил в Части I этой серии, с прикладным уровнем иногда труднее работать, так как зачастую он более сложен, и, кроме того, владельцы или создатели скриптов, триггеров или make-файлов защищают его от возможных изменений. Тем не менее, потенциал роста производительности в этой области достаточно велик.
Многие организации для выполнения специальной обработки используют скрипты, написанные на интерпретируемых языках, таких как Perl или язык командного процессора. Например, вместо использования простого взятия на редактирование cieartooi, они будут создавать скрипт, который сначала регистрирует операцию взятия на редактирование, а затем генерирует одну или несколько команд cieartooi. Другие организации создают скрипты, сходные с создаваемыми наследуемыми системами управления версиями. В любом случае, эти скрипты генерируют несколько выполняемых друг за другом команд cieartooi.
Триггеры, которые конфигурируются для автоматического запуска при выполнении определенной операции IBM Rational ClearCase, могут также вызвать cieartooi из интерпретируемого языка. В отличие от скриптов, триггеры часто являются невидимыми для пользователей, которые могут не знать, что какая-либо дополнительная обработка выполняется как часть их операций, например, взятия на редактирование.
Если вы используете Perl для написания скриптов или триггеров, то существуют несколько шагов, которые вы можете выполнить для улучшения производительности. Фактически, даже если вы не используете Perl, то вы возможно захотите переписать ваши скрипты прикладного уровня на Perl, для того, чтобы воспользоваться преимуществами некоторых из этих техник.
Как я уже писал в своей более ранней статье в Rational Edge , "Using Perl with Rational ClearCase Automation Library (CAL)," (Использование Perl c библиотекой автоматизации Rational ClearCase), когда программа вызывает cieartooi, то операционная система должна создать новый процесс, причем запуск нового процесса обходится достаточно дорого — сначала для него нужно выделить память, затем создать новую запись в таблице процессов и т.д. Эти операции могут занимать значительное количество времени, и если скрипт вызывает cieartooi несколько раз, то задержки накапливаются и могут становится весьма ощутимыми. Вы можете избежать задержек, связанных с выполнением нескольких команд cieartooi, воспользовавшись пакетом Perl ClearCase8 или библиотекой автоматизации ClearCase, которая предоставляет возможность обращения непосредственно к IBM Rational ClearCase. В моей предыдущей статье по CAL, я описал простой эксперимент, который я провел с целью выявления основных характеристик производительности. Я замерил время работы задачи, выполненной с помощью cieartooi, и затем замерил время работы той же задачи, но выполненной с помощью CAL. При выполнении этой определенной операции реализация на CAL была примерно на 30 процентов быстрее.
Другой техникой, которая может улучшить производительность, является предварительная компиляция ваших Perl-скриптов в самостоятельные приложения, что может быть сделано, например, с использованием PerlApp из Perl Development Kit9 от ActiveState. В первой части этой серии статей было дано исследование прецедента для организации, реализовавшей иной подход. При повторной оценке функциональности, реализованной с использованием скриптов и триггеров, обнаружилось, что Unified Change Management с успехом может справляться с большинством этих задач. Поэтому было принято решение по внедрению UCM. В качестве вторичного эффекта от подобного изменения, большинство выполняемых операций прикладного уровня было преобразовано во встроенные операции Rational ClearCase, которые выполняются значительно быстрее.
До того, как стало доступным использованием UCM, в ряде организаций были созданы программы-упаковщики (wrappers) для выполнения операций взятия на редактирование и снятия с редактирования, что было необходимо для реализации наборов изменений, связанных с определенными действиями разработчиков. Работа подобных скриптов заключается в том, что при запуске у пользователя запрашивается, какого рода операции он хочет провести, а затем производится регистрация этих операций с использованием базы данных или каким-либо другим способом. Теперь же все эти операции являются встроенными операциями UCM Rational ClearCase. Используя при выполнении этих задач UCM, а не написанные самими разработчиками скрипты, вы сможете достичь значительного увеличения производительности.
Во многих организациях, с которыми мне довелось работать, я часто обнаруживал make-файлы, структура которых была загадочна и чрезвычайно запутана.
Организации, которые использовали make или ciearmake для работы с большими проектами, опасались изменять что-либо в своих make-файлах из страха, что внесенные изменения сделают невозможным процесс дальнейшей сборки. Результатом был неконтролируемый рост размера этих файлов. Я люблю сравнивать подобный эффект с тем, что наблюдается в доме привидений в Винчестере, что близ Сан-Франциско в Калифорнии, где имеются лестницы и коридоры, ведущие в никуда, и двери, за которыми стены или которые открываются в пустоту10.
Подобно этому дому, многие make-файлы создавались годами без наличия какой-либо определенной руководящей схемы. Поэтому люди опасаются добавлять к ним что-либо, за исключением абсолютно необходимого для сборок новой версии. Обычно эти make-файлы не оптимизированы и никто не знает, как именно они работают. Тем не менее, разработчики при сборке своих систем все еще полагаются на эти файлы.
Я всегда настоятельно рекомендую своим клиентам периодически проверять и переписывать make-файлы проектов во избежание проявления «синдрома дома привидений в Винчестере». Кроме того, всегда весьма полезно заручиться поддержкой сотрудника, который хорошо знаком с процессом сборки программного обеспечения. Если вы точно не знаете, что именно делает ваш make-файл, но при этом вам нужно собрать программный проект, тогда можно использовать конфигурационную запись IBM Rational ClearCase для создания базиса для нового make-файла. Просто собирайте ваше ПО с помощью контролируемой сборки, используя ciearmake. Когда сборка будет завершена, запустите команду run cleartool cater -makefile myapplication. При этом конфигурационная запись будет выведена в формате make-файла. Этот make-файл может не быть оптимизированным, но его структура будет более прозрачной, что облегчит последующее проведение оптимизации.
Безусловно, использование экспресс-сборок может также ускорить процесс сборки. Кроме того, вы можете рассмотреть возможность выполнения параллельных распределенных сборок в среде UNIX или параллельных сборок в многопроцессорной среде Windows. За более подробной информацией по параллельной сборке обратитесь к руководству по IBM Rational ClearCase, разделу Building Software with Rational ClearCase (Сборка программного обеспечения с помощью Rational ClearCase).
Последнее замечание по эффективности сборки при работе с кэшами MVFS: будьте осторожны при использовании многих директив -i для указания путей поиска файлов компилятором. Директива компилятора -i <d±r> используется для указания каталога <dir> в качестве одного из каталогов, в котором следует искать файлы заголовков, используемые при компиляции. Для каждого включенного в исходный файл заголовка, компилятор будет производить поиск в каждом каталоге, и если не будет обнаружено соответствие, продолжать поиск в следующем каталоге. MVFS кэширует файловую информацию в кэшах dirent и enoent, а в последнем кэшируются имена путей, по которым каждый искомый файл не был найден. Эти кэши обеспечивают более быстрое выполнение просмотра, как для поиска корректных, так и отбрасывания неправильных имен путей. Если вы используете много директив -i для многих каталогов, и в каждом из этих каталогов имеется много различных файлов, из которых лишь некоторые фактически нужны для компиляции, то эффектом будет заполнение кэша enoent каждым элементом каталога, который не соответствует каждому не найденному файлу. При значительном количестве файловых записей кэш enoent становится заполненным, а поиск в нем – менее эффективным. Если вы считаете, что это может отрицательно влиять на производительность процесса сборки, то подумайте о том, чтобы сгруппировать все заголовки и другие включаемые файлы в одном каталоге, и указать этот единственный каталог в директиве -i.
Общие сетевые ресурсы — такие, как контроллеры доменов, серверы доменных имен, и так далее — также отрицательно влияют на производительность IBM Rational ClearCase. На платформах Windows, проведение анализа в этой области не так сложно; все, что нужно сделать - это предоставить возможность IBM Rational ClearCase Doctor выполнить свою работу.
На рисунке 12 приведены результаты стандартного статического анализа, выполняемого при запуске Rational ClearCase Doctor. Эта утилита тестирует разрешение имени хоста и сообщает о том, сколько времени заняло ожидание ответа от контроллера домена, запрос лицензии и ожидание ответа от сервера регистрации.
Рис. 12. Rational ClearCase Doctor показывает время отклика от общих сетевых ресурсов
Большинство заказчиков, с которыми я говорил, знают об этих отчетах, но лишь некоторые знают о том, что IBM Rational ClearCase Doctor также может выполнять и динамический анализ. Из меню Analysis , вы можете выбрать Server Accessibility Analysis... ("анализ доступности сервера...") для получения доступа к различным возможностям динамического анализа, как показано на рис. 13a.
Рис. 13a. IBM Rational ClearCase Doctor предоставляет возможности анализа доступности сервера
На рисунке 13a, я выбрал селективную кнопку для проверки определенного пути, связанного с представлением и с VOB. После того, как я щелкну по "Start Analysis" ("запуск анализа"), я увижу результаты, приведенные на рисунке 13b.
Рис.13b. Результаты анализа доступности сервера
Результаты показывают время отклика для доступа к указанному мной файлу в данном представлении и VOB. В этом случае отклик является очень быстрым, так как все объекты, к которым происходят обращения, находятся на моем компьютере. Тем не менее, если я отмечаю, что взятие/снятие с редактирования определенного файла требует слишком много времени, я могу использовать этот динамический анализ в Rational ClearCase Doctor для получения более полной картины происходящего.
Существует несколько других путей для предотвращения замедлений работы IBM Rational ClearCase.
В качестве общей рекомендации, не храните тысячи файлов в корневом каталоге VOB, который не кэшируется вместе с остальными каталогами; вместо этого, разместите файлы в подкаталогах. Фактически я следую этому правилу для каждой используемой мной операционной системы.
Кроме того, если вы используете версию UCM от 2002 г. или более раннюю, старайтесь снизить количество модифицируемых компонентов вашего проекта до десяти или меньше и старайтесь избегать продолжительных потоков работ с большим количеством базовых версий. В противном случае подобные операции могут отрицательно влиять на производительность. Улучшения в UCM для IBM Rational ClearCase версии 2003 сняли эти ограничения.
Анализ и улучшение производительности IBM Rational ClearCase может быть достаточно сложной задачей. Но как и при работе над любой сложной проблемой, она становится более простой, если ее решение разбить на ряд последовательных операций. Согласно моему опыту, работа со стеком производительности предоставляет прекрасную основу для разбиения задачи на составляющие. По мере того, как я перемещаюсь по стеку производительности — от аппаратного уровня / уровня ОС к параметрам IBM Rational ClearCase и далее к прикладному уровню, я постоянно помню о том, что даже небольшое увеличение производительности в долгосрочной перспективе может оказать значительное влияние на продуктивность и эффективность работы организации. Поэтому, затратив немного времени на улучшение производительности, можно достичь значительной экономии времени при работе над проектом.
Curt Aubley, Tuning & Sizing NT Server. Prentice Hall, 1998.
Curt Aubley, Tuning and Sizing Windows 2000 for Maximum Performance. Prentice
Hall, 2000.
Adrian Cockroft and Richard Pettit, Sun Performance and Tuning: Java and the
Internet.
Prentice Hall, 1998.
Gian-Paolo D. Musumeci and Mike Loukides, System Performance Tuning, 2nd Edition.
O'Reilly & Associates, 2002.
Richard Pettit, SE Toolkit, http://www.setoolkit.com.
Joseph D. Sloan, Network Troubleshooting Tools. O'Reilly & Associates,
2001.
Hal Stern, Mike Eisler, and Ricardo Labiaga, Managing NFS and NIS, 2nd Edition.
O'Reilly & Associates, 2001.
Ed Wilson and James Naramore, Network Monitoring and Analysis. Prentice Hall,
2000.
Brian L. Wong, Configuration and Capacity Planning for Solaris Servers. Prentice
Hall, 1997.
"
HP-UX Memory Management." Hewlett Packard Company White Paper, 2000. http://docs.hp.com/hpux/onlinedocs/os/lli/mem
mqt.html.
5 Unified Change Management представляет собой созданную IBM Rational систему "наилучших практик" для управления изменениями, начиная от требований и заканчивая релизом. Интегрируемая с IBM Rational ClearCase и IBM Rational ClearQuest, UCM определяет последовательный, основанный на выполнении отдельных задач процесс управления изменениями, который непосредственно может применяться группами для работы над проектами разработки ПО.
6 Это руководство поставляется вместе с продуктом IBM Rational ClearCase.
7 IBM Rational ClearCase использует технологию кэширования для быстрого удаления наиболее производных объектов (most derived objects), но в крупных проектах разработки ПО могут находиться несколько потенциальных кандидатов, которые должны быть более тщательно проанализированы.
8 Пакет Perl ClearCase доступен от CPAN по адресу http://www.cpan.org. Пакет ciearcase::ctcmd, поставляемый IBM Rational, является компилируемым интерфейсом к таблице процессов подкоманд cleartool. При этом устраняется расходование ресурсов на запуск каждой сессии cleartool, что делается за счет непосредственной привязки к библиотекам IBM Rational ClearCase и использованию компилированных точек обращения к совместно используемым объектам Rational ClearCase. Это может существенно увеличить производительность Perl-скриптов для Rational ClearCase.
9 См. мою статью в Rational Edge: "Using Perl with Rational ClearCase Automation Library (CAL)" (Использование Perl c библиотекой автоматизации Rational ClearCase), где приведена дополнительная информация и некоторые ньюансы использования CAL.
10 Сара Винчестер (Sarah Winchester), наследница состояния Винчестерской ружейной компании, непрерывно работала над этим домом в течение 38 лет. См. http://www.winchestermvsteryhouse.com/
Дополнительная информация
За дополнительной информацией обращайтесь в компанию Interface Ltd.
| INTERFACE Ltd. |
| ||||
