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

Question

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

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

Answer 1

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

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

Answer 2

Вы хотите изучить использование "составного набора изменений", как описано здесь:

• Страница 69 из Прагматическая автоматизация проекта
• 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

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

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

Answer 4

Во-первых, у меня нет опыта работы с StarTeam! У меня есть опыт CruiseControl и Subversion.

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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