Artifactory - 间歇性缓慢的响应时间

时间:2018-02-19 13:46:30

标签: artifactory

与本地Artifactory 5.8.4服务器集成时,我们遇到了gradle构建问题。 Gradle提供了这样的例外:Read timed out

要解决此问题,我们使用了以下(编辑)curl命令,有时最多需要30-60秒才能响应:

time curl -u username:password http://localhost:8081/artifactory/libs-snapshot/com/redacted/product/maven-metadata.xml

下面是artifactory服务器上request.log的输出:

20180219144146|30190|REQUEST|172.x.x.51|username|GET|/libs-snapshot/com/redacted/product/maven-metadata.xml|HTTP/1.1|200|411

30190表示请求由于某种原因需要30秒才能处理

我们可以尝试解决这个问题的任何想法?

---更新---

根据@DrorBereznitsky的要求,我已将跟踪附加到此端点(使用curl)。请注意,延迟似乎在跟踪开始之前 - 这可以通过time命令的输出看出,显示时钟持续时间为:real 0m30.316s

[root@afactory ]# time curl -u username:password http://localhost:8081/artifactory/libs-snapshot/com/redacted/product/maven-metadata.xml?trace
Request ID: c1fdcf4f
Repo Path ID: libs-snapshot:com/redacted/product/maven-metadata.xml
Method Name: GET
User: username
Time: 2018-02-23T10:14:36.281+01:00
Thread: http-nio-8081-exec-35
Steps: 
2018-02-23T10:14:36.281+01:00 Received request
2018-02-23T10:14:36.281+01:00 Request source = 127.0.0.1, Last modified = 01-01-70 00:59:59 +01:00, If modified since = -1, Thread name = http-nio-8081-exec-35
2018-02-23T10:14:36.281+01:00 Executing any BeforeDownloadRequest user plugins that may exist
2018-02-23T10:14:36.281+01:00 Retrieving info from {} repository '{}' type 
2018-02-23T10:14:36.281+01:00 Consulting the virtual repo download strategy
2018-02-23T10:14:36.281+01:00 Trying to retrieve resource info from the local storage
2018-02-23T10:14:36.281+01:00 Unable to find resource in libs-snapshot:com/redacted/product/maven-metadata.xml
2018-02-23T10:14:36.281+01:00 Intercepting cached virtual resource with 'PomInterceptor'
2018-02-23T10:14:36.281+01:00 Intercepting cached virtual resource with 'MavenMetadataInterceptor'
2018-02-23T10:14:36.281+01:00 Searching for info in aggregated repositories
2018-02-23T10:14:36.281+01:00 Preparing list of aggregated repositories to search in
2018-02-23T10:14:36.281+01:00 Appending the nested virtual repository 'libs-snapshot'
2018-02-23T10:14:36.281+01:00 Appending the nested virtual repository 'remote-repos'
2018-02-23T10:14:36.281+01:00 Appending the nested virtual repository 'remote-repos'
2018-02-23T10:14:36.281+01:00 Appending collective local repositories
2018-02-23T10:14:36.281+01:00 Appending collective local cache repositories
2018-02-23T10:14:36.281+01:00 Appending collective remote repositories
2018-02-23T10:14:36.281+01:00 Intercepting info request with 'PomInterceptor'
2018-02-23T10:14:36.281+01:00 Intercepting info request with 'MavenMetadataInterceptor'
2018-02-23T10:14:36.282+01:00 The requested resource isn't pre-resolved
2018-02-23T10:14:36.282+01:00 Target repository isn't virtual - verifying that downloading is allowed
2018-02-23T10:14:36.282+01:00 Creating a resource handle from 'libs-snapshot-local:com/redacted/product/maven-metadata.xml'
2018-02-23T10:14:36.282+01:00 Identified requested resource as a file
2018-02-23T10:14:36.282+01:00 Requested resource is an ordinary artifact - using normal content handle with length '411'
2018-02-23T10:14:36.284+01:00 Unable to find resource in ext-snapshot-local:com/redacted/product/maven-metadata.xml
2018-02-23T10:14:36.287+01:00 Info request was intercepted by 'MavenMetadataInterceptor'
2018-02-23T10:14:36.287+01:00 Received resource from an interceptor - returning
2018-02-23T10:14:36.287+01:00 Returning resource as found in the aggregated repositories
2018-02-23T10:14:36.287+01:00 Intercepting found resource with 'PomInterceptor'
2018-02-23T10:14:36.287+01:00 Intercepting found resource with 'MavenMetadataInterceptor'
2018-02-23T10:14:36.287+01:00 Requested resource is found = true
2018-02-23T10:14:36.287+01:00 Request is HEAD = false
2018-02-23T10:14:36.287+01:00 Request is for a checksum = false
2018-02-23T10:14:36.288+01:00 Target repository is not remote or doesn't store locally = true
2018-02-23T10:14:36.288+01:00 Requested resource was not modified = false
2018-02-23T10:14:36.288+01:00 Responding with found resource
2018-02-23T10:14:36.288+01:00 Executing any AltResponse user plugins that may exist
2018-02-23T10:14:36.288+01:00 Alternative response status is set to -1 and message to 'null'
2018-02-23T10:14:36.288+01:00 Found no alternative content handles
2018-02-23T10:14:36.288+01:00 Retrieving a content handle from target repo
2018-02-23T10:14:36.288+01:00 The requested resource is already resolved - using a string resource handle
2018-02-23T10:14:36.288+01:00 Executing any BeforeDownload user plugins that may exist
2018-02-23T10:14:36.288+01:00 Responding with selected content handle
2018-02-23T10:14:36.300+01:00 Request succeeded

