DEV Community: Igor Melo

Go 1.22 e o novo router HTTP

Igor Melo — Wed, 07 Feb 2024 00:50:47 +0000

Introdução

O http.ServeMux do Go ganhou novas features muito aguardadas pelos desenvolvedores, e como sempre, essas features são retrocompatíveis.

Em resumo, as features são:

Match com base no método HTTP

http.Handle("GET /users", ...)

Variavéis no path da requisição

http.Handle("GET /users/{id}", ...)

Match exato de paths terminados em barra

// match para qualquer path iniciado com /static/
http.Handle("GET /static/", ...)

// match somente GET /static/
http.Handle("GET /static/{$}", ...)

Essas mudanças vão reduzir bastante a necessidade de utilizar bibliotecas de routers, e como vai para a stdlib, vai ter a garantia de compatibilidade do Go 1.

1. Como funciona o `http.ServeMux`

O ServeMux tem um comportamento diferente da maioria dos routers.

Caminhos terminados em barra são como pastas

http.Handle("/assets/", ...)

Esse handler processa qualquer requisição com prefixo /assets/, como:

GET /assets/
GET /assets/img/img.png
DELETE /assets/abcd

O match é feito com o path exato se não for terminado em barra

http.Handle("/", ...)
http.Handle("/assets", ...)

Nesse caso o segundo pattern não termina em barra, então só requisições para exatamente /assets vão ser processadas por esse handler, e qualquer outra será processada pelo primeiro handler.

Obs.: O caminho / dá match em qualquer requisição que não dê match em outro handler, então ele é geralmente usado para a página raiz e página de not found.

O match é feito com o path mais similar

Se você tiver:

http.Handle("/users/", ...)
http.Handle("/users/123", ...)
http.Handle("/users/books/", ...)

Uma requisição para /users/ vai cair no primeiro handler.
Uma requisição para /users/123 vai cair no segundo handler.
Uma requisição para /users/1234 vai cair no primeiro handler.
Uma requisição para /users/books/123 vai cair no terceiro handler.
Uma requisição para /users/a/b/c/d também cai no primeiro handler

2. Entendendo o match com base no método HTTP

O comportamento das funções Handle e HandleFunc vai se manter igual para códigos existentes por conta da retrocompatibilidade da linguagem, então se você não especificar um método HTTP, seu handler vai continuar dando match em qualquer método.

Obs.: Um handler para o método GET vai também bater para requisições do método HEAD.

// GET /users
// HEAD /users
http.HandleFunc("GET /users", ...)


// somente DELETE /users
http.HandleFunc("DELETE /users", ...)

3. Utilizando variáveis de path

Podemos capturar o valor de uma variável de path usando o PathValue.

http.HandleFunc("GET /users/{id}", func(w http.ResponseWriter, r *http.Request) {
    id := r.PathValue("id")
    ...
})

4. Utilizando matches exatos

Ao utilizar o {$} indicamos que um handler terminado em barra deve somente bater com aquele path, e não com qualquer path com aquele prefixo.

// redirecionar um request de / para /home
http.HandleFunc("GET /{$}", func(w http.ResponseWriter, r *http.Request) {
    http.Redirect(w, r, "/home")
})

// qualquer outro path que não de match em outro handler vai dar um not found
http.HandleFunc("GET /", func(w http.ResponseWriter, r *http.Request) {
    http.NotFound(w, r)
})

Conclusão

Apesar de simples, essa foi uma mudança bem importante na stdlib do Go, tendo em vista que é uma linguagem muito utilizada para desenvolver servidores Web.

Mas é claro que essas foram só algumas das muitas novidades do Go 1.22 e pretendo falar de outras que foram bem expressivas, como no for loop, pacote rand, e outros em próximos artigos.

Go: Criando um cache em memória com map, mutex e generics

Igor Melo — Sun, 03 Dec 2023 19:17:53 +0000

1. Introdução

Nesse artigo vamos desenvolver um cache chave-valor na memória do processo para aprender sobre data races, Mutex, RWMutex e generics no Go.
No final vamos fazer comparações de performance para vermos qual é a solução mais eficiente.

2. Por que não usar simplesmente um `map`?

Podemos usar um map de cache da seguinte forma:

var cache = map[string]string{}

...

// tentando pegar o valor do  cache
val, ok := cache["api_lenta/info"]

// valor nao esta no cache, tenho que pegar da API
if !ok {
    val = consultarAPILenta()

    // guardando o valor no cache para o proximo uso
    cache["api_lenta/info"] = val
}

// usando o valor, vindo do cache ou da api
usarValor(val)

A princípio não tem problema nessa abordagem, porque o cache está sendo usado por uma só goroutine.
O problema começa quando adicionamos múltiplas goroutines...
Vamos falar de data races.

3. O que são data races?

Um data race ocorre quando duas ou mais goroutines tentam concorrentemente ler e/ou alterar um dado.

count := 0
for i := 0; i < 1000; i++ {
    go func() {
        count = count + 1
    }()
}

time.Sleep(time.Second)
fmt.Println(count)

No exemplo acima eu crio mil goroutines para incrementar o valor de count.
Só que eventualmente algumas goroutines vão rodar em paralelo e vão ler e alterar o valor de count ao mesmo tempo.

E mesmo que não rodem em paralelo, o scheduler pode interromper a goroutine no meio da execução dela, antes dela atualizar o valor na memória, e resumir tempo depois, fazendo com que o count que ela calculou esteja desatualizado.

Quando isso acontece, não há como determinar qual vai ser o resultado da operação. Tanto que se eu rodar esse programa múltiplas vezes, vou ter resultados diferentes:

$ go run main.go 
904
$ go run main.go
903
$ go run main.go
958
$ go run main.go
926
$ go run main.go
975

Regra geral sobre data races

Basicamente podemos pensar da seguinte forma:

Acontece data race quando

Duas ou mais goroutines estão alterando um mesmo valor
Uma ou mais goroutines estão lendo um valor, enquanto uma goroutine está alterando

Não acontece data race quando

Só há uma goroutine lidando com um dado (lendo ou escrevendo)
Há múltiplas goroutines lendo um dado (e nenhuma escrevendo)

Em tipos mais complexos, como é o caso do map, um data race bagunçaria totalmente a estrutura interna dele, então quando ele detecta um data race ele dá um panic com uma das seguintes mensagens:

fatal error: concurrent map writes

fatal error: concurrent map read and map write

Race detector

Felizmente o Go vem com uma ferramenta chamada data race detector que, como o nome sugere, detecta data races de forma geral e nos diz exatamente as linhas que estão causando o race.

Para usar o race detector, basta utilizar -race nos principais comandos do Go:

go test -race ./...
go run -race arquivo.go
go build -race .

Se usarmos o race detector no programa que deveria contar até 1000, ele vai detectar o race e mostrar a seguinte mensagem:

$ go run -race main.go 
==================
WARNING: DATA RACE
Read at 0x00c000026178 by goroutine 11:
  main.main.func1()
      /projeto/main.go:7 +0x30

Previous write at 0x00c000026178 by goroutine 7:
  main.main.func1()
      /projeto/main.go:7 +0x44
...

Apesar de parecer intimidadora essa saída, a informação relevante é que tivemos um read na linha 7 por uma goroutine e um write na mesma linha 7 por outra goroutine, então nos diz exatamente onde ocorreu o race.

Sugestões de leitura:

Data Race Detector - The Go Programming Language

4. Cache com `sync.Mutex`

Como vimos anteriormente, precisamos de alguma forma de evitar data race no map do nosso cache. Para esse tipo de problema existe o conceito de mutex.

Mutex é um mecanismo para garantirmos que somente uma goroutine tem acesso exclusivo a algo do momento que ela adquire o lock até o momento que ela libera o lock.

Uma analogia para ficar mais claro:
Pensa em um banheiro. Se não tem nenhuma forma de sincronização, pode acontecer de duas ou mais pessoas usarem o banheiro ao mesmo tempo, o que daria resultados bem desagradáveis.

A mutex é como se fosse a chave para o banheiro, e quem adquire essa chave se tranca no banheiro e tem acesso exclusivo a ele, enquanto as outras pessoas esperam do lado de fora até que a pessoa termine de usar o banheiro.

A mutex dá problema quando, ainda na analogia, uma pessoa se tranca no banheiro e não quer mais sair, que é o cenário de deadlock.

Criando um tipo para o Cache e utilizando uma mutex

Para começar vamos criar uma struct para o Cache com o método Get, Set e Delete, que por enquanto só executa as operações normais do map, sem ser concurrent-safe.

type Cache struct {
    data map[string]string
}

func NewCache() Cache {
    return Cache{
        data: map[string]string{},
    }
}

func (c Cache) Set(key string, val string) {
    c.data[key] = val
}

func (c Cache) Get(key string) (val string, ok bool) {
    val, ok = c.data[key]
    return
}

func (c Cache) Delete(key string) {
    delete(c.data, key)
}

Agora vamos adicionar a mutex a struct e ao construtor:

type Cache struct {
    data    map[string]string
    dataMut *sync.Mutex
}

func NewCache() Cache {
    return Cache{
        data:    map[string]string{},
        dataMut: &sync.Mutex{},
    }
}

Agora antes de lermos ou escrevermos no map, precisamos fazer um Lock para garantirmos que só uma goroutine está lendo/escrevendo, e quando terminarmos, precisamos fazer um Unlock para permitir que outra goroutine possa fazer o mesmo.

