Как отладить производительность неправильной настройки машины сборки? - PullRequest
Новая
       22

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

4 голосов
/ 05 октября 2011

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

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

  • Мы используем несколько сборочных машин, каждый проект получает свою собственную.
  • Каждая сборочная машина имеет аналогичную настройку, так что проекты могут начаться немедленно и не нужно много настраивать.
  • У нас есть предварительно настроенные следующие инструменты:
    • Hudson (в настоящее время 2.1.1, но будет меняться)
    • Artifactory 2.3.3.1
    • Сонар
    • У Хадсона, Артефактории и Сонара настроены свои собственные настроенные 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. Сборка станка Artifactory
  3. Центральная компания Artifactory (is isработает как зеркало и кеш для мира)
  4. Maven центральный (и другиеr репозиторий)

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

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

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

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

1 Ответ

0 голосов
/ 06 октября 2011

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

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

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

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

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

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

  1. Запрос https://<my-project-artifactory>/repo/<my-pom>. Expectation:

    • Локальный поиск не удастся, поэтому он должен найти ресурс в удаленном хранилище в центральной компании Artifactory.
    • Возможные эффекты могут быть получены от прокси, артефактного поиска.

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

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

    • Быстрый поиск.

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

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

    • Artifactory знает, где искать, поэтому он будет намного быстрее.

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

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

    • Artifactory найдет хранилище намного быстрее.

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

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

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

...