Wie messe ich gleichzeitig Anfrage- und Antwortzeiten mit cURL?

Question

Ich habe einen Webdienst, der Daten im JSON-Format empfängt, die Daten verarbeitet und dann das Ergebnis an den Anfragenden zurückgibt.

Ich möchte die Anfrage-, Antwort- und Gesamtzeit mit cURL messen.

Meine Beispielanfrage sieht folgendermaßen aus:

curl -X POST -d @file server:port

und ich messe dies derzeit mit dem time-Befehl in Linux:

time curl -X POST -d @file server:port

Der Zeitbefehl misst jedoch nur die gesamte Zeit, was jedoch nicht ganz das ist, wonach ich suche.

Gibt es einen Weg, um die Anfrage- und Antwortzeiten mit cURL zu messen?

Answer 1

Wenn Sie die Latenz analysieren oder zusammenfassen möchten, können Sie Apache Bench ausprobieren:

ab -n [Anzahl der Proben] [URL]

Zum Beispiel:

ab -n 100 http://www.google.com/

Es zeigt:

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 (bitte geduldig sein).....erledigt

Server-Software:        gws
Server-Hostname:        www.google.com
Server-Port:            80

Dokumentpfad:          /
Dokumentlänge:         12419 Bytes

Concurrency Level:      1
Zeit für Tests:         10.700 Sekunden
Abgeschlossene Anfragen:      100
Fehlgeschlagene Anfragen:        97
   (Connect: 0, Receive: 0, Length: 97, Exceptions: 0)