func (c Cache) Set(key string, val string) {
    c.dataMut.Lock()
    c.data[key] = val
    c.dataMut.Unlock()
}

func (c Cache) Get(key string) (val string, ok bool) {
    c.dataMut.Lock()
    val, ok = c.data[key]
    c.dataMut.Unlock()
    return
}

func (c Cache) Delete(key string) {
    c.dataMut.Lock()
    delete(c.data, key)
    c.dataMut.Unlock()
}

E para utilizar o cache:

cache := NewCache()
cache.Get("key") // "", false
cache.Set("key", "somevalue")
cache.Get("key") // "somevalue", true
cache.Delete("key")
cache.Get("key") // "", false

Sugestões de leitura:

Mutual exclusion - Wikipedia
Documentação da sync.Mutex - Go Packages

5. Introduzindo a `sync.RWMutex`

Como falamos antes, podemos ter múltiplas goroutines lendo o mesmo dado sem problemas, desde que não tenha nenhuma escrevendo ao mesmo tempo, porém com a sync.Mutex só permitimos uma goroutine ler por vez.

Para permitirmos leituras concorrentes, existe a sync.RWMutex, onde o "RW" é uma sigla para "read-write".
A RWMutex nos permite fazer dois tipos de lock e unlock:

write lock com Lock, write unlock com Unlock
read lock com RLock. read unlock com RUnlock

Quando precisamos alterar um dado, temos que fazer fazer um Lock e no fim Unlock.
Quando só queremos ler um dado sem fazer modificações, podemos fazer um RLock e no fim um RUnlock.

Atualizando métodos para usar `sync.RWMutex`

type Cache struct {
    data    map[string]string
    dataMut *sync.RWMutex
}

func NewCache() Cache {
    return Cache{
        data:    map[string]string{},
        dataMut: &sync.RWMutex{},
    }
}

func (c Cache) Set(key string, val string) {
    // write lock
    c.dataMut.Lock()
    c.data[key] = val
    c.dataMut.Unlock()
}

func (c Cache) Get(key string) (val string, ok bool) {
    // read lock
    c.dataMut.RLock()
    val, ok = c.data[key]
    c.dataMut.RUnlock()
    return
}

func (c Cache) Delete(key string) {
    // write lock
    c.dataMut.Lock()
    delete(c.data, key)
    c.dataMut.Unlock()
}

Sugestões de leitura:

Readers-writers lock
Documentação da sync.RWMutex

6. Utilizando generics

Até o momento, nosso cache só aceita chaves e valores do tipo string, mas agora vamos deixar nosso cache mais flexível, aceitando qualquer tipo de chave e valor.

Introduzindo a sintaxe de generics

Alguns exemplos de structs genéricas:

type List[T any] struct {
    slice []T
}

// a chave do map precisa ser um tipo comparável
type Map[K comparable, V any] struct {
    m map[K]V
}

Agora um exemplo de função genérica:

func max[T int | float64](a, b T) T {
    if a > b {
        return b
    }
    return a
}

Agora um exemplo de "método" genérico:

type List[T any] struct {
    slice []T
}

func (l *List[T]) Append(v T) {
    l.slice = append(l.slice, v)
}

Aplicando generics no tipo Cache

type Cache[K comparable, V any] struct {
    data    map[K]V
    dataMut *sync.RWMutex
}

func NewCache[K comparable, V any]() Cache[K, V] {
    return Cache[K, V]{
        data:    map[K]V{},
        dataMut: &sync.RWMutex{},
    }
}

func (c Cache[K, V]) Set(key K, val V) {
    c.dataMut.Lock()
    c.data[key] = val
    c.dataMut.Unlock()
}

func (c Cache[K, V]) Get(key K) (val V, ok bool) {
    c.dataMut.RLock()
    val, ok = c.data[key]
    c.dataMut.RUnlock()
    return
}

func (c Cache[K, V]) Delete(key K) {
    c.dataMut.Lock()
    delete(c.data, key)
    c.dataMut.Unlock()
}

E agora para usarmos nosso cache genérico:

func main() {
    cache := NewCache[string, bool]()
    cache.Set("valid", true)
    valid, _ := cache.Get("valid")
    log.Println(valid) // true
}

7. Comparações de performance

Comparei o cache utilizando sync.Mutex, sync.RWMutex, e um outro tipo que não falei aqui ainda: o sync.Map.
E para a minha surpresa, a sync.Mutex performou quase igual a sync.RWMutex, e até melhor em algumas operações.

O sync.Map é um tipo que funciona similar a um map, mas é concurrent-safe.
Pela documentação, o sync.Map é otimizado para leituras concorrentes e leituras e escritas em valores distintos.

O Resultado do benchmark foi:

# 1000 gets e sets na mesma chave
sync.Mutex      86908 ns/op
sync.RWMutex   111462 ns/op
sync.Map       239797 ns/op

# 1000 gets e sets em chaves diferentes
sync.Mutex      90000 ns/op
sync.RWMutex   115520 ns/op
sync.Map       299608 ns/op

# 1000 gets e sets concorrentes em chaves diferentes
sync.Mutex     2238245 ns/op
sync.RWMutex   2856618 ns/op
sync.Map       1884196 ns/op

# 1000 get concorrentes em chaves diferentes
sync.Mutex    1074670 ns/op
sync.RWMutex   935320 ns/op
sync.Map       876155 ns/op

Quanto maior o tempo, pior.

Então podemos concluir que nesses benchmarks:

A sync.Mutex foi mais rápida em gets e sets sequenciais na mesma chave
A sync.Mutex foi mais rápida em gets e sets sequenciais em chaves diferentes
O sync.Map foi mais rápido em gets e sets concorrentes em chaves distintas
o sync.Map foi mais rápido em gets concorrentes (sem sets) em chaves distintas

Sugestões de leitura:

Documentação do sync.Map

7 vantagens da linguagem Go

Igor Melo — Sun, 06 Aug 2023 00:28:25 +0000

Antes de tudo

Primeiro, vou fazer uma confissão…

A primeira vez que vi um código em Go eu achei a linguagem esquisita e me desinteressei.

Como assim não tem try/catch?
Por que métodos têm essa sintaxe diferente?
Por que não tem a feature XYZ que "toda" linguagem tem?

Essas foram algumas das perguntas que eu me fiz.
Só anos depois que eu resolvi dar uma segunda chance para a linguagem e resolvi aprender.

Então, antes de tudo, vai um conselho: não foque em detalhes bobos que nem eu fiz.
Uma linguagem tem muito mais a oferecer do que só uma sintaxe “bonita”.

É muito provável que em Go as coisas sejam diferentes de como você está acostumado a fazer, então não se assuste.

Introdução

Go é uma linguagem criada por desenvolvedores da Google e lançada a público em 2009.

A linguagem nasceu com foco em simplicidade, estabilidade e produtividade, pensada para desenvolver aplicações complexas e longevas.

Nesse artigo vamos ver em detalhes os pontos que eu considero os mais importantes da linguagem.

Tópicos:

Retrocompatibilidade
Compilação e portabilidade
Concorrência
Biblioteca padrão rica
Simplicidade
Ferramenta de profiling de performance nativa
Ferramenta de testes nativas

1. Retrocompatibilidade

O Go lançou sua versão estável 1.0 em 2012, com a promessa de que novas versões 1.x.y sejam retrocompatíveis.
Em outras palavras, isso significa que um código em Go escrito em 2012 usando a versão 1.0 deverá compilar e rodar corretamente em 2023 utilizando a versão 1.20.5, por exemplo.

A Google e muitas outras empresas testam a versão de pré-release do Go nos projetos internos delas para assegurar que a linguagem se manteve compatível e que nada quebrou. A vantagem disso é que se um projeto com milhões de linhas de código de produção e testes não quebraram, é bem improvável que projetos menores vão ter quebrado.

Porém a promessa de compatibilidade pode ser quebrada em alguns casos, como:

Correção de falhas de segurança
Correção de bugs na linguagem

E alguns outros cenários específicos.

O mais importante da retrocompatibilidade da linguagem é permitir que desenvolvamos códigos longevos sem precisar estarmos constantemente corrigindo e adaptando o código para as novas mudanças da linguagem.

2. Compilação e portabilidade

Na implementação oficial do Go, o código é compilado para um executável com tudo que ele precisa para rodar, o que reduz uma série de dores de cabeça.

O Go compila e otimiza o código em tempo de build, então o programa não vai utilizar memória nem CPU otimizando seu código em tempo de execução, diferente de como faz o Python, Java, JavaScript, PHP, etc.

Um detalhe importante é que no Go também é possível compilar para outras arquiteturas. Isso significa que você no Linux num processador ARM pode compilar seu código para rodar em um Windows 64 bits.
Pode não parecer muito, mas em C por exemplo isso não só não é trivial de fazer, como também é desencorajado.

Exemplo de cross-compiling de um programa Go:



GOOS=windows GOARCH=386 go build main.go # windows 32 bits
GOOS=linux GOARCH=arm go build main.go # linux arm

3. Concorrência

O Go conta com as goroutines, que são similares a threads, porém são mais leves e gerenciadas pelo runtime do Go.

O Go distribui as goroutines pelos núcleos da CPU o que possibilita processarmos coisas em paralelo, e também faz bastante uso de I/O assíncrono, o que possibilita um ganho considerável de performance em aplicações que façam muito uso de I/O, como aplicações web.

A linguagem também conta com canais (channels), que são uma ferramenta poderosa para comunicar e sincronizar goroutines.
Channels é um tópico tão importante da linguagem que eu fiz uma série de 5 artigos dedicada a eles.

