Как работает Accurev Performance?

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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