Производительность сервера управления версиями при использовании CruiseControl (StarTeam или альтернативы)

Question

Мы используем CruiseControl с сервером StarTeam и имеем проблемы с сбоем сервера StarTeam. Нам интересно, слишком ли ударились о сервер. Через 3 машины CruiseControl и в общей сложности около 30 проектов мы регистрируемся в StarTeam и каждый раз проверяем изменения. В большинстве наших проектов есть ~ 20 000 файлов. Кто-нибудь имеет опыт работы с ограничениями производительности в этом типе сценария с помощью StarTeam?

Я также заинтересован в показателях производительности для CruiseControl с другими системами управления версиями, такими как TFS, Perforce, SVN и т. Д. Имеют ли они проблемы с масштабируемостью при использовании CruiseControl и большого количества проектов с большим количеством проектов файлы?

Answer 1

У меня есть опыт использования Star Team для непрерывной интеграции - хотя с помощью TeamCity, а не с CruiseControl. В нашем случае регулярные соединения TeamCity с StarTeam едва регистрируются в качестве индикатора нашего мониторинга производительности.

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

Answer 2

Вы хотите посмотреть в использовании "набор модификации соединения", как описано здесь:

• Страница 69 из Pragmatic Project Automation
• http://www.nabble.com/How-I-can-use-compound-modification-set-with-triggers--td19397718.html
• http://cruisecontrol.sourceforge.net/main/configxml.html#compound

ли StarTeam поддержка "Триггеры" ? Вместо того, чтобы ваши машины CruiseControl проверяли репозиторий каждую минуту для изменения, у вас будет машина StarTeam, позволяющая CruiseControl знать, когда код был изменен, прикоснувшись к файлу.

В основном, когда в проект выполняется обновление, ваш VCS касается файла, который контролирует CruiseControl (например, project-a-update.txt). Как только он замечает, что файл имеет изменения, CruiseControl знает, что нужно делать обновление с вашего VCS. Таким образом, он обрабатывает один текстовый файл для каждого проекта каждые N минут, а не весь репозиторий.

Answer 3

Насколько я могу судить, StarTeam не поддерживает триггеры. Задача CruiseControl.NET StarTeam поддерживает только опрос, и я не видел никаких доказательств в любом месте, где StarTeam поддерживает триггеры изначально.

Я испытываю тот же самый вопрос, хотя и нажимаю StarTeam на его предел. Я не уверен, но я начинаю думать, что проблема с сбоями связана с одновременным доступом, поскольку проблемы происходят гораздо чаще, когда проект очень активен разработчиками, а также CruiseControl.

Штраф за опрос за изменения также становится весьма значительным. Хуже всего то, что наказание удваивается. Первый вызов StarTeam - это вызов «hist», чтобы получить набор изменений для создания отчетов и запуска сборки, затем вызов «co» выполняет вторую проверку всего исходного дерева и проверяет любые устаревшие или отсутствующие файлы. Если кто-нибудь может предложить способ создания триггера вокруг проекта StarTeam, который бы устранить это, я бы с удовольствием попросил его.

Answer 4

Дополнительная информация, которую я смог найти.

StarTeam не всегда отключает пользователя (или агент в случае доступа CruiseControl) и может иметь десятки открытых подключений/логинов для одного и того же пользователя/агента.К сожалению, очень сложно подтвердить, является ли это связанной проблемой, потому что я не могу надежно перегрузить сервер.

Мы используем старую версию StarTeam, которая не имеет MPX. Интересно, есть ли у кого-нибудь опыт использования StarTeam в другой среде непрерывной интеграции, поддерживающей метод MPX.

Answer 5

Во-первых, у меня нет опыта StarTeam! Однако у меня есть опыт CruiseControl и подрывной деятельности.

Вы можете изменить интервал между расписанием на менее агрессивный, чем 1 минута - обычно 3-5 минут обычно проверяют проекты, чтобы посмотреть, нужно ли им строить. Но я согласен, что может быть причина, по которой вам нужно проверять очень часто.

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

Надеюсь, это вам поможет.

Answer 6

Наше самое большое улучшение производительности при запуске CC в нескольких активных проектах состояло в том, чтобы установить агент кеширования MPX на том же компьютере и убедиться, что он хранит атрибуты и содержимое файлов. (Ну, это и убедитесь, что вы используете ccache в сборках.)

Идея триггеров существует в SDK StarTeam, но я не уверен, насколько она интегрирована с CC. Чтобы проверить, требуется ли сборка, мы сохраняем последний вывод с сервера в чистом каталоге и используем список stcmd для сравнения изменений. Это очень быстро.