4. Biblioteca padrão rica

O Go vem com uma biblioteca bem rica de pacotes que você pode utilizar em suas aplicações.
Esses são apenas alguns exemplos:

io: para lidar com leitura, escrita, etc de bytes
os: para lidar com o OS (arquivos, env, processos, etc)
time: para obter, converter e formatar tempo
testing: para testes automatizados, incluindo benchmark e fuzzing
crypto: para algoritmos e constantes criptográficas
net: para lidar com TCP, UDP, DNS
net/http: para clientes e servidores HTTP 1 e 2
html/template: template engine para HTML

5. Simplicidade

Muita gente se assusta quando ouve alguém falar que "C é uma linguagem muito simples".
Mas quando alguém fala que "C é simples" não significa que programar em C é moleza, mas sim que a linguagem em si é mais minimalista, não possui muitas formas diferentes de fazer a mesma coisa, não tem muito comportamento implícito, etc.

Alguns exemplos de como esse princípio é aplicado no Go:

Idealmente só há uma forma de fazer algo
O equivalente a "constructors" e "destructors" são explícitos
A linguagem possui apenas 25 palavras reservadas (vs 67 do Java, 95 do C++)
A especificação tem cerca de 100 páginas (vs +800 do Java, +1800 do C++)
A stdlib evita o uso de abstrações e indireções quando não é necessário

Obs.: Java e C++ foram citados só para fins de comparação

A vantagem de uma linguagem simples é que você se dedica menos tempo aprendendo a linguagem em si, e mais tempo desenvolvendo e aprendendo conceitos mais importantes.

6. Ferramenta de profiling de performance nativa

Não deixei esse tópico como um dos primeiros porque a maioria das soluções tem uma performance "boa o suficiente" para maioria dos cenários, e otimizações costumam ser bem pontuais.

Porém, quando sua aplicação tem milhões de usuários diariamente batendo em endpoints, uma linguagem que usa pouca memória e consegue gerenciar milhares de requisições por segundo é um diferencial.

O Go conta com uma ferramenta nativa para medir uso de memória, CPU, goroutines, e muito mais, o que te permite otimizar performance com base em métricas em vez de suposições.

Além disso, desde a versão 1.20, o Go suporta Profile-guided optimization (PGO), que é utilizar dados obtidos num profile de performance como parâmetro para otimizar o código durante a compilação.

7. Ferramenta de testes nativas

O Go vem com suporte nativo a testes automatizados, fuzzing e benchmarking.

Com testes automatizados você pode validar que seu código está sempre se comportando como esperado.



func TestFormatarNomeDeCartao(t *testing.T) {
    nome := "Zezinho da Silva Freitas Junior"
    esperado := "Zezinho da S F Junior"

    resultado := FormatarNomeDeCartao(nome)

    if resultado != esperado {
        t.Errorf("esperado: %s, obtido: %s", esperado, resultado)
    }
}

Com testes de fuzzing você alimenta o teste com um valor inicial, que no nosso exemplo vai ser um nome, e o fuzzer vai começar a criar variações desse valor e chamar sua função com eles.



func FuzzFormatarNomeDeCartao(f *testing.F) {
    f.Add("Zezinho da Silva")
    f.Fuzz(func (t *testing.T, nome string) {
        resultado := FormatarNomeDeCartao(nome)

        if len(resultado) > len(nome) {
            t.Errorf("O nome abreviado '%s' está maior que o original '%s'", resultado, nome)
        }
    })
}

Com testes de benchmark você pode verificar o tempo médio que uma função leva para rodar, uso de memória, alocações etc.



func BenchmarkFormatarNomeDeCartao(b *testing.B) {
    for i := 0; i < b.N; i++ {
        FormatarNomeDeCartao("Zezinho da Silva Freitas Junior")
    }
}

Go: Analisando performance com pprof

Igor Melo — Fri, 26 May 2023 19:31:47 +0000

Introdução

O pprof (Performance Profiler) é uma ferramenta que vem com o Go e que serve para extrair dados de performance, como uso de CPU, alocação de memória, goroutines, entre outros.

A grande utilidade do pprof é que ele nos diz exatamente onde no nosso código os recursos estão sendo utilizados, ou seja, conseguimos achar com facilidade as funções que estão usando mais CPU ou mais memória, e até conseguimos ver a linha exata do código que está causando o problema de performance.

Aplicação de exemplo

Vou usar como exemplo esse código:

package main

import (
    "os"
)

func main() {
    if len(os.Args) != 3 {
        panic("argumentos invalidos")
    }

    b, err := os.ReadFile(os.Args[1])
    if err != nil {
        panic(err)
    }

    err = os.WriteFile(os.Args[2], b, 0666)
    if err != nil {
        panic(err)
    }
}

O que ele faz é simples: copia o conteúdo de um arquivo para outro arquivo, similar ao que o comando cp faz.
Claro que é só um exemplo bobo comparado a aplicações reais, mas é suficiente para praticarmos.

Esse programa tem um problema... Se eu tento copiar um arquivo muito grande, o uso de memória aumenta em mais de 3GB:

Por que isso acontece? Vamos investigar.

Fazendo o profiling

A forma mais prática de fazer o profiling de CPU e memória é criando um teste comum ou de benchmark.
Para isso vou criar um arquivo main_test.go e vou adicionar:

package main

import "testing"

func Test_main_CopyManjaro(t *testing.T) {
    // injetando os argumentos para o programa funcionar
    os.Args = []string{"gp", "manjaro.iso", "manjaro2.iso"}
    main()
}

E daí, se executarmos:

go test .

Ele vai só rodar os testes nesse pacote.

Já para extraírmos os profiles, fazemos:

go test -cpuprofile cpu.prof -memprofile mem.prof .

Analisando os dados de memória

Agora que extraímos os dados que queríamos, vamos analisar na ferramenta web do pprof.
Para isso, basta executar:

go tool pprof -http :8080 mem.prof

E ele vai abrir o profile de memória no seu navegador padrão.

Esse gráfico pode parecer meio intimidador a primeira vista, mas basicamente ele está nos dizendo quais funções chamam quais, e quais usam mais memória:

Se seguirmos o gráfico, a função tRunner (do pacote de testes) chama Test_main, que chama a main, e a main chama os.ReadFile, sendo esse último quem aloca nesse caso 3.82GB.

Indo em View e trocando a visualização para Top chegamos na mesma conclusão.

Otimizando com base no profiling de memória

Descobrimos que a função os.ReadFile é a causadora do problema de uso de memória, porque estamos lendo todo o arquivo em memória e só então escrevendo o conteúdo num novo arquivo.

A solução é ler pedaço por pedaço do arquivo e ir escrevendo em outro arquivo, e para isso podemos usar a função io.Copy.

O código vai ficar assim:

package main

import (
    "os"
    "io"
)

func main() {
    if len(os.Args) != 3 {
        panic("argumentos invalidos")
    }

    src, err := os.Open(os.Args[1])
    if err != nil {
        panic(err)
    }
    defer src.Close()

    dst, err := os.Create(os.Args[2])
    if err != nil {
        panic(err)
    }
    defer dst.Close()

    _, err = io.Copy(dst, src)
    if err != nil {
        panic(err)
    }
}

E o resultado do uso de memória, olhando pelo gerenciador de tarefas é:

Analisando um profiling de CPU

O profiling de CPU desse caso não vai nos dar muita informação interessante, por ser um código extremamente simples, então vou usar um exemplo de outro projeto que fiz para um desafio.

O projeto em questão envolve ler um arquivo e inserir os dados de cada linha num banco Postgres.

O meu programa estava levando 37 segundos para processar 50 mil linhas, então resolvi fazer o profiling de CPU para investigar.
Eu fiz o profiling de CPU e abri o pprof na aba de Flame Graph (new).
Essa aba nos mostra quais funções estão levando mais tempo para executar:

Pode parecer intimidador, mas em resumo o que o gráfico diz para nós é que a função main.main chama diversas funções, como:

pgx.(*Conn).Exec
main.CustomerFrom
Fields

E as funções mais "largas" são as que estão tomando mais tempo para serem executadas, e nesse caso é a pgx.(*Conn).Exec.
Essa função é a que executa a inserção no banco Postgres.

Pesquisando sobre Postgres e estudando a lib pgx eu descobri que uma possível solução era enviar várias inserções de uma vez (chamado de batch), e resolvi experimentar e fazer um novo profiling.
O resultado foi: queda de 37s para 2s no tempo de execução.

Veja que a função pgx.(*Conn).SendBatch e Exec estão tomando uma fatia muito menor do tempo, e o que estava lento agora era a serialização e desserialização de dados.

E em aplicações que "não param"?

Até agora as técnicas de profiling que vimos só vão servir para aplicações que encerram rápido, como scripts, ferramentas de terminal, etc.

Para aplicações que rodam por tempo indeterminado, como servidores e interfaces gráficas, vamos precisar de outra abordagem para fazer esse profiling.

Para manter esse artigo simples e leve, vamos abordar essas técnicas na parte 2.
A parte 1 é mais para te dar uma noção de como funciona profiling em Go e como identificar problemas de performance.

Conclusão

Espero que essa primeira parte tenha te dado uma boa noção de como fazer profiling em Go e também tenha te esclarecido a importância de mensurar antes de otimizar, pois sem métricas você não tem como priorizar o que precisa ser otimizado e vai acabar gastando bastante energia otimizando coisas que não precisam tanto assim.

