Почему сборка hudson «mvn clean install» занимает в 3-6 раз больше времени, чем сборка в командной строке?

Мы наблюдаем относительно долгое время сборки на нашем сервере CI (hudson), и они начинают входить в нашу путь. Я знаю, что hudson делает больше, чем просто вызывает maven, и я бы с радостью предоставил ему на 10-20% больше времени для работы, но замедление на порядок кажется слишком большим.

Кто-нибудь знает, почему это может быть и как это сделать. решать проблему? Я начну с того, что скажу, что не причина:

• виртуальная машина, на которой работает hudson: в командной строке, это занимает примерно столько же времени, что и мой компьютер разработки
• , другие параллельные задачи: я убедился, что ничто не отвлекает ресурсы от задачи сборки

Цели maven буквально чистые и устанавливаемые, ничего необычного и ресурсоемкого, как javadoc, checkstyle и т. д. Глядя на вывод консоли задачи сборки hudson, кажется, что при «Получении номера предыдущей сборки из [нашего репозитория артефактов Nexus] есть задержки», но я не знаю простого способа измерить производительность этого шага и публикация артефакта кажется слишком простой операцией, чтобы оправдать общую разницу в скорости.

(проблема также описана в этом потоке)

Обновление:

Мы обновили Hudson / Jenkins до последней версии и смогли использовать плагин времени. Краткая версия:

• хорошие новости: /nexus/proxy/attributes/test/test2/test2/1.0.0/test2-1.0.0.rpm

  Насколько я могу судить, он просто вычисляет подпись MD5 и SHA1 и записывает общая информация об артефактах, но md5sum и sha1sum для файла размером 75 МБ требуют

  Наконец, это не похоже на какой-то сетевой тайм-аут, потому что задержка примерно пропорциональна размеру артефакта .

  Приветствуется любая идея, что делает нексус после получения артефакта.

  Обновление 2 :

  При установке уровня журнала нексуса на отладку при загрузке артефакта нексус регистрирует следующее:

   ...
  
  2011-04-05 14:38:53 ОТЛАДКА [jpsc28za2RtYQ ==] -
  

  osnpslfDefau ~ - Копирование потока с размером буфера: 4096

   05.04.2011, 14:39:55 ОТЛАДКА [ython-2.5.2.jar] - org.mortbay.log 
  

  - ОТВЕТ /nexus/content/groups/public/org/python/jython/2.5.2/jython-2.5.2.jar 200

   05.04.2011, 14:40:07 DEBUG [-2.5.2.jar.sha1] - org.mortbay.log 
  

  - ЗАПРОС /nexus/content/groups/public/org/python/jython/2.5.2/jython-2.5.2.jar.sha1 на

   ...
  
  2011-04-05 14:40:12 DEBUG [-2.5.2.jar.sha1] - org.mortbay.log 
  

  - ОТВЕТ /nexus/content/groups/public/org/python/jython/2.5.2/jython-2.5.2.jar.sha1 200

   05.04.2011, 14:43:45 DEBUG [ndex.properties] - org.mortbay.log 
  

  - ЗАПРОС /nexus/content/groups/public/.index/nexus-maven-repository-index.properties на org.mortbay.jetty.HttpConnection@141a720

   ...
  
  2011-04-05 14:44:04 DEBUG [ndex.properties] -
  

  osnpmmM2Group ~ - общедоступный retrieveItem () :: НАЙДЕНО public: /. index / nexus-maven-repository-index.properties

   2011-04-05 14:44:04 ОТЛАДКА [ndex.properties] - org.mortbay.log 
  

  - ОТВЕТ /nexus/content/groups/public/.index/nexus-maven-repository-index.properties 200

   05.04.2011, 14:48:07 ОТЛАДКА [jpsc28za2RtYQ ==] -
  

  osnpaDefaultAt ~ - Сохранение атрибутов на UID = test: /test/test/1.0.1/test-1.0.1.rpm

   ...
  
  2011-04-05 14:48:07 DEBUG [w / icon-info.gif] - org.mortbay.log 
  

  - держатель сервлета = nexus

   05.04.2011, 14:48:08 ОТЛАДКА [w / icon-info.gif] - org.mortbay.log 
  

  - ОТВЕТ /nexus/ext-2.3/resources/images/default/window/icon-info.gif 200

   05.04.2011, 14:49:01 ОТЛАДКА [c = 1302007326656] - org.mortbay.log 
  

  - ЗАПРОС / nexus / service / local / log / config на org.mortbay.jetty.HttpConnection@1dbd88f ....

  Кажется, он просто сидит там около минуты, а затем продолжает свою работу. Любая идея, почему Nexus делает это, приветствуется.