Docs
Golang
Performance

Performance e ottimizzazione in Go: guida completa 🏎️

Ottimizzare le performance in Go significa lavorare su più fronti: memoria, concorrenza, strutture dati, profiling e scelte architetturali. Questa guida unisce best practice, esempi pratici e consigli tratti da esperienze reali.

Gestione della memoria 🧠**

Stack vs Heap

Ottimizzare la gestione della memoria in Go significa innanzitutto comprendere dove vengono allocate le variabili. Le variabili locali restano nello stack, che è molto veloce, mentre quelle che “scappano” dallo scope finiscono sull’heap, più lento e gestito dal garbage collector. Per capire dove finiscono le tue variabili, puoi usare l’escape analysis:

1

go build -gcflags=-m main.go

Ad esempio:

1
2
3
4

func newInt() *int {
    x := 42
    return &x // x viene allocata sull'heap perché "scappa" dalla funzione
}

Quando possibile, restituisci valori invece di puntatori per evitare allocazioni inutili sull’heap.

Allineamento delle struct

L’allineamento delle struct in Go è un aspetto spesso trascurato ma fondamentale per ottenere il massimo delle performance, soprattutto in programmi che fanno uso intensivo di strutture dati o che gestiscono grandi quantità di oggetti in memoria.

Quando il compilatore alloca una struct, inserisce del padding tra i campi per rispettare i requisiti di allineamento della CPU. Questo padding serve a garantire che ogni campo sia posizionato in memoria in modo efficiente per l’accesso da parte del processore, ma può portare a uno spreco di memoria se i campi non sono ordinati correttamente.

Regola pratica: ordina i campi dal più grande al più piccolo (in termini di byte). In questo modo riduci il padding e migliori la locality della cache, rendendo più veloce l’accesso ai dati.

La cache locality indica quanto bene i dati utilizzati dal programma sono raggruppati in memoria. Quando i campi di una struct sono allineati e ordinati correttamente, il processore può caricare più dati utili in un singolo accesso alla cache, riducendo i tempi di attesa. Una buona cache locality migliora le performance perché minimizza i cache miss, cioè le situazioni in cui la CPU deve recuperare dati dalla RAM invece che dalla cache, molto più lenta. In sintesi: strutture dati ben allineate e compatte sfruttano meglio la cache della CPU, rendendo il programma più veloce.

Esempio di struct ottimizzata:

1
2
3
4
5
6

type Ottimizzata struct {
    Numero   int64   // 8 byte
    Flag     bool    // 1 byte
    Piccolo  byte    // 1 byte
    // 6 byte di padding aggiunti dal compilatore
}

Se inverti l’ordine dei campi, il padding può aumentare:

1
2
3
4
5
6

type NonOttimizzata struct {
    Flag     bool    // 1 byte
    Piccolo  byte    // 1 byte
    // 6 byte di padding tra Piccolo e Numero
    Numero   int64   // 8 byte
}

Per verificare la dimensione effettiva di una struct e il padding introdotto, puoi usare il pacchetto unsafe:

1
2

fmt.Println(unsafe.Sizeof(Ottimizzata{}))
fmt.Println(unsafe.Sizeof(NonOttimizzata{}))

Suggerimenti aggiuntivi:

  • Se hai molti booleani o byte, valuta l’uso di array o bitfield per risparmiare memoria.
  • L’allineamento è particolarmente importante nelle strutture usate in slice o map di grandi dimensioni.
  • In ambienti a 64 bit, i tipi come int64 e float64 dovrebbero sempre venire prima dei tipi più piccoli.

Un buon allineamento non solo riduce l’uso di memoria, ma può anche migliorare sensibilmente le performance grazie a un accesso più efficiente alla cache della CPU.

Evitare copie inutili