Aguarde a segunda parte para falarmos como analisar performance de aplicações web e similares, onde como já falamos, são aplicações que rodam por tempo indeterminado e precisam de estratégias diferentes para mensurar performance.

Git para leigos

Igor Melo — Sun, 19 Mar 2023 18:51:02 +0000

O Git hoje é uma ferramenta fundamental para praticamente todos os desenvolvedores.
Nesse artigo você irá entender de forma simplificada como o Git funciona, sua aplicabilidade e alguns comandos essenciais.
Não veremos ainda como utilizar GitHub pois isso geraria mais confusão para quem tá começando e não entende ainda como o Git funciona.

Todo mundo já fez algo assim

Seja algum trabalho da escola, TCC, ou mesmo algum projeto de programação, você com certeza já deve ter feito isso:

trabalho de historia.docx
trabalho de historia2.docx
trabalho de historia3.docx
trabalho de historia FINAL.docx
trabalho de historia FINAL DE VERDADE.docx
trabalho de historia FINAL AGORA EH PRA VALER.docx
trabalho de historia FINAL CORRECOES.docx

Basicamente evitamos sobrescrever o arquivo por temos medo de alterar demais e não conseguir voltar a versão anterior.

Para isso há décadas surgiram vários sistemas de controle de versão, que são ferramentas que te ajudam a registrar versões, que são pontos no histórico de alterações em arquivos, basicamente.

O que é o Git

Eu gosto de pensar no Git como uma “máquina do tempo de arquivos”.

A figura acima é um exemplo de histórico de alterações, como se fosse uma linha do tempo.

Com essa “máquina” conseguimos ver como um arquivo estava no passado, desfazer alterações, criar “realidades alternativas” onde o mesmo arquivo pode ser alterado de formas diferentes, desfazer alterações e muito mais.

Na figura, em amarelo está o histórico principal, enquanto em azul é um histórico alternativo onde um tema está sendo desenvolvido. Quando esse tema é finalizado ele é combinado ao histórico principal.
Não se preocupe em entender esse conceito agora.

O Git se torna útil por uma série de motivos:

Você não precisa ficar criando cópias de arquivos para não perder suas alterações
O Git utiliza pouco armazenamento e é bem rápido
É ótimo para trabalhar com arquivos em formato texto, como código, arquivos de configuração, arquivos de projetos, etc
Tendo um histórico bem definido de alterações, é muito mais fácil entender o que foi alterado e reverter algo se necessário
Facilita o trabalho em equipe, sendo possível combinar o trabalho de múltiplas pessoas com detecção automática de conflitos

Instalando o Git

Siga as instruções de instalação para o seu sistema. Para o Windows, instale com as opções padrões.

Seu primeiro projeto com Git

A melhor forma de aprender qualquer coisa é pondo em prática. Para isso vamos iniciar um projeto com Git.

Vamos criar um projeto do zero exclusivamente para treinar Git, pois assim vamos ficar mais a vontade de fazer alterações e executar comandos sem medo de perder algo de importante.

Para isso:

Abra um terminal, no caso de Linux ou Mac, ou o Git Bash, no caso de Windows
Digite mkdir aprendendo-git e aperte Enter para criar uma pasta
Digite cd aprendendo-git e aperte Enter para entrar na pasta que criou
Agora que está na pasta certa, digite git init e aperte Enter

Seu resultado deve ser algo similar a isso:

Com o comando git init nós inicializamos um repositório na pasta oculta .git.
Um repositório é um local onde diversas informações, inclusive os registros de histórico, são guardadas.
O repositório só vai analisar os arquivos dentro dessa pasta aprendendo-git e das subpastas, exceto a .git em si.

Tome cuidado! Se você apagar a pasta .git, você perderá todo o histórico que foi registrado.

O comando `git status`

Este é um comando que iremos utilizar com bastante frequência, pois ele nos lista quais arquivos foram criados, alterados, apagados e essa alteração ainda não foi registrada no histórico.

Como no projeto que acabamos de criar ainda não tem nenhum arquivo, se rodarmos o comando git status, vamos ter a seguinte saída:

Basicamente está sendo dito que não tem nenhuma alteração para registrar.

Vamos então criar um arquivo na pasta aprendendo-git utilizando o editor de sua preferência.

Agora se rodarmos git status de novo, vamos ter uma saída diferente:

O arquivo que criei está com status untracked, que significa que o Git nunca registrou esse arquivo no histórico.

Obs.: o vermelho no arquivo não significa que algo está errado. O Git usa apenas para distinguir o status

Gravando alterações no histórico

Uma coisa importante para quem tá começando é que o Git não registra histórico por conta própria.

Se você fizer uma alteração e desfazer sem explicitamente registrar no Git, essa alteração vai ser perdida.

Para gravar uma alteração, precisamos seguir este fluxo:

1. Fazer alteração

Esse é o passo mais simples e já fizemos. Basta criar um arquivo dentro do projeto utilizando qualquer programa.

Alterações nesse estágio são chamadas de alterações não-preparadas (unstaged) e são representadas no Git pela cor vermelha.

2. Preparar alteração

Esse passo antes de registrar a alteração nos dá maior flexibilidade, porque podemos ter 10 arquivos alterados, mas só 3 que queremos registrar no momento.
Alterações nesse estágio são chamadas de preparadas (staged) e são representadas no Git pela cor verde.

Para preparar todas as alterações em um arquivo, basta rodar o comando git add <arquivo>.

Se olharmos o git status depois disso, vamos ver que agora o arquivo está com um status diferente e cor verde:

3. Registrar alteração

Até o momento, nenhuma alteração que fizemos foi de fato “salva” no repositório.
Para registrar nossas alterações preparadas (staged), nós vamos usar o comando git commit.

Esse comando cria um commit, que nada mais é do que um registro no histórico do Git.
A partir de agora vou passar a chamar “registro” de commit para você se acostumar com o termo.

Um commit por padrão exige uma mensagem resumindo o que essas alterações fazem e o porquê.
Podemos passar a mensagem utilizando a opção -m do comando commit, da seguinte forma:

git commit -m 'criando um exemplo'

Obtemos um erro porque não temos nome e email configurado no Git.

Todo commit no Git precisa dessas duas informações. Vamos fazer o sugerido e configurar nosso nome e email global.
Não existe nenhuma validação nisso, então eu posso botar qualquer email e nome:

# com o --global: todos os projetos irão usar essas credenciais por padrão
config --global user.email "igor@eu.com"
config --global user.name "Igor"

# sem o --global: cada projeto terá que configurar seu próprio user.email e user.name
config user.email "igor@eu.com"
config user.name "Igor"

Agora se tentarmos de novo, irá funcionar:

Pronto!
Fizemos nosso primeiro commit.

Agora vamos checar o status de novo:

E vamos novamente modificar o arquivo exemplo.txt e olhar o status:

Repare que o status dessa vez é modified, porque agora o arquivo já tem histórico no Git.

Vendo o histórico de commits e as alterações feitas

Há várias formas de fazer isso, mas para simplificar, vou usar um único comando: git log -p.

O git log lista os commits na ordem dos mais recentes para os mais antigos:

Várias informações são mostradas, mas as mais importantes por agora são:

Autor (nome e email)
Data
Mensagem (criando um exemplo)

Para sair dessa visualização apertamos q e podemos mover na vertical com as setas ou scroll do mouse.

Se adicionarmos a opção -p, esse vai ser o resultado:

De novo, aqui vemos várias informações sendo mostradas, mas as mais relevantes são:

Mensagem, para entender o contexto das alterações
Nome do arquivo que foi alterado, depois do +++ (ignore o a/ e o b/)
O texto em verde com prefixo +, que significa que aquela linha foi adicionada
Linhas em vermelho com prefixo - significa que foram removidas

Exemplo mais concreto

Vamos criar um projeto do zero de novo, mas dessa vez vamos fazer algo menos abstrato para você ter uma sensação de como é usar Git para um projeto real.

Vou criar um projeto em HTML, mas não é requisito saber.

1. Iniciando o projeto

Vamos sair da pasta aprendendo-git vamos criar uma nova pasta padaria e vamos entrar nela:

cd
mkdir padaria
cd padaria

Vamos iniciar um repositório Git:

git init

2. Primeiro commit

Agora vamos começar a criar a página principal, index.html:

<h1>Bem-vindo a Padaria Rubrum Panem</h1>
<p>
    Ipsum quo quia voluptatem quibusdam. Minima eos animi
    dignissimos consequuntur qui optio distinctio possimus.
</p>

Quando sentirmos que já temos um básico feito, já podemos fazer nosso primeiro commit.

Primeiro adicionamos o arquivo index.html:

git add index.html

E em seguida fazemos um commit:

git commit -m 'página principal'

3. Commit de nova funcionalidade

Agora resolvemos criar uma página de contato, contato.html:

<h1>Contato</h1>
<ul>
  <li>Telefone: (99) 99999-9999</li>
  <li>Email: contato@padaria.com</li>
  <li>Endereço: Rua da Padaria, 123 - Osasco</li>
</ul>

E criamos um link na index.html para a página contato.html:

...
<a href="/contato.html">Contato</a>

Faz sentido que ambas as alterações sejam adicionadas a um mesmo commit, já que estão totalmente relacionadas. Sem a alteração do index.html o usuário não tem link para a página de contato, então vamos adicionar os dois arquivos:

git add index.html contato.html

Podemos olhar o status para confirmar que os dois arquivos foram adicionados:

E agora fazemos o commit:

