Как отладить производительность неправильной настройки сборочной машины?

Нам приходится регулярно настраивать новые среды сборки, и этот процесс кажется не таким уж простым. Сегодня у меня новая сборочная машина, и первая сборка Maven была настолько медленной, что я хотел уточнить, почему производительность была такой плохой. Но как это сделать?

Наш контекст:

  • Мы используем несколько машин сборки, у каждого проекта своя.
  • Каждая машина сборки имеет аналогичную настройку, поэтому проекты можно запускать сразу и не нужно много настраивать.
  • We have the following tools preconfigured:
    • Hudson (currently 2.1.1, but will change)
    • Артифабрика 2.3.3.1
    • Сонар
    • У Hudson, Artifactory и Sonar настроен собственный Tomcat.
    • Maven 2.2.1 и Maven 3.0.3 (без пользовательской конфигурации, только установка имеет settings.xml)
    • Ant 1.7.1 и Ant 1.8.2 (здесь не актуально)
    • Клиент Subversion 1.6

Все инструменты должны работать вместе, особенно цепочка репозиториев должна быть:

  1. Построить репозиторий Maven на машине
  2. Построить машину
  3. Центральная компания Artifactory (работает зеркалом и тайником для мира)
  4. Центральный Maven (и другой репозиторий)

Поэтому, когда для сборки Maven требуется разрешить зависимость, она сначала будет искаться в локальном репозитории Maven, оттуда в локальном репозитории Artifactory, затем в центральном репозитории Artifactory и только потом в Интернете.

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

Первая сборка (Maven Hello World) была построена примерно за 45 минут. В то время происходила вся загрузка, но я думал, что используя нашу цепочку репозиториев (где центральный репозиторий хорошо заполнен), сборка будет намного быстрее. Так что я думаю, что в центре внимания отладки будет сеть, локальная сборка не проблема. Так что конфигурация и взаимодействие Maven и Artifactory находятся на рассмотрении.

Как вы отлаживаете такую ​​среду? У меня есть доступ к сборочной машине (как sudo) и к центральному репозиторию, но я не знаю, как начать, что доказывать, где искать. Итак, каков ваш опыт, какими советами и рекомендациями вы хотели бы поделиться?


build maven performance artifactory hudson
person mliebelt    schedule 05.10.2011    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Вот несколько вещей, которые я сделал до сих пор. Если у вас есть дополнительные советы, добро пожаловать!

Я подозревал, что источником зла является цепочка репозиториев, поэтому сначала обратился к ней. Причины:

  • Реальная сборка на локальной машине (программы hello world) может отличаться на миллисекунды, но не на минуты.
  • Сеть имеет значение, поэтому атакуйте ее в первую очередь.

Интересна цепочка репозиториев, если что-то не найдено локально. Вот шаги, чтобы убедиться, что это так:

  • Для Maven удалите содержимое локального кеша. Если локальный кеш заполнен, вы не знаете, найден ли ресурс в локальном кеше или где-либо еще. (Сделайте это хотя бы в конце, если все остальное снова работает.)
  • Для Artifactory также найдите этот кеш и очистите его, удалив его содержимое. Это всего лишь кеш, поэтому он будет заполнен по-новому.
  • Если вы используете умный браузер для измерения поиска, убедитесь, что то, что вы просили, не находится в кеше браузера.
  • В противном случае используйте такой инструмент, как wget, чтобы запросить ресурс.
  • Постарайтесь свести к минимуму источники неудач. Поэтому постарайтесь разделить длинное расстояние вашего поиска на более мелкие сегменты, которые вы контролируете.
  • Не используйте Maven для поиска, начните сначала с репозитория Artifactory (только), а затем с Maven.

Это привело к следующим тестам, которые я хотел сделать. Каждый раз я проверял выполнение предыдущих предпосылок:

  1. Спросите https://<my-project-artifactory>/repo/<my-pom>. Ожидание:

    • Local lookup will fail, so has to find the resource in a remote repository in the central company Artifactory.
    • Возможные эффекты могут исходить от прокси, артефактного поиска.

    Результат: Поиск простого POM занял ~ 30 секунд. Это слишком.

  2. Удалите прокси. С wget есть опция --no-proxy, которая делает именно это. Ожидание:

    • Faster lookup.

    Результат: Никаких изменений, значит, причина не в прокси.

  3. Спросите https://<my-project-artifactory>/libs-snapshots-company/<my-pom>. Поэтому измените виртуальный репозиторий на реальный удаленный репозиторий. Ожидание:

    • Artifactory knows where to do the lookup, so it will be much faster.

    Результат: POM был найден сразу, поэтому Artifactory выполняет поиск в течение 30 секунд. Но что может быть тому причиной?

  4. Удалены в Artifactory все удаленные и виртуальные репозитории (остались только репозитории наших компаний и кешированный центр Maven). Но используйте снова https://<my-project-artifactory>/repo/<my-pom>. Ожидание:

    • Artifactory will find the repository much faster.

    Результат: POM пришел мгновенно, не поддающийся измерению.

  5. Тогда я набрался смелости и просто начал сборку (локально с пустым кешем). На сборку тогда понадобилось 5 секунд (вместо 15 минут тем же утром).

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

person mliebelt    schedule 06.10.2011
comment
Время, необходимое Artifactory для разрешения элементов при обращении к виртуальному репозиторию, зависит от запрошенного артефакта и от реальных репозиториев, которые объединяет упомянутый виртуальный репозиторий. - person noamt; 06.10.2011
comment
Например, когда запрашиваются метаданные maven, Artifactory должен выполнить итерацию по всем вложенным реальным репозиториям и объединить все соответствующие метаданные, которые он находит, что может занять некоторое время. Добавьте к этому миксу несколько удаленных репозиториев, разрешение из них требует времени; возможно, в вашей цепочке удаленных репозиториев есть несколько медленных? - person noamt; 06.10.2011
comment
Как уже упоминалось, удаленные репозитории могут задерживать время разрешения. Несколько вещей, которые вы можете сделать, чтобы решить эту проблему, это агрегировать только те удаленные репозитории, которые вам действительно нужны; вы также можете управлять порядком разрешения между агрегированными репозиториями, поэтому вы можете поместить репозитории, которые, как вы знаете, являются самыми быстрыми, раньше в цепочке. - person noamt; 06.10.2011
comment
Большое спасибо, я проведу еще несколько экспериментов, чтобы уточнить, что нужно и что мы можем предоставить централизованно. Я добавлю, что может ответить. - person mliebelt; 06.10.2011