Insgesamt übertragen:      1331107 Bytes
Übertragene HTML:       1268293 Bytes
Anfragen pro Sekunde:    9,35 [#/sec] (Durchschnitt)
Zeit pro Anfrage:       107,004 [ms] (Durchschnitt)
Zeit pro Anfrage:       107,004 [ms] (Durchschnitt, über alle gleichzeitigen Anfragen)
Übertragungsrate:          121,48 [KBytes/Sek] empfangen

Verbindungszahlen (ms)
              min  mean[+/-sd] median   max
Connect:       20   22   0,8     22      26
Verarbeitung:    59   85 108,7     68     911
Warten:       59   85 108,7     67     910
Gesamt:         80  107 108,8     90     932

Anteil der Anfragen, die innerhalb einer bestimmten Zeit (ms) bedient wurden
  50%     90
  66%     91
  75%     93
  80%     95
  90%    105
  95%    111
  98%    773
  99%    932
 100%    932 (längste Anfrage)

Answer 2

Sie können curl -v --trace-time verwenden, um Zeitstempel zur Trace-/Verbose-Ausgabe hinzuzufügen. Dies muss im Verbose- oder Trace-Modus durchgeführt werden, um etwas zu bewirken.

Answer 3

Eine andere Möglichkeit besteht darin, ~/.curlrc wie folgt zu konfigurieren

-w "\n\n==== cURL Messstatistiken ====\ngesamt: %{time_total} Sekunden \ngröße: %{size_download} Bytes \ndnslookup: %{time_namelookup} Sekunden \nverbinden: %{time_connect} Sekunden \nappconnect: %{time_appconnect} Sekunden \numleitung: %{time_redirect} Sekunden \npretransfer: %{time_pretransfer} Sekunden \nstarttransfer: %{time_starttransfer} Sekunden \ndownloadgeschwindigkeit: %{speed_download} Byte/Sekunde \nuploadgeschwindigkeit: %{speed_upload} Byte/Sekunde \n\n"

Also ist die Ausgabe von curl

 curl -I https://google.com
HTTP/2 301
location: https://www.google.com/
content-type: text/html; charset=UTF-8
date: Mon, 04 Mar 2019 08:02:43 GMT
expires: Wed, 03 Apr 2019 08:02:43 GMT
cache-control: public, max-age=2592000
server: gws
content-length: 220
x-xss-protection: 1; mode=block
x-frame-options: SAMEORIGIN
alt-svc: quic=":443"; ma=2592000; v="44,43,39"

==== cURL Messstatistiken ====
gesamt: 0,211117 Sekunden
größe: 0 Bytes
dnslookup: 0,067179 Sekunden
verbinden: 0,098817 Sekunden
appconnect: 0,176232 Sekunden
umleitung: 0,000000 Sekunden
pretransfer: 0,176438 Sekunden
starttransfer: 0,209634 Sekunden
downloadgeschwindigkeit: 0,000 Byte/Sekunde
uploadgeschwindigkeit: 0,000 Byte/Sekunde

Answer 4

Eine weitere Option, die möglicherweise die einfachste ist in Bezug auf die Befehlszeile, ist das Hinzufügen der integrierten --trace-time Option:

curl -X POST -d @file server:port --trace-time

Auch wenn es technisch gesehen die Zeiten der verschiedenen Schritte nicht wie vom OP gefordert ausgibt, werden unten die Zeitstempel für alle Schritte der Anfrage angezeigt. Mit diesem können Sie (ziemlich einfach) berechnen, wie lange jeder Schritt gedauert hat.

$ curl https://www.google.com --trace-time -v -o /dev/null
13:29:11.148734 * URL neugebaut: https://www.google.com/
  % Total    % Received % Xferd  Durchschn. Geschw. Zeit     Zeit     Zeit  Aktuell
                                 Heruntergeladen  Hochgeladen  Gesamt   Verstrichen Zeit    Restlich Time Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     013:29:11.149958 *   Verbindung zu 172.217.20.36 wird hergestellt...
13:29:11.149993 * TCP_NODELAY gesetzt
13:29:11.163177 * Verbindung zu www.google.com (172.217.20.36) Port 443 (#0) hergestellt
13:29:11.164768 * ALPN, stellt h2 bereit
13:29:11.164804 * ALPN, stellt http/1.1 bereit
13:29:11.164833 * Zertifikat verifizieren erfolgreich festgelegt:
13:29:11.164863 *   CAfile: none
  CApath: /etc/ssl/certs
13:29:11.165046 } [5 Bytes Daten]
13:29:11.165099 * (304) (AUS), TLS-Handshake, Client hallo (1):
13:29:11.165128 } [512 Bytes Daten]
13:29:11.189518 * (304) (HEREIN), TLS-Handshake, Server hallo (2):
13:29:11.189537 { [100 Bytes Daten]
13:29:11.189628 * TLSv1.2 (HEREIN), TLS-Handshake, Zertifikat (11):
13:29:11.189658 { [2104 Bytes Daten]
13:29:11.190243 * TLSv1.2 (HEREIN), TLS-Handshake, Server-Schlüsselaustausch (12):
13:29:11.190277 { [115 Bytes Daten]
13:29:11.190507 * TLSv1.2 (HEREIN), TLS-Handshake, Server fertig (14):
13:29:11.190539 { [4 Bytes Daten]
13:29:11.190770 * TLSv1.2 (AUS), TLS-Handshake, Client Schlüsselfreigabe (16):
13:29:11.190797 } [37 Bytes Daten]
13:29:11.190890 * TLSv1.2 (AUS), TLS-Wechsel Chiffre, Client hallo (1):
13:29:11.190915 } [1 Byte Daten]
13:29:11.191023 * TLSv1.2 (AUS), TLS-Handshake, Beendet (20):
13:29:11.191053 } [16 Bytes Daten]
13:29:11.204324 * TLSv1.2 (HEREIN), TLS-Handshake, Beendet (20):
13:29:11.204358 { [16 Bytes Daten]
13:29:11.204417 * SSL-Verbindung unter Verwendung von TLSv1.2 / ECDHE-ECDSA-CHACHA20-POLY1305
13:29:11.204451 * ALPN, Server akzeptiert die Verwendung von h2
13:29:11.204483 * Server-Zertifikat:
13:29:11.204520 *  subject: C=US; ST=Kalifornien; L=Mountain View; O=Google LLC; CN=www.google.com
13:29:11.204555 *  Startdatum:  2. Okt 07:29:00 2018 GMT
13:29:11.204585 *  Ablaufdatum:  25. Dez 07:29:00 2018 GMT
13:29:11.204623 *  subjectAltName: Host "www.google.com" entspricht dem Zertifikat "www.google.com"
13:29:11.204663 *  Herausgeber: C=US; O=Google Trust Services; CN=Google Internet Authority G3
13:29:11.204701 *  SSL-Zertifikat erfolgreich verifiziert.
13:29:11.204754 * Verwenden von HTTP2, Server unterstützt Multinutzung
13:29:11.204795 * Verbindungsstatus geändert (HTTP/2 bestätigt)
13:29:11.204840 * Kopieren von HTTP/2-Daten im Strompuffer zum Verbindungspuffer nach dem Upgrade: Länge=0
13:29:11.204881 } [5 Bytes Daten]
13:29:11.204983 * Verwenden von Stream-ID: 1 (leichter Griff 0x55846ef24520)
13:29:11.205034 } [5 Bytes Daten]
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 Daten]
13:29:11.218173 * Verbindungsstatus geändert (MAX_CONCURRENT_STREAMS == 100)!
13:29:11.218211 } [5 Bytes Daten]
13:29:11.251936 < HTTP/2 200 
13:29:11.251962 < Datum: Fr, 19. Okt 2018 10:29:11 GMT
13:29:11.251998 < Ablauf: -1
13:29:11.252046 < Cache-Control: privat, max-age=0
13:29:11.252085 < Inhaltstyp: text/html; Zeichensatz=ISO-8859-1
13:29:11.252119 < P3P: CP="Dies ist keine P3P-Richtlinie! Weitere Informationen finden Sie unter g.co/p3pHilfe."
13:29:11.252160 < Server: gws
13:29:11.252198 < X-XSS-Schutz: 1; Modus=block
13:29:11.252228 < X-FRAME-OPTIONS: SAMEORIGIN
13:29:11.252262 < Set-Cookie: 1P_JAR=2018-10-19-10; Ablauf=Son, 18-Nov-2018 10:29:11 GMT; Pfad=/; Domain=.google.com
13:29:11.252297 < Set-Cookie: NID=141=pzXxp1jrJmLwFVl9bLMPFdGCtG8ySQKxB2rlDWgerrKJeXxfdmB1HhJ1UXzX-OaFQcnR1A9LKYxi__PWMigjMBQHmI3xkU53LI_TsYRbkMNJNdxs-caQQ7fEcDGE694S; Ablauf=Sam, 20-Apr-2019 10:29:11 GMT; Pfad=/; Domain=.google.com; Nur-HTTP
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 Daten]
100 12215    0 12215    0     0   112k      0 --:--:-- --:--:-- --:--:--  112k
13:29:11.255674 * Verbindung #0 zum Host www.google.com verbleibt intakt