git commit -m 'página de contato'

4. Revendo os commits feitos

Se rodarmos o comando git log -p que aprendemos antes, o resultado será:

E rolando para baixo:

Conclusão

Com isso já podemos concluir a primeira parte, mas não se iluda, isso é apenas o começo!
Pratique bastante, pois mais para frente você vai aprender a reverter commits, combinar commits, criar branches, trabalhar com remotes como GitHub, criar pull requests, e muito mais.

Implementando um cat em C

Igor Melo — Mon, 23 Jan 2023 14:09:07 +0000

Introdução

O cat é uma ferramenta muito utilizada para ler e escrever em arquivos.

Ela faz parte do Coreutils, que é um conjunto de utilitários para manipular arquivos, shell e texto, como ls, chmod, mkdir, cd, entre outros.

Exemplos de utilização do `cat`

Ler um arquivo:

$ cat arquivo.txt
Esse
é
o 
conteúdo!

Ler mais de um arquivo:

$ cat arquivo1.txt arquivo2.txt
Conteúdo do arquivo 1
Conteúdo do arquivo 2

Entendendo `stdin`, `stdout` e `stderr`

Esses três são streams de dados, ou seja, são um “caminho” por onde dado é recebido ou enviado.

stdin representa a entrada padrão (stan*dard **in*put) do programa, que no terminal geralmente é o teclado.

stdout representa a saída padrão (*standard **out*put) do programa, e stderr representa a **saída padrão de erro (*standard **err***or), sendo que ambas são geralmente a tela do terminal.

O “geralmente” é usado por 2 motivos:

Essas 3 streams podem ser redirecionadas para arquivos e outros lugares
Em aparelhos como um Arduino a entrada pode vir de sensores e a saída pode ser para um display

Detalhe: no C, stdin, stdout e stderr são arquivos, então lidamos com eles da mesma forma que lidaríamos com qualquer outro arquivo.

Redirecionando streams no terminal

Ainda no exemplo do cat, se rodarmos somente o comando sem nenhum argumento, o que ele faz é ler do stdin e escrever no stdout.

$ cat
oi            # eu escrevi
oi            # cat printou
tudo bem?     # eu escrevi
tudo bem?     # cat printou

A princípio pode parecer meio sem utilidade o cat ”imitar” o que você escreve, mas isso se torna útil quando você redireciona a saída para um arquivo usando o >.

$ cat > novo.txt
Escrevendo o
conteúdo
desse arquivo
# aperte ctrl + D para finalizar

$ cat < original.txt > copia.txt

Iniciando a implementação em C usando `stdio.h`

Agora que os conceitos de entrada e saída padrão já estão mais claros, podemos começar a implementar o código do nosso cat.

Para isso vamos partir dessa estrutura básica:

#include <stdio.h>

int main(int argc, char *argv[]) {
    return 0;
}

E agora vamos implementar só a parte de ler do stdin e escrever no stdout:

#include <stdio.h>

int main(int argc, char *argv[]) {

  // argc: número de argumentos
  // argc == 1 signfica que o programa foi chamado sem nenhum
  // argumento extra, exemplo: ./cat

  if (argc == 1) {
    while (1) {
      // lê um caracter do stdin
      int ch = getc(stdin);

      // EOF significa fim do arquivo (end of file)
      if (ch == EOF)
        break;

      // escreve o caracter no stdout
      putc(ch, stdout);
    }
  }

  return 0;
}

O que esse programa faz é ficar lendo cara caractere do stdin até o último do arquivo.

Se a entrava for o teclado, ele lê até forçamos um EOF apertando ctrl + D.

Validando usando o `cat` original

Criei esse shell script para testar se o programa tem o mesmo comportamento do cat:

# para cada arquivo na pasta home
for f in ~/*; do

    # executa o cat real, o meu cat e tira o md5 da saída
    # < $f redireciona o conteúdo do arquivo atual para o stdin
    a=$(cat < $f | md5sum)
    b=$(./cat < $f | md5sum)

    # se o md5 for diferente, é sinal que algo está errado
    if [[ "$a" != "$b" ]]
    then
        echo "$f ($a vs $b)"
    fi
done

Isso não garante que nosso cat está totalmente correto, mas nos dá uma confiança maior de que está funcionando igual para muitos cenários.

Implementando o `cat` com argumentos

Caso sejam passados argumentos, o cat vai tratá-los como nomes de arquivos, vai tentar ler um por um e escrever seu conteúdo no stdout.

Obs.: o cat também recebe opcionalmente alguns outros argumentos, mas não vamos implementá-los aqui.

#include <stdio.h>

int main(int argc, char *argv[]) {
  if (argc == 1) {
    ...
  } else {
    for (int i = 1; i < argc; i++) {

      // abrimos o arquivo no modo leitura
      FILE *file = fopen(argv[i], "r");

      while (1) {
        // lê um caracter do arquivo, printa no stdout
        int ch = getc(file);
        if (ch == EOF)
          break;
        putc(ch, stdout);
      }

      // fechamos o arquivo para evitar problemas
      fclose(file);
    }
  }

  return 0;
}

Tratando arquivos que não podem ser lidos

Se você passar um arquivo que não existe ou que você não tem permissão para ler, vai acontecer um segmentation fault:

$ ./cat naoexiste     
[1]    99032 segmentation fault (core dumped)  ./cat naoexiste

Isso acontece porque quando o arquivo não pode ser aberto, o fopen retorna NULL e altera a variável global errno para o código do erro.
Precisamos tratar esses erros antes de tentar fazer qualquer operação com o arquivo, senão teremos comportamentos indefinidos no nosso programa.

#include <stdio.h>
#include <errno.h>

// usamos a função strerror para printar uma
// mensagem de erro com base no errno
#include <string.h>

int main(...) {
  // se tudo correr bem, esse valor não vai mudar,
  // e vamos retornar 0, que signifca ok
  int exit_status = 0;

  ...

  else {
      FILE *file = fopen(argv[i], "r");

      // arquivo não existe / não pode ser lido
      if (file == NULL) {

        // printar na saída de erro no mesmo formato que o cat, exemplo:
        // cat: naoexiste: No such file or directory
        fprintf(stderr, "%s: %s: %s\n", argv[0], argv[i], strerror(errno));

        // se o arquivo não existe, o cat não encerra imediatamente,
        // mas continua lendo os próximos arquivos e só depois 
        // finaliza com código de erro
        exit_status = errno;
        continue;
      }

      ...
    }
  }

  // retornando o status
  return exit_status;
}

Também seria necessário tratar erros de leitura e escrita em arquivos, mas vamos deixar para a parte 2.

Código completo feito com `stdio.h`

#include <errno.h>
#include <stdio.h>
#include <string.h>

int main(int argc, char *argv[]) {
  int exit_status = 0;

  if (argc == 1) {
    while (1) {
      int ch = getc(stdin);
      if (ch == EOF)
        break;
      putc(ch, stdout);
    }
  } else {
    for (int i = 1; i < argc; i++) {
      FILE *file = fopen(argv[i], "r");

      if (file == NULL) {
        fprintf(stderr, "%s: %s: %s\n", argv[0], argv[i], strerror(errno));
        exit_status = errno;
        continue;
      }

      while (1) {
        int ch = getc(file);
        if (ch == EOF)
          break;
        putc(ch, stdout);
      }
    }
  }

  return exit_status;
}

Dúvidas comuns

Ler/escrever byte por byte não prejudica a performance?

Não, porque os arquivos no C por padrão são “buferizados” (buffered), ou seja, quando você chama putc, esse byte é escrito num array (buffer) em memória até uma certa quantidade pré-definida, e depois esse array inteiro é escrito no arquivo de uma vez.

Dessa forma a escrita se torna mais rápida, pois escrever na memória é ordens de vezes mais rápido que no disco.
Essa escrita no arquivo de fato é chamada de “flush”, e você pode forçar um flush a qualquer momento no C usando fflush.

Da mesma forma a leitura de um arquivo com getc lê vários bytes e guarda num buffer em memória. Próximas chamadas para getc vão ler desse buffer e não do disco, até que seja necessário consultar o disco de novo.

Usei getc e putc como exemplos, mas o buffer é aplicado independente da função que você está usando para leitura ou escrita.

Conclusão

Bom, já falei bastante, apesar de não ter dado para abordar alguns assuntos.
Espero que esse texto tenha sido útil e tenha te trazido insights sobre C, sobre o programa cat e sobre como lidar com stdin, stdout e stderr.

Na parte 2 eu pretendo reimplementar esse código de forma mais baixo nível, falando diretamente com o kernel, implementando manualmente os buffers de leitura e escrita e usando outra estratégia para tratar erros.

Como sempre qualquer correção, sugestão ou informação que agregue é muito bem vinda.

Até a próxima!

5 dicas simples para deixar seu site mais rápido

Igor Melo — Sun, 16 Oct 2022 22:24:11 +0000

Introdução

Otimizar performance é parecido com economizar dinheiro.
Não adianta você economizar centavos apagando as luzes da casa, enquanto usa ar condicionado horas por dia.

Assim como economizar dinheiro, para otimizar performance é importante ter métricas para atacar a principal causa do problema, senão você vai estar jogando energia fora com algo que talvez não traga nenhum benefício perceptível.

A métrica também é importante para confirmar que nossa alteração realmente melhorou a performance.

No browser, você pode usar as diversas ferramentas que o DevTools oferece, como Performance, Performance Monitor, Memory, Network, etc, e também a extensão LightHouse.

Você também pode usar outras ferramentas como Elastic APM e similares para monitorar tanto o front-end quanto o back-end.

Nesse artigo eu não vou me basear em métricas, porque na realidade vou dar sugestões de coisas que você pode experimentar para melhorar performance.

A parte de medir e validar se houve melhoria de performance fica contigo.

1 - Use debounce e throttle

Debounce e throttle são funções para atrasar ou limitar quantas vezes um processamento é realizado.
O JavaScript não tem nativamente essas funções, porém você pode implementar ou usar uma biblioteca para isso.

Nesse exemplo aqui eu botei um event listener no evento de scroll.
Eu fiz scroll por poucos segundos e esse listener foi disparado 240 vezes.

Se eu tiver alguma função que faz algum processamento pesado no meu event listener, eu vou travar a aba do navegador disparando esse processamento dezenas de vezes.

Debounce

O debounce atrasa a execução de uma função por um tempo determinado pelo usuário.
Por exemplo:

window.onscroll = debounce(() => console.log('scrolled'), 1000)

O console.log só vai ser executado 1 segundo depois do último evento de scroll.

Throttle

O throttle executa a chamada para a função num intervalo definido pelo usuário.

window.onscroll = throttle(() => console.log('scrolled'), 1000)

Nesse caso, se o usuário ficar fazendo scroll, a cada segundo vai ter um console.log.

2 - Coloque só o crítico no `head`

Se você coloca todos os seus JS e CSS no head do seu index.html, você está fazendo com que sua página fique em branco até que todos esses arquivos carreguem.

Esse é o momento que vários usuários desistem de usar seu site!

<!DOCTYPE html>
<html lang="pt">
  <title>Meu site lento</title>
  <link rel="stylesheet" href="estilo_critico.css">
  <link rel="stylesheet" href="estilo_nao_critico1.css">
  <link rel="stylesheet" href="estilo_nao_critico2.css">
  <script src="script_nao_critico1.js"></script>
  <script src="script_nao_critico2.js"></script>
</head>
<body>
  <!-- só vai aparecer depois que todos os arquvios forem baixados e processados -->
  <h1>Bem vindo!</h1>
</body>
</html>

Uma regra simples é a seguinte:

só coloque no head o que você realmente precisa que seja carregado e processado antes do browser mostrar algo na tela.

Só coloque estilos no head que você considere críticos, exemplo: fontes, layout básico, cores.

Só coloque scripts no head se você realmente precisa que eles façam algo antes da página ser renderizada.

Se você não precisa que um estilo ou script execute antes da página ser renderizada, coloque no fim do body.

Resultado do html anterior:

<!DOCTYPE html>
<html lang="pt">
  <title>Meu site otimizado</title>
  <link rel="stylesheet" href="estilo_critico.css">
</head>
<body>
  <!-- vai aparecer assim que o estilo_crítico.css carregar -->
  <h1>Bem vindo!</h1>

  <link rel="stylesheet" href="estilo_nao_critico1.css">
  <link rel="stylesheet" href="estilo_nao_critico2.css">
  <script src="script_nao_critico1.js"></script>
  <script src="script_nao_critico2.js"></script>
</body>
</html>

Obs.: no caso de scripts, você até pode deixá-los no head, desde que use defer

Saiba mais:

Critical rendering path - Web performance | MDN

3 - Coloque o crítico inline

Fazer uma requisição HTTP é algo que pode ser bem lento, principalmente em redes móveis, porque o tempo da requisição chegar no servidor e voltar é muito grande.

Dessa forma, no primeiro carregamento da sua página você deve buscar fornecer o crítico num único arquivo HTML.

<html lang="pt">
  <title>Meu site rapidão</title>
</head>
<body>
  <style>
    /* meu estilo crítico */
    body {
      color: red;
    }
  </style>
  <!-- vai aparecer mais rápido pois não vai fazer uma req. pro estilo crítico -->
  <h1>Bem vindo!</h1>

  <link rel="stylesheet" href="estilo_nao_critico1.css">
  <link rel="stylesheet" href="estilo_nao_critico2.css">
  <script src="script_nao_critico1.js"></script>
  <script src="script_nao_critico2.js"></script>
