ARTIFACTORY:如何对request.log进行性能分析

帕特里克·罗素
2021-09-13 32

ARTIFACTORY:如何对request.log进行性能分析

相关版本:此信息与…有关Artifactory版本4.倍通过6.倍

显示在Artifactory的request.log当你试图确定什么、何时、何地、为什么和如何给出时,提供对你非常有用的信息性能问题。日志格式非常强大,因为它能够测量Artifactory处理请求所需的时间,而不管网络情况如何。这可以排除网络作为性能问题的一个因素。

以下是一个标准的request.log条目的格式:

| 2632 | 20140508154145 |请求86:12:14:192管理| | | / jcenter / org/iostreams/iostreams/0.2/iostreams-0.2.jar HTTP / 1.1 | 200 | 8296 |

日期和时间戳

给定请求完成并输入日志文件的日期和时间。格式将显示为[YYYYMMDDHHMMSS]

请求时间

处理请求所需的时间(以毫秒为单位)

请求类型

DOWNLOAD用于下载请求
UPLOAD用于上传请求
请求任何其他请求

知识产权

请求用户的IP地址

用户名

请求用户的用户名或
匿名访问时为non_authenticated_user

请求方法

HTTP请求方法(如GET、PUT等)

请求的资源路径

请求资源的相对路径

协议版本

HTTP协议版本

响应代码

HTTP响应码

请求或响应的大小(字节)

如果请求方法是GET:响应的大小
如果请求方法是PUT或POST:请求的大小

分析性能问题最重要的字段是请求时间和响应大小。这可以通过使用一些bash终端命令来搜索文件来演示。

检查性能问题

当涉及到性能问题时,最需要分析的字段是请求时间请求大小或响应。可以通过使用一些bash终端命令搜索请求日志文件来演示这一点,如下所示。

让我们来看看一个非常常见的问题:码头工人登录超时。如果您遇到了这个问题,您肯定想尝试弄清楚为什么会发生这种情况。您可能知道docker登录进程通过使用Artifactory API请求令牌。可以得到精确的请求格式通过模拟对Artifactory的docker登录请求:

GET /api/docker/docker-repo/v2/token curl -u admin:password http://artifactory.com/artifactory/api/docker-local/v2/token

现在,有了URL搜寻,一组grep搜索可以精心设计为解析您请求日志:

请注意:此搜索将识别耗时在10,000到99,999毫秒(10-99秒)之间的任何请求。
#在grep中,单个通配符是句点'。grep“|…|REQUEST" request.log | grep "api/docker" | grep "v2/token"#替代“awk”搜索awk 'BEGIN {FS="|"} ($2 > requestTime) && ($6 == "GET") {print $1 " response_time: " $2 " " $7} " requestTime=10000 request.log#示例长时间运行的docker登录20190726113810| 39070[39秒]|REQUEST| 127.0.0.1 |Jenkins-LDAP|GET|/api/docker/docker-virtual/v2/token|HTTP/1.1|200|0 #添加一个额外的点搜索100 - 999秒请求20190726114126 | 126000[126秒]|REQUEST| 127.0.0.1 |Jenkins-LDAP|GET|/api/docker/docker-virtual/v2/token|HTTP/1.1|200|0

这种技术允许您查看Artifactory是否是原因缓慢的请求。您可能有理由担心,例如,如果一个给定的长时间运行的请求是针对一个小文件的。另一方面,如果该文件是第一次从远程端点提取,那么在该文件被缓存之后,与后续情况相比,该请求可能需要更长的时间来执行:

2.2秒流…53个KB[20181228204422|。2218| | 127.0.0.1请求管理| | | / api / npm npm / sshpk /——/ sshpk-1.16.0.tgz | HTTP / 1.1 | 200 |5340520190814003406 |681| | 127.0.0.1请求管理| | | / api / npm npm / sshpk /——/ sshpk-1.16.0.tgz | HTTP / 1.1 | 200 |53405

当然,也有一些限制这种方法。例如,缓慢的下载或上传可能需要更长的时间来执行,因为您的客户端需要流式传输大量数据。实际上,如果遇到传输大量二进制数据的长时间运行请求,则执行问题的时间长度可能会记录为预期行为

[137毫秒上传2.5 MB文件]20181204003658|137(毫秒)| | 127.0.0.1请求管理| |把| / libs-snapshot-local org/jfrog/test/multi3/3.7 snapshot/multi3 - 3.7 snapshot.war; build.timestamp = 1543883800178; build.name = maven-pipeline; build.number = 23 HTTP / 1.1 | 201 | |2533340 [2.5 mb]

要解决这些问题,最好考虑Artifactory如何处理请求,以便确定瓶颈。下图显示了Artifactory用来处理二进制文件下载的标准过程:

用户添加图片

1.Artifactory接收请求(和请求时间开始滴答声)
2.Artifactory进行身份验证用户通过其嵌入式Access服务器(在Access数据库中搜索用户)
3.Artifactory查找文件校验和在数据库中
4.Artifactory获取文件从文件系统
5.Artifactory流式传输文件致用户
6.请求关闭,请求时间停止, request.log条目为记录

可以测试链中的每个环节,看看它是否是瓶颈。例如,您可以仅使用此请求日志分析来消除步骤1和步骤5之前或之后的任何内容(然后它只在应用程序内部变慢)。

检查请求速率

如果人工工厂用了很多处理能力要了解导致如此高使用率的原因,一种方法是查看您的请求率。这可以通过分析Unix BASH终端中的日志来完成,并依赖于请求日志时间戳旁边的一组锚文本。要获得特定小时内发生的所有请求的计数,您可以查找以小时标记结束的请求日志时间戳:

#从2019-07-29 09:00 AM开始计数
>$ grep "2019072909" request*.log | wc - 1
162848
>$ grep "2019072910" request*.log | wc - 1
301432
>$ grep "2019072911" request*.log | wc - 1
275613
>$ grep "2019072912" request*.log | wc - 1
359222
patrick -mac:日志patrick $ grep“2019072913”请求*.log | wc - 1
219759

用户添加图片

返回的每个数字都表示在该小时内服务的请求。当你想要的时候,这些数字会对你很有帮助调音和音阶根据您商店的特殊需要制作工艺品。

信息如何对工件进行重载调优是可用的在这里