0%

最近工作中遇到一个问题,某个请求的响应特别慢,因此我就希望有一种方法能够分析到底请求的哪一步耗时比较长,好进一步找到问题的原因。

在网络上搜索了一下,发现了一个非常好用的方法,curl 命令就能帮助分析请求的各个部分耗时情况。

curl 参数

curl 命令提供了 -w 参数,这个参数在 manpage 是这样解释的:

-w, --write-out <format>
              Make curl display information on stdout after a completed transfer. The format is a string that may contain plain text mixed with any number of variables. The  format
              can  be  specified  as  a literal "string", or you can have curl read the format from a file with "@filename" and to tell curl to read the format from stdin you write
              "@-".

              The variables present in the output format will be substituted by the value or text that curl thinks fit, as described below. All variables are specified  as  %{vari‐
              able_name} and to output a normal % you just write them as %%. You can output a newline by using \n, a carriage return with \r and a tab space with \t.

它能够按照指定的格式打印某些信息,里面可以使用某些特定的变量,而且支持 \n、\t 和 \r 转义字符。提供的变量很多,比如 status_code、local_port、size_download 等等,这篇文章我们只关注和请求时间有关的变量(以 time_ 开头的变量)。

试用

$ curl -o /dev/null -s -w "time_connect: %{time_connect}\ntime_starttransfer: %{time_starttransfer}\ntime_nslookup:%{time_namelookup}\ntime_total: %{time_total}\n" "https://www.baidu.com"
time_connect: 0.009
time_starttransfer: 0.065
time_nslookup:0.007
time_total: 0.065

步骤

先往文本文件 curl.txt 写入下面的内容:

   time_namelookup:  %{time_namelookup}\n
      time_connect:  %{time_connect}\n
   time_appconnect:  %{time_appconnect}\n
     time_redirect:  %{time_redirect}\n
  time_pretransfer:  %{time_pretransfer}\n
time_starttransfer:  %{time_starttransfer}\n
                   ----------\n
        time_total:  %{time_total}\n

每个变量的解释如下:

time_namelookup:DNS 域名解析的时候,就是把 https://baidu.com 转换成 ip 地址的过程
time_connect:TCP 连接建立的时间,就是三次握手的时间
time_appconnect:SSL/SSH 等上层协议建立连接的时间,比如 connect/handshake 的时间
time_redirect:从开始到最后一个请求事务的时间
time_pretransfer:从请求开始到响应开始传输的时间
time_starttransfer:从请求开始到第一个字节将要传输的时间
time_total:这次请求花费的全部时间

示例

例子:

$ curl -w "@curl.txt" -o /dev/null -s -L  'http://www.baidu.com'
time_namelookup:  0.004
       time_connect:  0.015
    time_appconnect:  0.000
      time_redirect:  0.000
   time_pretransfer:  0.015
 time_starttransfer:  0.027
                    ----------
         time_total:  0.027

可以看到这次请求各个步骤的时间都打印出来了,每个数字的单位都是秒(seconds),这样可以分析哪一步比较耗时,方便定位问题。这个命令各个参数的意义:

-w:从文件中读取要打印信息的格式
-o /dev/null:把响应的内容丢弃,因为我们这里并不关心它,只关心请求的耗时情况
-s:不要打印进度条
从这个输出,我们可以算出各个步骤的时间:

DNS 查询:4ms
TCP 连接时间:pretransfter(15) - namelookup(4) = 11ms
服务器处理时间:starttransfter(27) - pretransfer(15) = 12ms
内容传输时间:total(27) - starttransfer(27) = 0ms

-w 参数详解