</body>
</html>

Um site que faz isso bem é o G1:

Mesmo desativando o cache e simulando um 3G lento, em menos de 2 segundos o texto da notícia e o layout básico da página foi carregado, o que para um usuário é bem aceitável.

Já o Github é outra história:

O site carrega 8 estilos no head.

O navegador levou 19 segundos para mostrar algo na tela! Muitos usuários desistiriam no caminho.

Também é preciso ter um cuidado especial com single page applications, pois elas são todas renderizadas no cliente, e muitas vezes acabam fazendo muitas requisições.
Você pode experimentar reduzir o número de requisições usando GraphQL ou outras técnicas como server side rendering.

Saiba mais:

Inlining critical CSS

4 - Use cache de requisições HTTP

Caching é uma ótima estratégia para diminuir tempo de carregamento de páginas e entregar uma experiência instantânea para o usuário.

4.1 - `Cache-Control` e `max-age`

O cache-control é um header de resposta HTTP que, entre outras coisas, diz para o navegador por quanto tempo ele pode salvar o resultado de uma requisição para usar no futuro.

Esse tempo é definido pelo max-age, que é um valor sempre em segundos.

Exemplo: cache de dois minutos

Cache-Control: max-age=120

Se eu fizer umas requisições com o mesmo path, exemplo /img/1234.png, a primeira vai trazer do back-end e a salvar em cache por 2 minutos.

Se na segunda vez ainda não tiver passado 2 os minutos, o resultado da requisição anterior vai ser reutilizado, sem nem precisar falar com o back-end.

Isso traz um benefício de performance enorme, porque trazer do disco pode ser milhares de vezes mais rápido do que trazer do servidor.

4.2 - ETag

ETag é um outro header de resposta que também serve como validação de cache.
O ETag é pensado para ser um código curto identificador daquela resposta.

Em resumo:

respostas idênticas devem ter o mesmo ETag
respostas distintas devem ter ETags diferentes

O motivo disso é que quando o navegador fizer uma requisição que responda com um ETag, ele vai salvar a resposta no disco e nas próximas vezes ele vai enviar o ETag para o servidor, falando "Se o body mudar, me retorna o novo body. Se não, me retorne um status 304 (Not Modified) sem body.".

ETags podem ser implementadas no lado do servidor fazendo hash do body da resposta.

Se for uma requisição para um arquivo, pode ser baseada no momento de última modificação.

Se for uma requisição que consulta dados do banco, também pode usar a última vez que um dado foi alterado...
Use sua imaginação.

4.3 - Combinando `max-age` com `ETag`

Quem disse que você precisa escolher um ou outro?
Você pode perfeitamente pôr um cache de 5 minutos numa imagem, e também usar uma ETag.

Quando o cache expirar, o navegador vai fazer uma requisição checando se a ETag mudou, e se não, vai manter o dado que ele já tem em cache por mais 5 minutos.

Saiba mais:

Cache-Control - HTTP | MDN

ETag - HTTP | MDN

5 - Mostre menos coisa na tela de uma vez

Mais elementos na tela significa mais coisa em memória, mais elementos para recalcular o estilo e layout, mais event listeners, mais trabalho para a GPU, etc…

Se tiver muitas imagens, coloque lazy loading, porque carregar muitas imagens em paralelo vão dar uma sensação de maior lentidão e pode até travar o seu site.

Use paginação e/ou infinite scroll para controlar a quantidade de conteúdo na tela.

Dessa forma o usuário não precisa carregar megabytes de dados de uma vez só para ver o início do conteúdo.

Conclusão

Como o título avisou, foram dicas bem simples, porém que eu considero bem úteis e eficazes no desafio de entregar boa performance.

Eu tenho vontade de falar sobre outros assuntos mais desafiadores, como memory leaks, repaint and reflow, e estou lendo o livro High Performance Browser Networking do Ilya Grigorik para transformar numa série de artigos também.

Por hoje é só. Aguardo seu feedback!

Golang: Desmistificando channels - Select

Igor Melo — Wed, 12 Oct 2022 19:51:59 +0000

Select: selecionando o canal “mais rápido”

O desafio

Imagina que você quer consultar as informações de um local a partir de um CEP.

Existem algumas APIs de CEP, mas você quer que o resultado seja o mais rápido possível. O que você faz?

Você poderia fazer um benchmark para ver qual é a API mais rápida, mas isso não seria muito preciso, porque uma certa API pode ficar mais lenta em certos horários, ou pode ser mais rápida para alguns CEPs e não para outros...

Uma estratégia que podemos usar é disparar uma requisição para cada uma e usar a primeira que responder com um status de 200 OK, e essa é justamente a ideia do projeto CEP Promise do BrasilAPI.

Dessa forma não só ganhamos em performance como também em disponibilidade, porque mesmo se uma API falhar, ainda vamos ter outra(s) de fallback.

Para implementar algo parecido, podemos usar o select.

O select é como se fosse um switch, onde cada case é uma tentativa de comunicar com um canal.

O primeiro case com um recebimento ou envio pronto para ser executado vai ser o case que a goroutine vai entrar.

Exemplo:

select {
case <-time.After(time.Second):
    fmt.Println("1 segundo")

case <-time.After(500 * time.Millisecond):
    fmt.Println("500ms")
}

// "500ms"

O select por padrão pausa a execução da goroutine. Um select sem case vai parar a goroutine indefinidamente:

package main

