Rest Performance
Introduction
The pipeline usually has Client -> Gateway -> Load Balancer -> Service
Performance Evaluation|Optimization
Evaluate Connection Latency between Client|Gateway
Connection latency could be evaluated by curl test
curl-format.txt
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
time_appconnect 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_connect The time, in seconds, it took from the start until the TCP connect to the remote host (or proxy) was completed.
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 The time, in seconds, it took for all redirection steps including 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 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.
time_total The total time, in seconds, that the full operation lasted.
Reference: https://curl.haxx.se/docs/manpage.html
curl -s -o /dev/null -w "@curl-format.txt" https://www.google.com/?[1-3]
time_namelookup: 0.062749
time_connect: 0.097960
time_appconnect: 0.177406
time_pretransfer: 0.177604
time_redirect: 0.000000
time_starttransfer: 0.284539
----------
time_total: 0.290738
If appconnect time (TCP connection + SSL Handshake) is higher than ~200ms, this means something is missing
Evaluate TLS and Cipher
Check the TLS version used
TLS 1.3 is performant over TLS1.2, ensure latest TLS version is being used in connection negotiation
The TLS 1.3 handshake saves an entire round-trip and hundreds of milliseconds. A major improvement over the TLS 1.2 handshake.
https://www.thesslstore.com/blog/tls-1-3-handshake-tls-1-2/
openssl s_client -host www.google.com -port 443
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Ensure Server use latest TLS version
Enforce latest TLS version over Server|Gateway e.g. TLS1.3
Ensure Client use latest TLS version
This would ensure TLS connection happens at latest version between Client and Server
$ openssl ciphers -v | awk '{print $2}' | sort | uniq
SSLv3
TLSv1
TLSv1.2
TLSv1.3
Evaluate Connection Re-use at Gateway
Gateway would create connection with ELB|Service
Connection re-use would save the cost of connection and latency
Evaluate web-server (Nginx etc) being used at Gateway and ensure connection re-use is enabled, all web-server have connection re-use feature supported
Evaluate HTTP/2
HTTP/2 is highly performant over HTTP/1 and boost client experience
HTTP/2 is built over Google SPDY protocol
Ensure HTTP/2 is getting used for traffic
curl -v https://www.google.com/
> GET / HTTP/2
References