以下是 - w 参数对应的一些变量以及对应的解释:

  • url_effective 最终获取的 url 地址,尤其是当你指定给 curl 的地址存在 301 跳转,且通过 - L 继续追踪的情形。
  • http_code http 状态码,如 200 成功,301 转向,404 未找到,500 服务器错误等。(The numerical response code that was found in the last retrieved HTTP (S) or FTP (s) transfer. In 7.18.2 the alias response_code was added to show the same info.)
  • http_connect The numerical code that was found in the last response (from a proxy) to a curl CONNECT request. (Added in 7.12.4)
  • time_total 总时间,按秒计。精确到小数点后三位。 (The total time, in seconds, that the full operation lasted. The time will be displayed with millisecond resolution.)
  • time_namelookup DNS 解析时间,从请求开始到 DNS 解析完毕所用时间。(The time, in seconds, it took from the start until the name resolving was completed.)
  • time_connect 连接时间,从开始到建立 TCP 连接完成所用时间,包括前边 DNS 解析时间,如果需要单纯的得到连接时间,用这个 time_connect 时间减去前边 time_namelookup 时间。以下同理,不再赘述。(The time, in seconds, it took from the start until the TCP connect to the remote host (or proxy) was completed.)
  • time_appconnect 连接建立完成时间,如 SSL/SSH 等建立连接或者完成三次握手时间。(The time, in seconds, it took from the start until the SSL/SSH/etc connect/handshake to the remote host was completed. (Added in 7.19.0))
  • time_pretransfer 从开始到准备传输的时间。(The time, in seconds, it took from the start until the file transfer was just about to begin. This includes all pre-transfer commands and negotiations that are specific to the particular protocol (s) involved.)
  • time_redirect 重定向时间,包括到最后一次传输前的几次重定向的 DNS 解析,连接,预传输,传输时间。(The time, in seconds, it took for all redirection steps include name lookup, connect, pretransfer and transfer before the final transaction was started. time_redirect shows the complete execution time for multiple redirections. (Added in 7.12.3))
  • time_starttransfer 开始传输时间。在发出请求之后,Web 服务器返回数据的第一个字节所用的时间 (The time, in seconds, it took from the start until the first byte was just about to be transferred. This includes time_pretransfer and also the time the server needed to calculate the result.)
  • size_download 下载大小。(The total amount of bytes that were downloaded.)
  • size_upload 上传大小。(The total amount of bytes that were uploaded.)
    size_header 下载的 header 的大小 (The total amount of bytes of the downloaded headers.)
  • size_request 请求的大小。(The total amount of bytes that were sent in the HTTP request.)
  • speed_download 下载速度,单位 - 字节每秒。(The average download speed that curl measured for the complete download. Bytes per second.)
  • speed_upload 上传速度,单位 - 字节每秒。(The average upload speed that curl measured for the complete upload. Bytes per second.)
  • content_type 就是 content-Type,不用多说了,这是一个访问我博客首页返回的结果示例 (text/html; charset=UTF-8);(The Content-Type of the requested document, if there was any.)
  • num_connects 最近的的一次传输中创建的连接数目。Number of new connects made in the recent transfer. (Added in 7.12.3)
  • num_redirects 在请求中跳转的次数。Number of redirects that were followed in the request. (Added in 7.12.3)
    redirect_url When a HTTP request was made without -L to follow redirects, this variable will show the actual URL a redirect would take you to. (Added in 7.18.2)
  • ftp_entry_path 当连接到远程的 ftp 服务器时的初始路径。The initial path libcurl ended up in when logging on to the remote FTP server. (Added in 7.15.4)
  • ssl_verify_result ssl 认证结果,返回 0 表示认证成功。(The result of the SSL peer certificate verification that was requested. 0 means the verification was successful. (Added in 7.19.0))

使用 Collections.sort 排序时,可能出现如下报错:

image-20220608142210621

问题复现

Integer[] array = {0, 0, 0, 0, 0, 0, 0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
                   0, 0, 0, 1, 1, 0, 0, 1, 0, 1, 0, 0, 0, 0, 1, 0, 0, 1, 0, 0, 0, 2, 1, 0, 0, 0, 2, 30, 0, 3};
List<Integer> list = Arrays.asList(array);
Collections.sort(list, new Comparator<Integer>() {
    @Override
    public int compare(Integer o1, Integer o2) {
        return o1 > o2 ? 1 : -1;	// 错误的方式
    }
});
System.out.println(list);

问题原因

Collections.sort () 在 JDK6 和 JDK7 中实现的底层排序算法变了,在 JDK6 中使用的时 MergeSort 排序,而在 JDK7 中使用的是 TimSort。

Timsort 结合了归并排序和插入排序。这个算法在实现过程中明确需要:严格的单调递增或者递减来保证算法的稳定性。

image-20220608142704366

  • sgn(compare(x, y)) == -sgn(compare(y, x))
  • ((compare(x, y)>0) && (compare(y, z)>0)) implies compare(x, z)>0
  • compare(x, y)==0 implies that sgn(compare(x, z))==sgn(compare(y, z)) for all z

说明:

  • 自反性:x,y 的比较结果和 y,x 的比较结果相反。
  • 传递性:x>y,y>z, 则 x>z。
  • 对称性:x=y, 则 x,z 比较结果和 y,z 比较结果相同。(也叫可逆比较)

