Улучшения производительности Subversion

Question

У нас есть хранилище SVN 3.5 Гб, недавно перенесенное из хранилища 6 Гб. Мы храним все наше собственное программное обеспечение и множество мелких общих компонентов. Мы также делаем много тегов. Проекты хранят копии своих бинарных зависимостей, в основном библиотеки. Мы не можем перейти в GIT прямо сейчас.

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

Доступ осуществляется через mod_dav_svn с пользовательской аутентификацией. Авторизация будет реализована с помощью перехватов после фиксации, поскольку мы выполняем некоторые проекты на год и требуем подробных правил безопасности.

Мы хотим оптимизировать доступ так:

• Сделал 'svn pack'.
• Реализовано кэширование аутентификации.
• Готовы оценить svnserve.

Структура нашего хранилища следующая:

\root
 \proyect1
  \trunk
   <files>
  \docs
  \branches
  \tags
   \proyect1-1.2.3-beta
    <files>
   \proyect1-1.3.0
     <files>
   etc...
 .
 .
 .
 \proyectn

Существуют ли другие оптимизации, не связанные с оборудованием, которые раньше приносили успех? Может ли расположение наших файлов иметь какое-либо значение?

Answer 1

Я буду комментировать только те части, которые испытал.

1) Во-первых, он большой! Обычно лучше хранить бинарные файлы и библиотеки вне репозитория, даже иногда удобнее иметь все вместе. У нас были такие проекты (где я работаю) с файлами, которых не было в репозитории, и которые занимали много места. Он убивал сервер при каждой проверке или для важных коммитов, другие проекты были просто хороши.

Разделение проектов также является хорошей идеей в целом: с svn:externals у вас достаточно гибкости, чтобы связывать их при необходимости, и вы избегаете единой точки отказа, гигантских размеров репозитория, проще создавать резервные копии и и так далее.

Но вы не всегда можете выбрать эти параметры.

2) Это сервер Linux Apache или он работает в Windows? Я видел разницу между этими двумя версиями: версия для Windows, как правило, медленнее и очень чувствительна к конфигурации.

3) Я бы сделал тест с svnserve вместо Apache mod_dav_svn. Нагрузка на сеть меньше, что также может стать препятствием, когда многие люди используют один и тот же сервер (в зависимости также от конфигурации сети).

4) Используете ли вы 1,5 или даже лучше, 1,6? Файловая система была улучшена, и если вы перешли с предыдущей версии, выполнение dump / load окупается, как правило ( проверьте эту ссылку также ). Мы провели несколько тестов с большими репозиториями и получили несколько процентов, но в том, что мы наблюдали, была большая разница.

5) Кроме того, вы можете рассмотреть это (из Контроль версий с Subversion ) - хотя я никогда не пробовал эту конкретную возможность:

Начиная с Subversion 1.6, файловые системы FSFS имеют несколько настраиваемых параметров, которые администратор может использовать для точной настройки производительности или использования диска в своих хранилищах. Вы можете найти эти опции - и документацию для них - в файле db / fsfs.conf в хранилище.

6) Сценарии ловушек могут оказать влияние, если они плохо реализованы, добавляя дополнительную задержку к взаимодействию с сервером.

7) TortoiseSVN использует кеширование журналов, иногда это раздражает (имеет тенденцию блокировать файлы, которые вы затем не можете удалить - может быть удивительно, если вы не знаете об этом), но дает пользователям более быстрые ответы при просмотре журналов (помимо того, что он хорошо интегрирован в Windows).

Answer 2

Краткий ответ: Попробуйте svnserve ! В некоторых тестах, которые я делал некоторое время назад, он был в несколько раз быстрее , чем mod_dav_svn для большинства операций.

Впоследствии мы перешли на svnserve и не оглядывались назад, но вы также можете работать на обоих серверах параллельно, если вам нужно, и правильно настроить его.

Длинные истории и результаты измерений можно найти по адресу http://www.ohrner.net/software/tipps_en.php / http://www.ohrner.net/software/tipps_de.php.