In Go, evitare copie inutili di dati è fondamentale per ottenere applicazioni efficienti sia in termini di memoria che di velocità. Le slice sono reference type: quando le passi a una funzione, non viene copiata l’intera sequenza di dati, ma solo un piccolo header che punta ai dati sottostanti. Questo rende le slice molto leggere da passare e restituire.

Tuttavia, ci sono situazioni in cui potresti inavvertitamente causare copie costose:

  • Restituire grandi struct per valore: se una funzione restituisce una struct di grandi dimensioni per valore, Go ne farà una copia. Preferisci l’uso di puntatori per struct molto grandi o contenenti array di grandi dimensioni.
  • Modificare slice senza attenzione: alcune operazioni sulle slice, come l’uso di append su una slice condivisa, possono causare la creazione di una nuova copia dei dati se la capacità viene superata. Se più goroutine o funzioni lavorano sulla stessa slice, valuta se è necessario copiarla esplicitamente per evitare effetti collaterali.
  • Conversione tra tipi: la conversione tra stringa e slice di byte ([]byte(s)) crea sempre una copia dei dati. Se devi solo leggere, lavora direttamente con la slice o la stringa originale.
1
2
3

func process(data []int) {
    // lavora direttamente sulla slice
}

Esempio pratico: differenza tra copia e riferimento

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

// Passaggio efficiente di slice: nessuna copia dei dati sottostanti
func somma(data []int) int {
    totale := 0
    for _, v := range data {
        totale += v
    }
    return totale
}

// Attenzione: restituire una struct grande per valore comporta una copia
func creaGrande() GrandeStruct {
    var g GrandeStruct
    // ...riempi g...
    return g // qui viene fatta una copia di tutta la struct
}

type GrandeStruct struct {
    dati [1024]int
}

// Uso corretto: restituisci un puntatore per evitare la copia
func creaGrandePtr() *GrandeStruct {
    var g GrandeStruct
    // ...riempi g...
    return &g // solo il puntatore viene copiato
}

// Conversione che crea copia
s := "test string"
b := []byte(s) // copia i dati della stringa

// Slicing efficiente: nessuna copia dei dati
sub := b[2:6]

Scegliere la struttura dati giusta

La scelta tra slice, map e array dipende dalle esigenze di accesso e modifica dei dati. Le slice sono flessibili e leggere, le map permettono accesso rapido per chiave, gli array sono utili per dati di dimensione fissa.

1
2

var numeri = []int{1,2,3}
var mappa = map[string]int{"a": 1}

Attenzione alle allocazioni e alle copie: preferisci passare slice e map per riferimento.

Evitare interface{} inutili

L’uso eccessivo di interface{} in Go può portare a inefficienze, perché ogni valore passato a una variabile di tipo interface{} viene “boxed”: se il valore non è già un tipo di interfaccia, viene allocato sull’heap, con un impatto negativo sulle performance e sulla prevedibilità della memoria. Inoltre, l’uso di interface{} riduce la sicurezza dei tipi e rende il codice meno leggibile e più soggetto a errori di runtime.

Preferisci sempre tipi concreti o interfacce specifiche, solo quando serve davvero l’astrazione. Ad esempio, invece di:

1

var x interface{} = 42 // può causare allocazione sull'heap

usa direttamente il tipo concreto:

1

var x int = 42 // nessuna allocazione extra

Quando usare interface{}:

  • Solo se devi gestire dati eterogenei o scrivere funzioni generiche che non possono essere espresse con i generics di Go 1.18+.
  • Se lavori con API che richiedono davvero flessibilità di tipo, ma valuta sempre se puoi restringere l’interfaccia.

Con Go moderno, preferisci i generics per funzioni e strutture dati riutilizzabili, evitando l’overhead e la perdita di sicurezza di interface{}.

Object pooling e preallocazione

Per ridurre le allocazioni e migliorare le performance, sfrutta due strategie:

  • Preallocazione: Quando conosci la dimensione massima di una slice o di una struttura dati, prealloca la capacità per evitare riallocazioni e copie durante la crescita.
