我有一个web服务，它接收JSON格式的数据，处理数据，然后将结果返回给请求者。
我想使用cURL测量请求、响应和总时间。
我的请求示例如下:
curl -X POST -d @file server:port
我现在用Linux中的time命令来测量:
time curl -X POST -d @file server:port
然而，time命令只测量总时间——这并不是我想要的。
有什么方法可以使用cURL来测量请求和响应时间吗?
当前回答
就命令行而言，另一个可能是最简单的选项是添加内置的——trace-time选项:
curl -X POST -d @file server:port --trace-time
尽管从技术上讲，它不会输出OP所请求的各个步骤的计时，但它确实显示了请求所有步骤的时间戳，如下所示。使用它，您可以(相当容易地)计算出每一步所花费的时间。
$ curl https://www.google.com --trace-time -v -o /dev/null
13:29:11.148734 * Rebuilt URL to: https://www.google.com/
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 013:29:11.149958 * Trying 172.217.20.36...
13:29:11.149993 * TCP_NODELAY set
13:29:11.163177 * Connected to www.google.com (172.217.20.36) port 443 (#0)
13:29:11.164768 * ALPN, offering h2
13:29:11.164804 * ALPN, offering http/1.1
13:29:11.164833 * successfully set certificate verify locations:
13:29:11.164863 * CAfile: none
CApath: /etc/ssl/certs
13:29:11.165046 } [5 bytes data]
13:29:11.165099 * (304) (OUT), TLS handshake, Client hello (1):
13:29:11.165128 } [512 bytes data]
13:29:11.189518 * (304) (IN), TLS handshake, Server hello (2):
13:29:11.189537 { [100 bytes data]
13:29:11.189628 * TLSv1.2 (IN), TLS handshake, Certificate (11):
13:29:11.189658 { [2104 bytes data]
13:29:11.190243 * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
13:29:11.190277 { [115 bytes data]
13:29:11.190507 * TLSv1.2 (IN), TLS handshake, Server finished (14):
13:29:11.190539 { [4 bytes data]
13:29:11.190770 * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
13:29:11.190797 } [37 bytes data]
13:29:11.190890 * TLSv1.2 (OUT), TLS change cipher, Client hello (1):
13:29:11.190915 } [1 bytes data]
13:29:11.191023 * TLSv1.2 (OUT), TLS handshake, Finished (20):
13:29:11.191053 } [16 bytes data]
13:29:11.204324 * TLSv1.2 (IN), TLS handshake, Finished (20):
13:29:11.204358 { [16 bytes data]
13:29:11.204417 * SSL connection using TLSv1.2 / ECDHE-ECDSA-CHACHA20-POLY1305
13:29:11.204451 * ALPN, server accepted to use h2
13:29:11.204483 * Server certificate:
13:29:11.204520 * subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=www.google.com
13:29:11.204555 * start date: Oct 2 07:29:00 2018 GMT
13:29:11.204585 * expire date: Dec 25 07:29:00 2018 GMT
13:29:11.204623 * subjectAltName: host "www.google.com" matched cert's "www.google.com"
13:29:11.204663 * issuer: C=US; O=Google Trust Services; CN=Google Internet Authority G3
13:29:11.204701 * SSL certificate verify ok.
13:29:11.204754 * Using HTTP2, server supports multi-use
13:29:11.204795 * Connection state changed (HTTP/2 confirmed)
13:29:11.204840 * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
13:29:11.204881 } [5 bytes data]
13:29:11.204983 * Using Stream ID: 1 (easy handle 0x55846ef24520)
13:29:11.205034 } [5 bytes data]
13:29:11.205104 > GET / HTTP/2
13:29:11.205104 > Host: www.google.com
13:29:11.205104 > User-Agent: curl/7.61.0
13:29:11.205104 > Accept: */*
13:29:11.205104 >
13:29:11.218116 { [5 bytes data]
13:29:11.218173 * Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
13:29:11.218211 } [5 bytes data]
13:29:11.251936 < HTTP/2 200
13:29:11.251962 < date: Fri, 19 Oct 2018 10:29:11 GMT
13:29:11.251998 < expires: -1
13:29:11.252046 < cache-control: private, max-age=0
13:29:11.252085 < content-type: text/html; charset=ISO-8859-1
13:29:11.252119 < p3p: CP="This is not a P3P policy! See g.co/p3phelp for more info."
13:29:11.252160 < server: gws
13:29:11.252198 < x-xss-protection: 1; mode=block
13:29:11.252228 < x-frame-options: SAMEORIGIN
13:29:11.252262 < set-cookie: 1P_JAR=2018-10-19-10; expires=Sun, 18-Nov-2018 10:29:11 GMT; path=/; domain=.google.com
13:29:11.252297 < set-cookie: NID=141=pzXxp1jrJmLwFVl9bLMPFdGCtG8ySQKxB2rlDWgerrKJeXxfdmB1HhJ1UXzX-OaFQcnR1A9LKYxi__PWMigjMBQHmI3xkU53LI_TsYRbkMNJNdxs-caQQ7fEcDGE694S; expires=Sat, 20-Apr-2019 10:29:11 GMT; path=/; domain=.google.com; HttpOnly
13:29:11.252336 < alt-svc: quic=":443"; ma=2592000; v="44,43,39,35"
13:29:11.252368 < accept-ranges: none
13:29:11.252408 < vary: Accept-Encoding
13:29:11.252438 <
13:29:11.252473 { [5 bytes data]
100 12215 0 12215 0 0 112k 0 --:--:-- --:--:-- --:--:-- 112k
13:29:11.255674 * Connection #0 to host www.google.com left intact
其他回答
我做了一个友好的格式化器来嗅探curl请求，以帮助调试(参见注释了解用法)。它包含了您可以以易于阅读的格式写出的所有已知输出参数。
https://gist.github.com/manifestinteractive/ce8dec10dcb4725b8513
以下内容是受西蒙的回答启发。它是自包含的(不需要单独的格式文件)，这使得它非常适合包含在.bashrc中。
curl_time() {
curl -so /dev/null -w "\
namelookup: %{time_namelookup}s\n\
connect: %{time_connect}s\n\
appconnect: %{time_appconnect}s\n\
pretransfer: %{time_pretransfer}s\n\
redirect: %{time_redirect}s\n\
starttransfer: %{time_starttransfer}s\n\
-------------------------\n\
total: %{time_total}s\n" "$@"
}
此外，它应该适用于curl通常接受的所有参数，因为“$@”只是传递了它们。例如，你可以这样做:
curl_time -X POST -H "Content-Type: application/json" -d '{"key": "val"}' https://postman-echo.com/post
输出:
namelookup: 0,125000s
connect: 0,250000s
appconnect: 0,609000s
pretransfer: 0,609000s
redirect: 0,000000s
starttransfer: 0,719000s
-------------------------
total: 0,719000s
以下是答案:
curl -X POST -d @file server:port -w %{time_connect}:%{time_starttransfer}:%{time_total}
所有与-w一起使用的变量都可以在man curl中找到。
如果你想分析或总结延迟，你可以尝试apache bench:
ab -n [number of samples] [url]
例如:
ab -n 100 http://www.google.com/
它将显示:
This is ApacheBench, Version 2.3 <$Revision: 1757674 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.google.com (be patient).....done
Server Software: gws
Server Hostname: www.google.com
Server Port: 80
Document Path: /
Document Length: 12419 bytes
Concurrency Level: 1
Time taken for tests: 10.700 seconds
Complete requests: 100
Failed requests: 97
(Connect: 0, Receive: 0, Length: 97, Exceptions: 0)
Total transferred: 1331107 bytes
HTML transferred: 1268293 bytes
Requests per second: 9.35 [#/sec] (mean)
Time per request: 107.004 [ms] (mean)
Time per request: 107.004 [ms] (mean, across all concurrent requests)
Transfer rate: 121.48 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 20 22 0.8 22 26
Processing: 59 85 108.7 68 911
Waiting: 59 85 108.7 67 910
Total: 80 107 108.8 90 932
Percentage of the requests served within a certain time (ms)
50% 90
66% 91
75% 93
80% 95
90% 105
95% 111
98% 773
99% 932
100% 932 (longest request)
一个你可以添加到你的.bashrc etc的快捷方式，基于这里的其他答案:
function perf {
curl -o /dev/null -s -w "%{time_connect} + %{time_starttransfer} = %{time_total}\n" "$1"
}
用法:
> perf stackoverflow.com
0.521 + 0.686 = 1.290
推荐文章
- 如何删除列表中的最后一项?
- 如何计算两次约会之间的间隔时间?
- PHP中的cURL是什么?
- 对bash脚本函数中定义的变量使用curl POST
- iPhone:如何获取当前毫秒数?
- 使用curl POST multipart/form-data的正确方法是什么?
- PHP -调试Curl
- (1) libcurl不支持或禁用https协议
- Python日志:使用时间格式的毫秒
- 如何改变。net WebClient对象的超时时间
- 我如何用python解析一个包含毫秒的时间字符串?
- 时间的“零”值是多少?围棋时间?
- 在尝试访问HTTPS url时，如何使用cURL处理证书?
- 如何使用PHP 7安装ext-curl扩展?
- 如何下载Angular2或更高版本的文件