func main() {
    ...

    // Se não tiver outra goroutine, vai causar um deadlock e encerrar
    select {}
}

O select, assim como o switch, também tem um caso default.

Ele cai no default quando nenhum dos outros casos está pronto para ser executado.

read := false

// combinando um loop com um select
for !read {

    select {
    case x := <-ch:
        fmt.Println("li do channel:", x)
        read = true

    default:
        fmt.Println("channel ainda não está preparado para leitura")
        time.Sleep(100 * time.Millisecond)
    }
}

// "channel ainda não está preparado para leitura"
// "channel ainda não está preparado para leitura"
// "li do channel: 123"

No exemplo de consulta de CEP, um código fictício para pegar o primeiro CEP que retornar seria:

cep := "12345678"
var info CepInfo

select {
case info = <-cepInfoCorreios(cep):
    fmt.Println("Correios retornou primeiro")

case info = <-cepInfoViaCep(cep):
    fmt.Println("ViaCEP retornou primeiro")
}

fmt.Println(info.City)

// obs.: num caso real você teria que cancelar as requisições HTTP também

Golang: Desmistificando channels - Buffered Channels

Igor Melo — Sat, 01 Oct 2022 21:22:43 +0000

Buffered channels

Se você já conseguiu entender e praticar bem a parte de channels, podemos falar sobre buffered channels.

Buffered channels são channels que não bloqueiam o envio e recebimento em alguns cenários, porque eles guardam os valores enviados temporariamente num buffer, que vai ser lido e removido do buffer quando alguém receber.

Você cria um buffered channel com o tamanho do buffer que você quer, por exemplo 5, daí você vai poder fazer 5 envios sem bloquear a goroutine.

A partir daí, enquanto o buffer estiver cheio, os próximos envios vão bloquear, da mesma forma que num channel sem buffer.

// basta passar um tamanho na hora de criar o channel
ch := make(chan string, 3)

// não vão bloquear a gourotine
ch <- "A"
ch <- "B"
ch <- "C"

// buffer cheio, novos envios vão bloquear a goroutine 
// até que surja um  espaço livre no buffer
ch <- "D"

Da mesma forma, receber de um buffered channel não vai bloquear se o buffer não estiver vazio.

Se ele estiver vazio, vai funcionar como um channel sem buffer.

ch := make(chan string, 3)

// não vão bloquear a gourotine
ch <- "A"
ch <- "B"
ch <- "C"

// não vão bloquear a goroutine
<-ch // "A"
<-ch // "B"
<-ch // "C"

// buffer vazio, vai bloquear a goroutine até um novo envio
<-ch

Usando buffered channels para controlar número de goroutines

Uma grande vantagem dos buffered channels é que eles passam a bloquear quando o buffer está cheio, e podemos usar isso ao nosso favor.

Nesse exemplo aqui eu tenho um programa que vai ficar criando goroutines indeterminadamente e cada goroutine faz uma requisição GET.

package main

import (
    "fmt"
    "net/http"
)

func main() {
    for {
        go func() {
            client := http.Client{}

            resp, _ := client.Get("https://www.google.com")
            resp.Body.Close()

            fmt.Println(resp.Status)
        }()
    }
}

O problema é que não podemos ficar criando goroutines e clientes HTTP sem limites, porque memória não é infinita, e nem vai ser muito eficiente fazer milhares de requisições ao mesmo tempo.

Esse programa vai cedo ou tarde dar um erro e vai encerrar:

"runtime error: invalid memory address or nil pointer dereference"

Stack:
    4  0x0000000000744764 in main.main.func1
        at /home/igor/Git/pessoal/got/main.go:21

Para resolver isso, vamos criar um buffered channel antes do loop:

// o tipo não importa muito, porque não estamos interessados no valor enviado
// nesse caso vou limitar para 50 goroutines fazendo requisições
limitter := make(chan bool, 50)

Toda vez antes de criar uma goroutine vamos adicionar um valor ao buffer:

for {
    limitter <- true

    go func() {
        ...
    }()
}

Toda vez que a goroutine finalizar, vamos tirar um valor do buffer:

for {
    limitter <- true

    go func() {
        ...
        <-limitter
    }()
}

O resultado vai ser:

package main

import (
    "fmt"
    "net/http"
)

func main() {
    finished := make(chan bool, 50)
    for {
        finished <- true

        go func() {
            client := http.Client{}

            resp, _ := client.Get("https://www.google.com")
            resp.Body.Close()

            fmt.Println(resp.Status)
            <-finished
        }()
    }
}

Golang: Desmistificando channels - Range e close

Igor Melo — Sat, 01 Oct 2022 21:21:30 +0000

Usando range e close

Se você tiver um canal, você pode receber mensagens usando um for range, parecido com percorrer um array ou slice.

Só que a diferença é que um for range em um canal vai receber valores até o canal ser fechado. Se o canal nunca for fechado, o loop vai ficar bloqueado.

ch := make(chan struct{})

for val := range ch {
  // essa linha nunca é executada, porque val nunca é recebido
  doSomething()
}

Para fechar um canal é muito simples, porém deve ser feito com cuidado, porque se você fechar um canal e tentar enviar isso vai causar um panic.

Então tem duas regras básicas que você pode seguir para fechar um canal:

Você deve fechar na função que envia, porque só ela sabe quando pode fechar
Você deve garantir que está fechando depois de todas as goroutines terem terminado de enviar

Não tem problema tentar ler de um channel fechado em um range:

ch := make(chan int)
close(ch)

for val := range ch {
    // não vai entrar aqui porque não tem nada para ser lido e não vai
    // repetir porque o channel está fechado
}

Você pode seguramente fechar um channel depois de ter enviado todos os valores:

func process(values []int, results chan string) {

    // neste caso eu estou usando WaitGroup pra garantir que todas as
    // goroutines já escreveram no channel antes de poder fechá-lo
    wg := sync.WaitGroup{}
    wg.Add(len(values))

    // faço um processamento concorrente de values
    for _, val := range values {
        go func() {
            results <- val * val
        }()
    }

    wg.Wait()
    close(results)
}

Fazendo múltiplas goroutines esperarem por um sinal

Uma coisa que você pode querer fazer é notificar uma goroutine que ela pode começar a fazer algum tipo de processamento.
Isso é bem fácil... Basta usar um channel e enviar um valor. Quando ela receber é porque ela pode iniciar.

Exemplo:

func main() {
    // esse channel serve para saber se o nosso servidor está pronto ou não
    ready := make(chan bool)

    go func() {
        startHttpServer(3000)
        ready <- true
    }()

    // fazer coisas que não dependam do servidor rodando
    // ...

    // esperar o servidor iniciar
    <-ready

    // fazer uma requisição para o servidor, agora que podemos garantir que ele está rodando
    client.Get("http://localhost:3000/")
}

Isso até funciona se tivermos só uma goroutine esperando o servidor iniciar.

Mas e se quisermos ter várias esperando esse sinal, como resolver isso?
Enviar um valor ao channel para cada uma não é uma solução viável.

Para isso podemos fazer um truque esperto que é usar o close do channel.

Em vez de enviarmos um valor para o channel para notificar que o servidor iniciou, podemos simplesmente fechar o channel e todas as goroutines que estiverem bloqueadas tentando receber do channel vão ser desbloqueadas.

func main() {
    ready := make(chan bool)

    go func() {
        startHttpServer(3000)
        close(ready) // usando close em vez de enviar
    }()

    // esperar o servidor iniciar
    <-ready

    // fazer uma requisição para o servidor, agora que podemos garantir que ele está rodando
    client.Get("http://localhost:3000/")
}

Golang: Desmistificando channels - Exemplo concreto

Igor Melo — Sat, 01 Oct 2022 21:17:00 +0000

Exemplo concreto de uso de channels

Vamos supor que você tenha um slice de URLs de arquivos e queira baixar todos de forma simultânea.

Você pode começar implementando uma solução sequencial, e depois fazer isso concorrente com goroutines, e por último usar os channels para esperar cada download terminar e comunicar que eles finalizaram.

Fazendo os downloads de forma sequencial

Digamos que você tenha um slice com os arquivos que quer baixar:

urls := []string{
    "http://files.com/file1.png",
    "http://files.com/file2.png",
    "http://files.com/file3.png",
}

Para fazer o download deles, você pode criar uma função download que recebe a URL do arquivo e faz o download.

Para simular o download, vamos fazer uma função que espera um tempo aleatório entre 0 e 3 segundos.

func download(url string) {
    r := rand.Intn(4)
    time.Sleep(time.Duration(r) * time.Second)
}

Agora, vamos fazer o download de cada arquivo de forma sequencial:

for _, url := range urls {
    download(url)
    fmt.Println("concluído:", url)
}

O resultado vai ser esse:

concluído: http://files.com/file1.png
concluído: http://files.com/file2.png
concluído: http://files.com/file3.png

No pior cenário o programa vai levar 3 segundos por download, ou seja, um total de 9 segundos.

Se conseguirmos fazer isso de forma simultânea, o pior cenário vai levar 3 segundos no total.

Usando goroutines para fazer downloads concorrentes

Criamos um channel de string

finished := make(chan string)

Poderia ser de outro tipo, mas nesse caso vou mandar a URL do download que finalizou, por isso vou usar um chan string.

Iniciar o download numa nova goroutine

func download(url string) {
    ...
}

func main () {
    urls := []string{
        ...
    }

    finished := make(chan string)

    for _, url := range urls {
        go download(url)
    }
}