1

numeri := make([]int, 0, 100) // preallocazione efficiente
  • Object pooling: Se il programma crea e distrugge frequentemente oggetti temporanei (buffer, slice grandi, strutture di breve durata), usa un pool per riutilizzarli e ridurre la pressione sul garbage collector. In Go, il tipo sync.Pool è pensato per questo scopo.

Esempio di utilizzo di un pool per buffer temporanei:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

var bufPool = sync.Pool{
    New: func() interface{} {
        return new(bytes.Buffer)
    },
}

// Ottieni un buffer dal pool
buf := bufPool.Get().(*bytes.Buffer)
buf.Reset() // sempre azzerare prima dell'uso

// ...usa buf...

// Restituisci il buffer al pool
bufPool.Put(buf)

Best practice:

  • Prealloca sempre slice e map quando conosci la dimensione attesa.
  • Usa il pooling solo per oggetti temporanei e costosi da creare, non per il caching persistente.
  • Ricorda di azzerare lo stato degli oggetti prima di rimetterli nel pool.
  • Con i generics di Go, puoi creare pool tipizzati per maggiore sicurezza e performance.

Queste tecniche aiutano a ridurre le allocazioni, migliorare la prevedibilità delle performance e alleggerire il lavoro del garbage collector, soprattutto in applicazioni ad alto carico o con molti oggetti temporanei.

Concorrenza e goroutine 🚦

Goroutine: leggere ma non gratis

Le goroutine sono uno dei punti di forza di Go: leggere, facili da creare e gestite dal runtime in modo efficiente. Ogni goroutine parte con uno stack molto piccolo (circa 2KB) che cresce dinamicamente, permettendo di avviare migliaia o milioni di goroutine senza saturare subito la memoria.

Tuttavia, “leggere” non significa “gratuite”. Ogni goroutine consuma memoria (stack, metadati) e risorse di scheduling. Se ne crei troppe senza controllo, puoi comunque esaurire la RAM o introdurre overhead di contesto eccessivo. Inoltre, goroutine che non terminano (leak) o che restano bloccate possono causare problemi difficili da diagnosticare.

Best practice per l’uso delle goroutine:

  • Crea solo le goroutine che servono davvero: valuta se puoi usare worker pool o pipeline invece di una goroutine per ogni task.
  • Assicurati che ogni goroutine abbia un ciclo di vita chiaro e che possa terminare: usa channel di segnalazione (done, context.Context) per gestire la chiusura.
  • Evita di lanciare goroutine in loop senza limiti o in risposta a input non controllati.
  • Monitora periodicamente il numero di goroutine attive con runtime.NumGoroutine() per individuare leak o anomalie.

Esempio di gestione corretta del ciclo di vita di una goroutine:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

func worker(jobs <-chan int, done <-chan struct{}) {
    for {
        select {
        case job, ok := <-jobs:
            if !ok {
                return // channel chiuso, termina la goroutine
            }
            // processa il job
        case <-done:
            return // segnale di terminazione
        }
    }
}

// Avvio e chiusura controllata
jobs := make(chan int)
done := make(chan struct{})
go worker(jobs, done)
// ...
close(done) // segnala la chiusura

Ricorda: le goroutine sono uno strumento potente, ma vanno gestite con disciplina per evitare sprechi di memoria, leak e difficoltà di debugging.

Worker pool

Per microservizi ad alto carico, il pattern worker pool permette di gestire molte richieste in parallelo senza saturare la memoria e limitando la concorrenza. Invece di creare una goroutine per ogni task, si avviano un numero fisso di worker che processano i job da una coda condivisa. Questo approccio previene l’esaurimento delle risorse e migliora la stabilità del sistema.

Esempio pratico:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