Answer 5

Hey ist besser als Apache Bench, hat weniger Probleme mit SSL

./hey https://google.com -mehr
Zusammenfassung:
  Gesamt:    3.0960 Sekunden
  Langsamste:  1.6052 Sekunden
  Schnellste:  0.4063 Sekunden
  Durchschnitt:  0.6773 Sekunden
  Anfragen/Sekunde: 64.5992

Antwortzeit-Histogramm:
  0.406 [1] |
  0.526 [142]   |
  0.646 [1] |
  0.766 [6] |
  0.886 [0] |
  1.006 [0] |
  1.126 [0] |
  1.246 [12]    |
  1.365 [32]    |
  1.485 [5] |
  1.605 [1] |

Verteilung der Latenz:
  10% in 0.4265 Sekunden
  25% in 0.4505 Sekunden
  50% in 0.4838 Sekunden
  75% in 1.2181 Sekunden
  90% in 1.2869 Sekunden
  95% in 1.3384 Sekunden
  99% in 1.4085 Sekunden

Details (Durchschnitt, schnellste, langsamste):
  DNS+Wählverbindung:    0.1150 Sekunden, 0.0000 Sekunden, 0.4849 Sekunden
  DNS-Suche:    0.0032 Sekunden, 0.0000 Sekunden, 0.0319 Sekunden
  Anfrage schreiben:     0.0001 Sekunden, 0.0000 Sekunden, 0.0007 Sekunden
  Antwort warten:     0.2068 Sekunden, 0.1690 Sekunden, 0.4906 Sekunden
  Antwort lesen:     0.0117 Sekunden, 0.0011 Sekunden, 0.2375 Sekunden

Verteilung der Statuscodes:
  [200] 200 Antworten

Referenzen

• https://github.com/rakyll/hey