Linux下使用curl查看http请求各阶段耗时

　　1. 准备文件模版（curl.txt）

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

　　2. 使用curl带以下参数请求

curl -w "@curl.txt" -o /dev/null -s https://www.sogo.com

　　结果：

[@ ~]# curl -w "@curl" -o /dev/null -s https://www.sogo.com

            time_namelookup:  0.004
               time_connect:  0.014
            time_appconnect:  0.141
           time_pretransfer:  0.141
              time_redirect:  0.000
         time_starttransfer:  0.153
                            ----------
                 time_total:  0.165

　　

　　NAMELOOKUP：从开始计算，域名解析完成的耗时

　　CURLINFO_NAMELOOKUP_TIME. The time it took from the start until the name resolving was completed.

　　CONNECT：从开始计算，TCP建立完成的耗时

　　CURLINFO_CONNECT_TIME. The time it took from the start until the connect to the remote host (or proxy) was completed.

　　APPCONNECT：从开始计算，应用层（SSL，在TCP之上的应用层）连接/握手完成的耗时

　　CURLINFO_APPCONNECT_TIME. The time it took from the start until the SSL connect/handshake with the remote host was completed. (Added in in 7.19.0)

　　PRETRANSFER：从开始计算，准备开始传输数据的耗时

　　CURLINFO_PRETRANSFER_TIME. The time it took from the start until the file transfer is just about to begin. This includes all pre-transfer commands and negotiations that are specific to the particular protocol(s) involved.

　　STARTTRANSFER：从开始计算，开始传输数据的耗时（libcurl接收到第一个字节）

　　CURLINFO_STARTTRANSFER_TIME. The time it took from the start until the first byte is received by libcurl.

　　TOTAL：总的耗时

　　CURLINFO_TOTAL_TIME. Total time of the previous request.

　　REDIRECT：整个过程重定向的耗时，如果整个过程没有重定向，这个时间为0

举个实际的例子吧。 工作中有人反映，我们有个页面打开的非常慢，需要1份多钟。

进入我们自己服务的docker容器， curl  -v -w "@curl.txt" -o /dev/null -s  127.0.0.1:/xxx/xxx/x。发现时间主要在time_starttransfer之后，也就是time_total - time_starttransfer占了整个请求的大部分时间。

这也就基本定位是微服务自身的问题。  看日志，在读取文件列表时非常慢。

使用time ls -l和time tar -zxvf ***.tar.gz 和linux的dd命令发现文件读写非常慢。time 加到linux命令前，可以查看命令的执行时间。

联系持久卷nfs的同事，微小的网络延迟都会导致nfs读取速度很慢。这也是带延迟测试场景，实际场景中有延迟时要先解决延迟的问题。