func WorkerPool(tasks []Task, numWorkers int) []Result {
    results := make([]Result, len(tasks))
    jobs := make(chan int, len(tasks))
    var wg sync.WaitGroup
    for w := 0; w < numWorkers; w++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            for j := range jobs {
                results[j] = executeTask(tasks[j])
            }
        }()
    }
    for j := range tasks {
        jobs <- j
    }
    close(jobs)
    wg.Wait()
    return results
}

Best practice: Meglio poche goroutine che lavorano su tanti job, invece di una per ogni richiesta. Usa worker pool per controllare la concorrenza e ottimizzare l’uso della memoria.

Channel e sincronizzazione

I channel sono il cuore della concorrenza in Go: permettono di comunicare e sincronizzare le goroutine in modo sicuro e idiomatico, senza dover ricorrere sempre a mutex o variabili condivise. Un channel è una coda thread-safe che consente di inviare e ricevere valori tra goroutine, garantendo che i dati siano trasferiti in modo ordinato e senza race condition.

Principi chiave nell’uso dei channel:

  • Usa i channel per coordinare il flusso di lavoro tra goroutine, ad esempio per distribuire task a worker o raccogliere risultati.
  • Chiudi sempre i channel quando non servono più: la chiusura segnala ai riceventi che non arriveranno altri dati, evitando deadlock e goroutine bloccate.
  • Preferisci channel buffered quando vuoi decouplare produttore e consumatore, ma attenzione a non usarli come code infinite: un buffer troppo grande può mascherare problemi di sincronizzazione.
  • Per la sincronizzazione “one-shot” (es. segnalare la fine di un lavoro), usa channel di tipo chan struct{} o context.Context.

Esempio di pattern produttore/consumatore con chiusura corretta del channel:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

jobs := make(chan int)
results := make(chan int)

// Worker
go func() {
    for job := range jobs {
        results <- job * 2
    }
}()

// Produttore
for i := 0; i < 5; i++ {
    jobs <- i
}
close(jobs) // fondamentale: segnala la fine dei job

// Consumatore
for r := range results {
    fmt.Println(r)
    // ...
    // chiudi results quando hai finito, se necessario
}

Sincronizzazione avanzata:

  • Usa sync.WaitGroup per attendere la fine di più goroutine.
  • Usa sync.Mutex o sync.RWMutex solo quando serve proteggere dati condivisi che non possono essere gestiti tramite channel.
  • Le operazioni atomiche (sync/atomic) sono utili per contatori e flag, ma non sostituiscono la sincronizzazione strutturata dei channel.

Best practice:

  • Progetta il flusso dei dati in modo che ogni channel abbia un solo mittente responsabile della chiusura.
  • Evita di chiudere un channel da più goroutine: può causare panic.
  • Preferisci dati immutabili o strutture “passate per valore” nei channel, per evitare race condition.

In sintesi, i channel rendono la concorrenza in Go più sicura e leggibile, ma vanno usati con attenzione: una buona progettazione del flusso dei dati e la chiusura corretta dei channel sono fondamentali per evitare deadlock, leak e bug difficili da tracciare.

Profiling e benchmarking 📏

Profiling: misura prima di ottimizzare

Prima di ottimizzare il codice Go, è fondamentale misurare dove si trovano i veri colli di bottiglia: CPU, memoria e concorrenza. Go offre strumenti integrati per il profiling di CPU, memoria, goroutine, blocchi e tracing, che permettono di individuare e analizzare le aree critiche dell’applicazione.

Profiling di CPU e memoria

Per raccogliere e analizzare i profili, integra il pacchetto net/http/pprof e avvia un server HTTP di debug:

1
2
3
4
5
6
7
8
9

import _ "net/http/pprof"
import "net/http"

func main() {
    go func() {
        http.ListenAndServe("localhost:6060", nil)
    }()
    // ... resto dell'app
}

Avvia l’applicazione e raccogli i profili con:

1
2
3
4
5
6

curl http://localhost:6060/debug/pprof/heap > heap.out
curl http://localhost:6060/debug/pprof/profile > cpu.out