real    0m30.316s
user    0m0.002s
sys 0m0.011s

3 个答案:

答案 0 :(得分:0)

maven-metadata.xml 是一个簿记XML文件,位于工件的根目录下,列出了给定工件的所有版本。

例如,使用此层次结构

com
  \---redacted
      \---product
            \---maven-metadata.xml
            \---2.7.5
            \---2.7.7

该文件将包含

<?xml version="1.0" encoding="UTF-8"?>
<metadata>
  <groupId>com.redacted</groupId>
  <artifactId>product</artifactId>
  <versioning>
    <latest>2.7.7</latest>
    <release>2.7.7</release>
    <versions>
      <version>2.7.5</version>
      <version>2.7.7</version>
    </versions>
    <lastUpdated>20180219142822</lastUpdated>
  </versioning>
</metadata>

当您为此工件上传新版本2.7.8时,服务器将:

  • 锁定 maven-metadata.xml
  • 插入新版本2.7.8
  • 更新 maven-metadata.xml
  • 解锁 maven-metadata.xml

所以我很确定这个文件需要时间来检索的时间是上传同一个工件的SNAPSHOT版本的时间。

这当然是设计的,Artifactory竭尽全力阻止您收到过时的文件。 我不认为你应该考虑解决这个问题......

答案 1 :(得分:0)

回答我自己的问题:

我可以通过更改以下Artifactory LDAP设置来解决/解决此问题:

[1]更改了LDAP URL,以便它包含包含我们用户的OU的完整DN:

ldaps://redacted-server-hostname:636/ou=company-staff,ou=company-users,dc=subdomain,dc=company,dc=com

[2]禁用搜索子树选项。

这似乎明显改善了性能

答案 2 :(得分:-1)

Tomcat严重依赖SecureRandom类来提供随机值。如果用于初始化SecureRandom的熵源缺少熵,则它可能在启动期间导致延迟。

有一种方法可以通过设置以下系统属性来配置JRE以使用非阻塞熵源:

-Djava.security.egd=file:/dev/./urandom

将此选项添加到当前JAVA_OPTS可能会解决您的超时问题。