Isso não vai funcionar, porque a goroutine main vai finalizar primeiro e vai encerrar o programa.

Quando o download finalizar, vamos enviar para o channel a URL

func download(url string) {
    ...
}

func downloadAndNotify(url string, ch chan string) {
    download(url)

    // agora em vez de só baixar em outra goroutine, estamos
    // enviando a url do download finalizado para o channel
    ch <- url
}

func main () {
    ...

    for _, url := range urls {
        go downloadAndNotify(url, finished)
    }

    // obs.: o programa vai continuar encerrando antes de fazer os downloads
}

Recebemos os valores do channel

func main () {
    ...

    for _, url := range urls {
        go downloadAndNotify(url, finished)
    }

    // sabemos que o números de resultados vai ser igual ao 
    // tamanho de urls, então podemos fazer esse for para repetir len(urls) vezes
    for range urls {

        // recebemos um resultado do channel
        // lembre-se, esse receber vai bloquear até que alguma goroutine envie algo
        url := <-finished

        fmt.Println("concluído:", url)
    }

    // como o loop anterior repete 3x, todos os resultados das 3 goroutines
    // são lidos, e a main finaliza quando todos os downloads terminam
}

Resultado:

concluído: http://files.com/file2.png
concluído: http://files.com/file1.png
concluído: http://files.com/file3.png

Podemos também usar uma função anônima no lugar do downloadAndNotify, e o código completo ficaria assim:

package main

import (
    "fmt"
    "math/rand"
    "time"
)

func download(url string) {
    r := rand.Intn(4)
    time.Sleep(time.Duration(r) * time.Second)
}

func main() {
    urls := []string{
        "http://files.com/file1.png",
        "http://files.com/file2.png",
        "http://files.com/file3.png",
    }

    finished := make(chan string)

    for _, url := range urls {
        // isso é necessário agora porque estamos usando uma closure
        url := url

        go func() {
            download(url)
            finished <- url
        }()
    }

    for range urls {
        url := <-finished
        fmt.Println("concluído:", url)
    }
}

Golang: Desmistificando channels - Conceito e sintaxe

Igor Melo — Sat, 01 Oct 2022 21:14:37 +0000

Introdução

Resolvi fazer esse texto porque no meu primeiro contato com channels eu não entendi muito bem como funcionava, daí eu sempre fugia para o WaitGroup ou fazia alguma Mutex para usar goroutines, mesmo quando a melhor solução seria usar channels.

Fiz esse texto com o objetivo de deixar mais claro como usar channels e os problemas comuns que você vai encontrar ao usá-los de forma errada.

O que é e para que serve?

Channel, ou canal, é uma forma nativa do Go para comunicar e sincronizar goroutines.

O channel já é thread-safe por padrão, ou seja, enviar e receber são operações seguras de se usar com goroutines, então você não vai precisar se preocupar em criar mutexes nem nada do tipo.

Com channels você consegue facilmente fazer coisas como:

Coletar o resultado de várias goroutines fazendo requisições HTTP e ir mostrando na tela
Criar workers que processam no máximo 50 operações concorrentes
Fazer outras goroutines esperarem por um sinal que sua aplicação iniciou

Criando e usando channels

Para criar um channel, fazemos:

func main() {
    ch := make(chan int)
}

O channel pode ser basicamente de qualquer tipo: int, string, struct{} e outros.

Esse tipo é o tipo de dado que vai ser enviado e recebido pelo canal.
Detalhe que ao enviar uma informação para um channel, o que o outro lado recebe é uma cópia do dado.

Dessa forma você já evita vários problemas de data race, porque a goroutine que recebeu o dado pode ler e modificar sem o risco de afetar outra goroutine.
A exceção para isso é quando você cria channels de tipos que não copiam o dado inteiro, como ponteiros, maps e slices.

Exemplos de channels que vão copiar somente a referência, e não o dado completo:

ch := make(chan *int)
ch := make(chan []string)
ch := make(chan map[string]User)

Para enviar informações para um channel, fazemos:

func main() {
    ch := make(chan string)

    ch <- "Shakespeare"
}

Para receber do channel, fazemos:

func main() {
    ch := make(chan string)

    // recebendo de um channel e descartando valor
    <-ch

    // recebendo de um channel e guardando numa variável
    name := <-ch
}

Por que não funciona?

Se você rodar qualquer um dos códigos do exemplo anterior, vai acontecer isso:

fatal error: all goroutines are asleep - deadlock!

goroutine 1 [chan send]:
main.main()
        main.go:5 +0x31
exit status 2

Isso acontece porque os channels por padrão vão pausar a execução da goroutine que tentar enviar ou receber. Ou seja, a goroutine que tentar enviar vai esperar até que outra esteja pronta para receber, e da mesma forma a goroutine que tentar receber vai esperar até que outra envie.

No caso acima quando eu tento enviar para um channel, eu pauso a goroutine main para esperar que outra goroutine leia o que enviei, mas como não tem outra goroutine rodando, a main vai ficar esperando “para sempre” (deadlock).

O runtime do Go percebe que esse programa vai ficar parado indeterminadamente, porque todas as goroutines estão “dormindo” (all goroutines are asleep), então ele encerra o programa com um código de erro.

O mesmo acontece no segundo exemplo.

Também existem os buffered channels, que permitem a gente enviar para um canal uma quantidade X de dados antes que ele comece a bloquear a goroutine, mas vamos ver isso mais para frente.

Usando channels corretamente

Para corrigir o problema do deadlock anterior, vamos criar outra goroutine que lê do channel, enquanto a goroutine main vai enviar para o channel.

package main

import (
    "fmt"
)

func main() {
    ch := make(chan int)

    // obs. 1: 'go' vai fazer com que essa função seja executada numa 
    // nova goroutine, então ler do channel não vai bloquear a main

    go func() {
        // obs. 2: eu não preciso passar o ch como parâmetro da função
        // porque o ch está no da main escopo
        <-ch
    }()

    // a goroutine main vai esperar até que consiga enviar
    ch <- 12

    fmt.Println("Fim")
}

Se você está confuso com ch <- 12 e <-ch, você pode pensar que a seta aponta para onde o dado está fluindo.

// o dado está saindo do channel ch (receber) e sendo descartado
<-ch

// o dado está saindo do channel ch (receber) e sendo atribuído à variável x
x := <-ch

// o dado 12 está indo para o channel ch (enviar)
ch <- 12

Conclusão

Isso conclui a parte 1 dessa série, com o conceito básico de channels.
Na parte 2 vamos ver um exemplo mais realístico de onde e como seria utilizado channels.

DEV Community: Igor Melo

Go 1.22 e o novo router HTTP

Introdução

1. Como funciona o http.ServeMux

2. Entendendo o match com base no método HTTP

3. Utilizando variáveis de path

4. Utilizando matches exatos

Conclusão

Go: Criando um cache em memória com map, mutex e generics

1. Introdução

2. Por que não usar simplesmente um map?

3. O que são data races?

Regra geral sobre data races

Race detector

4. Cache com sync.Mutex

Criando um tipo para o Cache e utilizando uma mutex

5. Introduzindo a sync.RWMutex

Atualizando métodos para usar sync.RWMutex

6. Utilizando generics

Introduzindo a sintaxe de generics

Aplicando generics no tipo Cache

7. Comparações de performance

7 vantagens da linguagem Go

Antes de tudo

Introdução

1. Retrocompatibilidade

2. Compilação e portabilidade

3. Concorrência

4. Biblioteca padrão rica

5. Simplicidade

6. Ferramenta de profiling de performance nativa

7. Ferramenta de testes nativas

Go: Analisando performance com pprof

Introdução

Aplicação de exemplo

Fazendo o profiling

Analisando os dados de memória

Otimizando com base no profiling de memória

Analisando um profiling de CPU

E em aplicações que "não param"?

Conclusão

Git para leigos

Todo mundo já fez algo assim

O que é o Git

Instalando o Git

Windows

Linux

Mac

Seu primeiro projeto com Git

O comando git status

Gravando alterações no histórico

1. Fazer alteração

2. Preparar alteração

3. Registrar alteração

Vendo o histórico de commits e as alterações feitas

Exemplo mais concreto

1. Iniciando o projeto

2. Primeiro commit

3. Commit de nova funcionalidade

4. Revendo os commits feitos

Conclusão

Implementando um cat em C

Introdução

Exemplos de utilização do cat

Entendendo stdin, stdout e stderr

Redirecionando streams no terminal

Iniciando a implementação em C usando stdio.h

Validando usando o cat original

Implementando o cat com argumentos

Tratando arquivos que não podem ser lidos

Código completo feito com stdio.h

Dúvidas comuns

Ler/escrever byte por byte não prejudica a performance?

Conclusão

5 dicas simples para deixar seu site mais rápido

Introdução

1 - Use debounce e throttle

Debounce

Throttle

2 - Coloque só o crítico no head

1. Como funciona o `http.ServeMux`

2. Por que não usar simplesmente um `map`?

4. Cache com `sync.Mutex`

5. Introduzindo a `sync.RWMutex`

Atualizando métodos para usar `sync.RWMutex`

O comando `git status`

Exemplos de utilização do `cat`

Entendendo `stdin`, `stdout` e `stderr`

Iniciando a implementação em C usando `stdio.h`

Validando usando o `cat` original

Implementando o `cat` com argumentos

Código completo feito com `stdio.h`

2 - Coloque só o crítico no `head`

4.1 - `Cache-Control` e `max-age`

4.3 - Combinando `max-age` com `ETag`