go tool pprof -http=:8080 heap.out
# oppure
# go tool pprof -http=:8080 cpu.out

Questi strumenti permettono di individuare le funzioni che consumano più memoria o CPU, visualizzare flame graph e analizzare le allocazioni. Il profiling della memoria aiuta a rilevare leak e ottimizzare l’uso delle risorse.

Profiling della concorrenza

Oltre a CPU e memoria, puoi profilare la concorrenza per individuare deadlock, leak di goroutine e blocchi:

  • Profilo goroutine: quante goroutine sono attive e dove si trovano nel codice.
  • Profilo dei blocchi (block): mostra dove le goroutine restano bloccate su operazioni di sincronizzazione.
  • Profilo dei thread (threadcreate): utile per capire se il runtime crea troppi thread OS.

Raccogli i profili:

1
2
3
4
5
6

curl http://localhost:6060/debug/pprof/goroutine > goroutine.out
curl http://localhost:6060/debug/pprof/block > block.out

go tool pprof -http=:8080 goroutine.out
# oppure
# go tool pprof -http=:8080 block.out

Nell’interfaccia web di pprof puoi esplorare stack trace, funzioni bloccanti e visualizzazioni grafiche per individuare rapidamente i punti critici.

Consigli pratici per il profiling

  • Esegui il profiling in ambienti che riproducono il carico reale di produzione.
  • Analizza sia le allocazioni totali che quelle temporanee.
  • Usa i comandi top, list e web di pprof per approfondire le funzioni più costose.
  • Se noti leak di memoria, cerca goroutine bloccate o strutture dati che crescono senza limiti.
  • Analizza il profilo dei blocchi per individuare mutex o canali che causano rallentamenti.

Il profiling dovrebbe essere parte integrante del ciclo di sviluppo: solo così puoi garantire applicazioni Go efficienti e scalabili.

Benchmark

Scrivi test di benchmark per confrontare le performance prima e dopo le ottimizzazioni. Un benchmark in Go ha questa forma:

1
2
3
4
5

func BenchmarkSomma(b *testing.B) {
    for i := 0; i < b.N; i++ {
        _ = 1 + 2
    }
}

Esegui i benchmark con:

1

go test -bench=.

Tracing

Il tracing in Go permette di analizzare in profondità la latenza, la concorrenza e il flusso delle chiamate all’interno dell’applicazione. A differenza del semplice profiling, il tracing fornisce una visione temporale dettagliata degli eventi: puoi vedere quando vengono avviate e terminate le goroutine, come si propagano i context, dove avvengono le attese su channel, lock e I/O.

Per generare e analizzare un trace:

1

go test -trace trace.out

Questo comando esegue i test e registra un file di trace. Puoi poi esplorarlo con:

1

go tool trace trace.out

Si aprirà un’interfaccia web interattiva che mostra:

  • La timeline delle goroutine e degli eventi di sistema
  • I periodi di attesa su lock, channel e I/O
  • Le regioni di codice più lente o congestionate
  • Le relazioni tra eventi concorrenti

Quando usare il tracing:

  • Per individuare colli di bottiglia dovuti a sincronizzazione, lock o attese su I/O
  • Per analizzare la latenza end-to-end di una richiesta
  • Per capire la sequenza e la durata delle operazioni concorrenti

Consigli pratici:

  • Esegui il tracing sotto carico realistico per ottenere dati significativi
  • Combina tracing e profiling per una diagnosi completa delle performance
  • Usa le annotazioni custom (runtime/trace) per marcare sezioni di codice critiche

Il tracing è uno strumento avanzato ma potentissimo: usalo per risolvere problemi di latenza, concorrenza e per ottimizzare il flusso delle tue applicazioni Go.

Ottimizzazioni di rete per microservizi Go

Comprendere Latency e Throughput

