Какова производительность Accurev?

Question

Какова производительность в текущей версии (4.7) Аккурев?

• время оформления заказа на 100 МБ, на гб?
• время для фиксации на # файлов или МБ?
• отзывчивость графического интерфейса при более чем 100 потоках?

У меня только что была демонстрация Accurev, и потоки выглядят как облегченный способ моделирования рабочего процесса вокруг кода / проектов.Я слышал, как люди хвалили Accurev за серверную часть streams и жаловались на производительность.Accurev, похоже, поработал над производительностью, но я хотел бы получить некоторые реальные данные, чтобы убедиться, что это не тот случай, когда демо-версии работают хуже.

Есть ли у кого-нибудь анекдоты о производительности Accurev или (что еще лучше) данные тестирования?

Answer 1

У меня нет никаких цифр, но я могу сказать вам, где мы заметили проблемы с производительностью.

В наших сборках обычно используются 30-40 тысяч файлов из системы управления версиями.В моей рабочей области в настоящее время имеется более 66 Тысяч файлов, включая промежуточные файлы сборки и выходные файлы, размером более 15 ГБ.Чтобы AccuRev работала оперативно, мы активно используем игнорировать элементы таким образом, AccuRev игнорирует любые промежуточные файлы, такие как *.obj.Кроме того, мы используем оптимизация временных меток.Как правило, запуск обновления происходит быстро, но размеры проекта обычно составляют 5-10 человек, поэтому обычно при ежедневном обновлении выводится всего пара десятков файлов.Даже если кто-то внес изменения, которые затронули большое количество файлов, скорость не является проблемой.С другой стороны, полное заполнение всех более чем 30 тысяч файлов происходит медленно.У меня нет времени, так как я редко это делаю, и в тех редких случаях, когда я это делаю, я запускаю заполнение, когда собираюсь на обед или встречу.Я ожидаю, что это может занять целых 10 минут.Как правило, исходные файлы загружаются очень быстро, но у нас есть несколько больших двоичных файлов, по 10-20 МБ, каждый из которых занимает пару секунд.

Если правила исключения и игнорируемые элементы настроены неправильно, AccuRev может потребоваться несколько минут для запуска обновления для рабочих областей такого размера.Когда я слышу, что другие разработчики жалуются на скорость, я знаю, что что-то не так настроено, и мы это исправляем.

Примерно год назад один из участников проекта обновил boost, добавив более 25 тысяч файлов, а также добавил FireFox в репозиторий (забудьте о размере, но boost выглядел маленьким). Они также добавили отделение интенсивной терапии, написали много программного обеспечения и изменили бесчисленное количество файлов.Насколько я помню, в потоке находилось более 250 тысяч файлов.К сожалению, я решил, что весь их хороший код следует перенести в корневой каталог, чтобы все проекты могли совместно использоваться.Это оказалось немного за пределами того, с чем AccuRev могла бы хорошо справиться.Продвижение всех изменений заняло несколько часов.Насколько я помню, как только FireFox был продвинут, все остальное прошло гладко - возможно, проблема была в одной транзакции с более чем 100 тысячами файлов?

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

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

В качестве заключительного замечания, поддержка AccuRev - это потрясающе - мы называем их голос в небе.Время от времени мы стреляем себе в ногу, используя AccuRev, и в итоге не имеем ни малейшего представления о том, как все исправить.Почти всегда мы делали что-то глупое, а потом пробовали что-то еще более глупое, чтобы это исправить.В конце концов, мы отправляем запрос в службу поддержки, и следующее, что мы узнаем, это то, что они рассказывают нам о шагах к праведности либо по телефону, либо на собрании goto.Я даже связывался с ними по пустяковым вопросам, в которых у меня просто нет времени разбираться, поскольку у меня напряженный день, и они любезно рассказали мне об этом, вместо того чтобы сообщать в RTFM.

Answer 2

Редактировать 2014:Теперь мы можем получить приемлемую производительность X-Windows, используя коммерческую версию RealVNC.

Оригинальный комментарий: Этот ответ применим к любой версии Accurev, а не только к 4.7.Во-первых, производительность графического интерфейса может быть в порядке, если вы можете использовать веб-клиент.Если вы не можете использовать веб-клиент и если вам нужна производительность графического интерфейса, то вам лучше использовать Windows или собрать всех ваших разработчиков в одном месте, т. е.где расположен сервер Accurev.Попытаться запустить графический интерфейс в X-Windows через глобальную сеть ?Забудь об этом :наш опыт составлял десятки секунд или минут для выполнения базовых операций наведения и щелчка.Это происходит в довольно хорошей глобальной сети на расстоянии около 800 миль, с почти оптимальным временем пинга.Это ошибка не Accurev, а X-Windows, и у вас, вероятно, возникнут аналогичные проблемы с другими приложениями X через глобальную сеть.Так что избегайте basic X, если это возможно.В настоящее время мы не можем, и наши пользователи глобальной сети принудительно подключены только к командной строке.Основная проблема заключается в том, что Accurev is централизован, и вы не можете увеличить скорость света.Я полагаю, что вы можете обойти задержку глобальной сети, запустив серверы репликации Accurev, но это по-прежнему не решает проблему должным образом, если у вас есть удаленные разработчики в офисах из одного человека через VPN.По иронии судьбы, серверы репликации в какой-то степени превращают эту централизованную VCS в форму DVCS.Если у вас нет серверов репликации, то ужасным, но в какой-то степени выполнимым решением является использование инструмента дельта-синхронизации, такого как rsync, для синхронизации вашего исходного дерева между вашим локальным компьютером, где вы можете запускать графический интерфейс (т.Е.Графический интерфейс, работающий непосредственно на вашем ноутбуке с Windows или Linux), и компьютер, на котором вы фактически работаете (напримерМашина UNIX на расстоянии 1000 миль).Другой вариант - использовать что-то вроде VNC, который лучше работает по глобальной сети, чем X, подключаясь к виртуальному рабочему столу в расположении сервера Accurev и используя X оттуда.На моем рабочем месте не одна команда прибегала к использованию Mercurial на стороне и переходу на Accurev только тогда, когда это было строго необходимо.Как указывает Стивен Натт выше, другая необходимая работа заключается в использовании оптимизации временных меток и игнорировании.У нас также есть администраторы Accurev (да, для этого требуется нанять людей, чтобы присматривать за ним), которые жалуются, когда нам нужно включить большое количество файлов, несмотря на то, что они составляют основную часть нашего продукта и ДОЛЖНЫ быть включены и контролироваться версиями.Делайте свои собственные выводы.