Leitfaden zur Leistungsoptimierung von Go-Anwendungen

Leitfaden zur Leistungsoptimierung von Go-Anwendungen

• Sammlung technischer Materialien für die Entwicklung hochperformanter Go-Anwendungen
• Bietet praxisnahe Muster, Beispiele und Low-Level-Performance-Einblicke für Engineers, die hochperformante APIs, Microservices und verteilte Systeme entwickeln
• Go bietet zwar nicht so viele Performance-Tuning-Optionen wie C++ oder Rust, eröffnet aber dennoch viele Optimierungsmöglichkeiten, etwa durch Speicherwiederverwendung, Kontrolle von Allokationen sowie effiziente Netzwerk- und Nebenläufigkeitsverarbeitung
• Dieser Leitfaden konzentriert sich auf messbare Techniken zur Leistungssteigerung und behandelt Themen von zentralen Sprachfunktionen bis hin zu fortgeschrittenen Netzwerkstrategien

Bisher behandelte Inhalte

Gängige Go-Performance-Muster

• Der erste Beitrag fasst zentrale Performance-Muster zusammen, die alle Go-Entwickler kennen sollten
• Wichtige Themen:
  • effektive Nutzung von sync.Pool
  • Vermeidung unnötiger Speicherallokationen
  • Optimierung von Struct-Layouts und Speicher-Alignment
  • effiziente Fehlerbehandlung
  • Zero-Cost-Abstraktion über Interfaces
  • Techniken zur Wiederverwendung von Slices und zum In-Place-Sorting
• Basierend auf Praxisbeispielen, inklusive Benchmarks und kopierbarer Codebeispiele

Kommende Inhalte

Hochperformantes Networking in Go

• Geplant ist eine detaillierte Analyse zum Aufbau hochperformanter Netzwerkdienste mit der Standardbibliothek und externen Bibliotheken
• Behandelte Themen:
  • effiziente Nutzung von net/http und net.Conn
  • Umgang mit einer großen Zahl gleichzeitiger Verbindungen
  • Performance-Tuning mit epoll/kqueue, GOMAXPROCS usw.
  • Techniken für Lasttests und Bottleneck-Diagnose
  • Wann Low-Level-Netzwerkbibliotheken wie fasthttp sinnvoll sind und wie sich das mit Wartbarkeit ausbalancieren lässt

Zielgruppe

• Backend-Engineers, die Go-Services in der Produktion optimieren
• Entwickler, die an latenzsensitiven Systemen arbeiten
• Teams, die auf Go migrieren oder hochperformante Pfade aufbauen
• Entwickler, die sich für das Performance-Modell und die Trade-offs von Go interessieren

[GN⁺]

Hacker-News-Kommentare

• Beim ersten Beispiel mit dem Objekt-Pool überrascht, dass das ohne Warnung möglich ist

  • Diese API existierte schon vor den Generics und verwendet daher any
  • Golang hat prinzipiell zwar ein starkes Typsystem, aber in der Praxis gibt es viele APIs, die das Typsystem umgehen
  • Das wirft die Frage auf, wie nützlich das Typsystem wirklich ist
  • Bemerkenswert ist auch, dass es keine API gibt, um Werte auf initialisierte Standardwerte zurückzusetzen

• Der Performance-Guide empfiehlt, Allokationen zu minimieren, um die GC-Zeit zu reduzieren

  • Die GC-Markierungsphase kostet Zeit, und es ist besser, langlebige Allokationen zu vermeiden
  • Kurzlebige Allokationen haben fast keinen Einfluss auf die GC-Zeit
  • In realen Apps ist es fast unmöglich, GC zu vermeiden; effektiver ist es, die GC-Markierungszeit zu verringern

• Zusätzlich ...

  • Go-Optimierungsleitfaden
  • Uber Go Guide
  • Wenn man über sechs Monate hinweg zwischen Projekten in mehreren Sprachen wechselt, ist es schwer, sich die wichtigen Dinge zu merken

• Zero-Copy wird unterschätzt

  • Gos Interfaces eignen sich gut zum Schreiben von Zero-Copy-Code, aber man muss vorsichtig sein
  • Oft merkt man, wie viel Zeit für Speicherallokation und Datenbewegung draufgeht

• GOMEMLIMIT hat mehrfach geholfen

  • Nützlich in containerisierter Produktion und hat im CI Probleme mit Speichermangel gelöst
  • Durch den Wechsel zu nogo wurden die Probleme mit golangci-lint behoben

• Neugier auf Projekte, die Optimierung brauchen

  • Z. B. die Ausrichtung von Struct-Feldern

• Beim Lesen der Dokumentation zum Objekt-Pooling kam die Frage auf, ob es Pläne gibt, Pakete wie sync generisch zu machen

• Überrascht, dass Golang C bei der Struct-Ausrichtung ähnelt

• "Struct Data enthält ein Array [1024]int, das 4 KB groß ist"

  • Fraglich, ob überhaupt jemand standardmäßig eine 32-Bit-Architektur verwendet

• Mit sync.Pool kann man sich selbst täuschen

  • pprof sieht in Benchmarks gut aus, weil es keine Allokationen gibt, aber der tatsächliche Speicherverbrauch steigt
  • Wichtig ist, die Vorteile unter realen Bedingungen zu messen