Prima di addentrarsi nelle ottimizzazioni, è fondamentale capire cosa stiamo cercando di migliorare:

  • Latency (Latenza): il tempo necessario per processare una singola richiesta (misurato in ms o μs).
  • Throughput (Capacità): il numero di richieste che possono essere processate in un determinato periodo di tempo (misurato in richieste al secondo).

Queste metriche sono spesso in relazione complessa: ottimizzare una può talvolta impattare negativamente sull’altra. L’obiettivo è trovare il giusto equilibrio in base al caso d’uso specifico.

Latency = Tempo di risposta per richiesta Throughput = Richieste processate al secondo

Ad esempio, un servizio può avere una bassa latenza ma un throughput limitato, oppure gestire molte richieste al secondo ma con tempi di risposta più alti. La scelta delle ottimizzazioni dipende dal tipo di carico e dai requisiti dell’applicazione.

Ottimizzazione delle connessioni HTTP

Le connessioni HTTP sono spesso il collo di bottiglia nei microservizi, soprattutto quando si effettuano molte chiamate tra servizi o verso API esterne. Un uso corretto del connection pooling e dei timeout permette di ridurre la latenza, evitare la creazione eccessiva di connessioni e migliorare la gestione delle risorse.

1
2
3
4
5
6
7
8

var httpClient = &http.Client{
    Transport: &http.Transport{
        MaxIdleConns:        100,
        MaxIdleConnsPerHost: 100,
        IdleConnTimeout:     90 * time.Second,
    },
    Timeout: 10 * time.Second,
}

Ottimizzazione delle connessioni database

Le connessioni al database sono risorse costose e limitate. Un corretto dimensionamento dei pool di connessioni e la gestione della loro durata sono essenziali per evitare colli di bottiglia, saturazione delle risorse e rallentamenti nelle query. Configurare i parametri del pool aiuta a mantenere le performance costanti anche sotto carico elevato.

1
2
3

db.SetMaxOpenConns(25)
db.SetMaxIdleConns(25)
db.SetConnMaxLifetime(5 * time.Minute)
  • Batch processing: Esegui operazioni batch per ridurre i round-trip verso il database:
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

func BatchInsert(users []User) error {
    query := "INSERT INTO users(id, name, email) VALUES "
    vals := []interface{}{}
    for i, user := range users {
        query += fmt.Sprintf("($%d, $%d, $%d),", i*3+1, i*3+2, i*3+3)
        vals = append(vals, user.ID, user.Name, user.Email)
    }
    query = query[:len(query)-1] // rimuove la virgola finale
    _, err := db.Exec(query, vals...)
    return err
}

Pattern e anti-pattern

Operazioni atomiche e lazy initialization

Sincronizza solo quando necessario. Usa sync.Once per inizializzazioni sicure e operazioni atomiche per contatori e flag:

1
2
3
4

var once sync.Once
once.Do(func() {
    // inizializzazione
})

Gestione degli errori e best practice

Evita errori comuni come ignorare gli errori, uso eccessivo di cgo, variabili globali, puntatori inutili e riferimenti circolari. Gestisci sempre gli errori in modo esplicito:

1
2
3
4
5

f, err := os.Open("file.txt")
if err != nil {
    log.Fatal(err)
}
defer f.Close()

Gestione dei riferimenti circolari

I riferimenti circolari tra strutture dati possono impedire al garbage collector di liberare memoria, causando memory leak. In Go, presta attenzione a strutture che si referenziano a vicenda (es. nodi di una lista doppiamente collegata, grafi, ecc.). Se necessario, usa puntatori deboli o tecniche di disaccoppiamento per evitare cicli di riferimento non necessari.

Ottimizzare Go è come giocare a tetris: ogni pezzo al posto giusto fa la differenza tra un programma snello e uno… traballante!

Ottimizzazioni avanzate per microservizi Go

Multi-level cache con Redis

Usa una cache in memoria (es. Ristretto) come primo livello e Redis come secondo livello distribuito. Questo riduce la latenza e scarica Redis da richieste ripetitive.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

