mirror of
https://github.com/GSA/notifications-api.git
synced 2026-05-17 23:34:05 -04:00
using lots of CPU by tracing the application to gather some data Alternatively we could take a stab in the dark, which is what this commit is doing. I have the hypothesis that we are not re-using TCP connections using HTTP keepalive Refer to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Keep-Alive This means we are renegotiating the TLS connection every time we want to send an SMS. When we are sending lots of SMS messages then this will do a lot of crypto handshaking which is expensive (in terms of CPU) ie send_sms calls request() which creates a new tcp connection and a new TLS handshake When you use request.Session() to create a session it uses urllib3's connection pooling, I've arbitrarily chosen 32 connections per pool (with a default number of pools = 10) ie init_app creates a session which has underlying connection pools send_sms claims a connection from the pool and uses it to create or re-use an existing TLS connection Sessions are usually not great because they share data like cookies, but when calling an API this is fine, or at least it is probably worth canarying Another way of re-using connections is by running HAProxy or similar as a side-car proxy, which proxies to the API. send_sms would make a local TCP connection to HAProxy which proxies to the MMG or Firetext API via TLS, adding the Connection: keep-alive header This command can be used to see how many TLS handshakes your computer is doing, with some false positives: tcpdump -n "tcp port 443 and (tcp[((tcp[12] & 0xf0) >> 2)] = 0x16)" (alternatively we could just instrument the code /shrug) Signed-off-by: toby lorne <toby@toby.codes>