Golang: Http Transport unbedingt wiedeverwenden
Heute habe ich gelernt, dass man unbedingt den transport von net/http/transport.go
wiederverwenden sollte.
Macht nicht den gleichen Fehler!
In der Dokumentation steht dazu folgendes:
The Client’s Transport typically has internal state (cached TCP connections), so Clients should be reused instead of created as needed. Clients are safe for concurrent use by multiple goroutines.
Quelle: https://pkg.go.dev/net/http?utm_source=godoc#Client
Nach dem KISS-Prinzip könnte man beim Prototypen erstmal auf eine Wiederverwendung vom transport verzichten.
In der Dokumentation ist jedoch von should die Rede ist, hier hätte man schon hellhörig werden können.
1. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
Quelle: https://tools.ietf.org/html/rfc2119
Aber nach ein paar Benchmarks war mir schnell klar, dass es für einem Kunden mit langsamen und gestörten Internet einen erheblichen Unterschied ausmachen würde.
Test Setup
Wie testen wir überhaupt ein Szenario mit einem langsamen und gestörten Internet?
Gestörtes Netzwerk
Mit dem Tool clumsy kann man auf einem Windows Rechner sehr einfach ein gestörtes Netzwerk simulieren.
Folgende Parameter sind möglich:
- Lag, hold the packets for a short period of time to emulate network lagging.
- Drop, randomly discard packets.
- Throttle, block traffic for a given time frame, then send them in a single batch.
- Duplicate, send cloned packets right after to the original one.
- Out of order, re-arrange the order of packets.
- Tamper, nudge bits of packet’s content.
Ich habe folgendes Setup gewählt:
Langsames Netzwerk
Mit dem Web Debugging Proxy Fiddler kann man recht einfach den Proxy auf Modem-Speed runterschrauben. D.h. jedoch, dass die Anwendung zum Testen seinen Datenverkehr über diesen Proxy senden muss.
Benchmarks
Durch die Wiederverwendung vom transport konnte im Labor eine Performance-Steigerung von bis zum Faktor 10 erreicht werden.
Mit schlechten und gestörten Internet konnte sogar eine Performance-Steigerung bis zum Faktor 80 erreicht werden.
Labor
Mit schlechten und gestörten Internet
RTFM
Dieses Beispiel zeigt mal wieder, wie wichtig das Lesen der Dokumentation sein kann.