type MultiLevelCache struct {
    local  *ristretto.Cache
    redis  *redis.Client
}

func (c *MultiLevelCache) Get(key string, value interface{}) (bool, error) {
    if val, found := c.local.Get(key); found {
        err := json.Unmarshal(val.([]byte), value)
        return true, err
    }
    val, err := c.redis.Get(context.Background(), key).Bytes()
    if err == nil {
        err = json.Unmarshal(val, value)
        if err == nil {
            c.local.SetWithTTL(key, val, 1, time.Minute)
        }
        return true, err
    }
    return false, err
}

Cache client-side di Redis: Redis supporta una modalità di caching client-side che permette ai client di mantenere una cache locale sincronizzata con il server Redis. Questo approccio consente di ridurre ulteriormente la latenza e il carico sul server Redis, specialmente in scenari con molti client o richieste ripetitive sugli stessi dati. Per maggiori dettagli: Redis Client Side Caching.

Rate limit TCP con Redis

Redis può essere usato per implementare rate limiter e lock distribuiti tra microservizi.

Un approccio avanzato consiste nell’applicare il rate limit a livello di connessioni TCP, bloccando le richieste prima che vengano parse dall’handler HTTP. In questo modo si riduce il carico sul server, evitando di processare e parsare richieste che sarebbero comunque rifiutate. Questo è particolarmente utile in microservizi ad alto traffico o in presenza di attacchi DoS.

Esempio di rate limit TCP con Redis:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

// Esempio: rate limit TCP a livello di connessione, prima del parsing HTTP
// Usa Redis per tenere traccia dei tentativi per IP
import (
    "net"
    "time"
    "github.com/go-redis/redis/v8"
    "context"
    "strconv"
)

var rdb = redis.NewClient(&redis.Options{
    Addr: "localhost:6379",
})

const (
    maxConnPerMinute = 10
)

func tcpRateLimitListener(addr string) error {
    ln, err := net.Listen("tcp", addr)
    if err != nil {
        return err
    }
    defer ln.Close()
    for {
        conn, err := ln.Accept()
        if err != nil {
            continue
        }
        go func(c net.Conn) {
            remoteIP, _, _ := net.SplitHostPort(c.RemoteAddr().String())
            allowed, _ := checkRateLimit(remoteIP)
            if !allowed {
                c.Close() // chiudi subito la connessione
                return
            }
            // ...passa la connessione al server HTTP o altro handler...
        }(conn)
    }
}

func checkRateLimit(ip string) (bool, error) {
    ctx := context.Background()
    key := "tcp:ratelimit:" + ip
    count, err := rdb.Incr(ctx, key).Result()
    if err != nil {
        return false, err
    }
    if count == 1 {
        rdb.Expire(ctx, key, time.Minute)
    }
    return count <= maxConnPerMinute, nil
}

In questo esempio, ogni nuova connessione TCP viene controllata tramite Redis: se il numero di connessioni da un certo IP supera la soglia prefissata nel minuto corrente, la connessione viene chiusa immediatamente, senza passare dallo stack HTTP.

Monitoraggio, profiling e best practice

  • Telemetry e metriche: Integra metriche dettagliate (es. Prometheus) per monitorare latenza, throughput, errori e risorse.
  • Profiling continuo: Usa strumenti come pprof e benchmark automatizzati per individuare colli di bottiglia e misurare l’impatto delle ottimizzazioni.
  • Evita ottimizzazioni premature: Misura sempre prima e dopo ogni cambiamento.
  • Scalabilità e resilienza: Considera Redis Sentinel/Cluster per alta disponibilità e configura le policy di memoria/eviction in base alle esigenze.

Nota: Redis non è solo cache: può essere usato per rate limiting, session management, locking distribuito, Pub/Sub e job queue.

Risorse utili

Ultimo aggiornamento il