问题解决

方式一:使用 compareTo

官方推荐使用该方式。

Collections.sort(list, new Comparator<Integer>() {
    @Override
    public int compare(Integer o1, Integer o2) {
        return o1.compareTo(o2);
    }
});

方式二:判断相等

Collections.sort(list, new Comparator<Integer>() {
    @Override
    public int compare(Integer o1, Integer o2) {
        if (o1 > o2) {
            return 1;
        } else if (o1 < o2) {
            return -1;
        } else {
            return 0;
        }
    }
});

方式三:增加 JVM 参数

给 jvm 添加启动参数:

-Djava.util.Arrays.useLegacyMergeSort=true

但是不建议使用这种方式。这种的弊端在于会导致无法使用 jdk1.7 里面的新特性,对后期的升级是有不可知的影响的。

需要注意

并不一定你的集合中存在相等的元素,并且比较函数不符合上面的严谨定义,就一定会稳定浮现此异常。

实际上我们在生产环境出现此异常的概率很小,毕竟 java 并不会蠢到先去把整个数组都校验一遍,实际上它是在排序的过程中发现你不符合此条件的。

所以有可能某种集合顺序让你刚好绕过了此判断。

一个会引发该异常的 Case:

Integer[] array = {0, 0, 0, 0, 0, 0, 0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
                   0, 0, 0, 1, 1, 0, 0, 1, 0, 1, 0, 0, 0, 0, 1, 0, 0, 1, 0, 0, 0, 2, 1, 0, 0, 0, 2, 30, 0, 3};

问题处理

循环依赖

构建时报错:

[exec] [ERROR] The projects in the reactor contain a cyclic reference: Edge between 'Vertex{label='com.xxx.xxx:aaa:0.0.49'}' and 'Vertex{label='com.xxx.xxx:bbb:0.0.49'}' introduces to cycle in the graph com.xxx.xxx:bbb:0.0.49 --> com.com.xxx.xxx:aaa:0.0.49 --> com.xxx.xxx:bbb:0.0.49 -> [Help 1]

解决方案:

夫工程的依赖 dependencies 加上 dependencyManagement 标签。

<dependencyManagement>
    <dependencies>
    </dependencies>
</dependencyManagement>

Maven 通过 dependencyManagement 元素来管理 jar 包的版本,让⼦项⽬中引⽤⼀个依赖,⽽不⽤显⽰的列出版本号。Maven 会沿着⽗⼦层次向上⾛,直到找到⼀个拥有 dependencyManagement 元素的项⽬,然后它就会使⽤在
这个 dependencyManagement 元素中指定的版本号。
这样做的好处:统⼀管理项⽬的版本号,确保应⽤的各个项⽬的依赖和版本⼀致,才能保证测试的和发布的是相同的成果,因此,在顶层
pom 中定义共同的依赖关系。同时可以避免在每个使⽤的⼦项⽬中都声明⼀个版本号,这样想升级或者切换到另⼀个版本时,只需要在⽗类
容器⾥更新,不需要任何⼀个⼦项⽬的修改;如果某个⼦项⽬需要另外⼀个版本号时,只需要在 dependencies 中声明⼀个版本号即可。⼦
类就会使⽤⼦类声明的版本号,不继承于⽗类版本号。

在最顶级的项⽬中才需要配置 标签,其⼦项⽬在标签中继承该顶级项⽬的 pom.xml ⽂件即可。

继承后⼦项⽬中的 jar 包的版本就跟顶级项⽬ pom.xml ⽂件中规定的⼀致。

dependencies 和 dependencyManagement 的区别在于:

  • 前者,即使在⼦项⽬中不写该依赖项,那么⼦项⽬仍然会从⽗项⽬中继承该依赖项。
  • 后者,如果在⼦项⽬中不写该依赖项,那么⼦项⽬中是不会从⽗项⽬继承该依赖项的;只有在⼦项⽬中写了该依赖项,才会从⽗项⽬中继承该项,并且 version 和 scope 都读取⾃ ⽗ pom。

Dubbo 支持同一服务向多注册中心同时注册,或者不同服务分别注册到不同的注册中心上去,甚至可以同时引用注册在不同注册中心上的同名服务。另外,注册中心是支持自定义扩展的。

本文介绍 Dubbo 多注册中心的配置和使用。

阅读全文 »