DEV Community: Matheus

Golang: Importância de planejar como exibir logs em aplicações de uso intenso

Matheus — Thu, 10 Oct 2024 14:47:40 +0000

Na maioria das vezes não gastamos o tempo necessário para planejar corretamente os logs das nossas aplicações, que posteriormente nos causa um retrabalho, muitas vezes desnecessário.

O uso bem planejado e aplicado de logs pode, além de melhorar uma análise futura sobre algum problema, impactar de forma significativa o desempenho da aplicação, principalmente para processos intensos.

Pensando em exemplificar e demonstrar um pouco desse impacto, seguem dois exemplos com seu benchmark, respectivamente.

O primeiro de uma forma comum de "loggar" informações no código, mas pouco valor de informação, se torna apenas um dado:

benchmark_logs_test.go

Benchmark:

E o segundo com o log estruturado, apresentando somente no final os tempos de inicio, finalização e a mensagem.

benchmark_logs_enhancement_test.go

Benchmark:

Ambos exemplos, possuem um loop de cem mil de índices, que usando goroutines, incrementa uma variável.
Ao iniciar é capturado a hora atual, e ao finalizar, é impresso o tempo que levou.
Estou usando a biblioteca logrus de logs, pois tem inúmeras propriedade e funcionalidade interessantes, como o log estruturado.

Nitidamente pode ser perceber, a diferença que pode causar no desempenho das aplicações, um log não pensado corretamente.

Golang: Como a observabilidade e profiling revelaram um throttling quase indetectável

Matheus — Wed, 09 Oct 2024 15:22:20 +0000

Em um projeto pessoal com Go, que obtém informações de ativos financeiros da Bovespa.
O sistema faz uso intenso de concorrência e paralelismo com goroutines, atualizando as informações de ativos(junto com os cálculos do negócio) a cada 8 segundos.
Inicialmente, não aparecia nenhum erro ou warning, mas percebi que algumas goroutines estavam levando mais tempo do que outras para serem executadas.

Para ser mais específico, enquanto o tempo p99 estava em 0.03 ms, em alguns momentos, ele aumentava para 0.9 ms. Isso me levou a investigar mais a fundo o problema.

Descobri que estava usando uma pool de goroutines com semáforo, que foi criada com base na variável GOMAXPROCS.
No entanto, percebi que havia um problema com essa abordagem.

Quando utilizamos a variável GOMAXPROCS, ela não captura corretamente a quantidade de núcleos disponíveis no container. Se o container tiver menos núcleos disponíveis do que o total da VM, ele considera o total da VM. Por exemplo, minha VM possui 8 núcleos disponíveis, mas o container tinha apenas 4. Isso resultou na criação de 8 goroutines para serem executadas ao mesmo tempo, causando throttling.

Após muita pesquisa durante a madrugada, encontrei uma biblioteca desenvolvida pela Uber que ajusta automaticamente a variável GOMAXPROCS de forma mais eficiente, independentemente de estar em container ou não. Essa solução se mostrou extremamente estável e eficiente: automaxprocs

uber-go / automaxprocs

Automatically set GOMAXPROCS to match Linux container CPU quota.

automaxprocs

Automatically set GOMAXPROCS to match Linux container CPU quota.

Installation

go get -u go.uber.org/automaxprocs

Quick Start

import _ "go.uber.org/automaxprocs"

func main() {
  // Your application logic here.
}

Performance

Data measured from Uber's internal load balancer. We ran the load balancer with 200% CPU quota (i.e., 2 cores):

GOMAXPROCS	RPS	P50 (ms)	P99.9 (ms)
1	28,893.18	1.46	19.70
2 (equal to quota)	44,715.07	0.84	26.38
3	44,212.93	0.66	30.07
4	41,071.15	0.57	42.94
8	33,111.69	0.43	64.32
Default (24)	22,191.40	0.45	76.19

When GOMAXPROCS is increased above the CPU quota, we see P50 decrease slightly, but see significant increases to P99. We also see that the total RPS handled also decreases.

When GOMAXPROCS is higher than the CPU quota allocated, we also saw significant throttling:

$ cat /sys/fs/cgroup/cpu,cpuacct/system.slice/[...]/cpu.stat
nr_periods 42227334
nr_throttled 131923
throttled_time 88613212216618

Once GOMAXPROCS was reduced to match the CPU quota, we saw no CPU throttling.

…

View on GitHub

Após implementar o uso dessa biblioteca, o problema foi resolvido, e agora o tempo p99 se manteve em 0.02 ms constantemente. Essa experiência destacou a importância da observabilidade e do profiling em sistemas concorrentes.

A seguir um exemplo bem simples, mas que consegue demonstrar a diferença de desempenho.

Utilizando o pacote nativo de testes e benckmak do Go, criei dois arquivos:

benchmarking_with_enhancement_test.go:

package main

import (
    _ "go.uber.org/automaxprocs"
    "runtime"
    "sync"
    "testing"
)

// BenchmarkWithEnhancement Função com melhoria, para adicionar o indice do loop em um array de inteiro
func BenchmarkWithEnhancement(b *testing.B) {
    // Obtém o número de CPUs disponíveis
    numCPUs := runtime.NumCPU()
    // Define o máximo de CPUs para serem usadas pelo programa
    maxGoroutines := runtime.GOMAXPROCS(numCPUs)
    // Criação do semáforo
    semaphore := make(chan struct{}, maxGoroutines)

    var (
        // Espera para grupo de goroutines finalizar
        wg sync.WaitGroup
        // Propriade
        mu sync.Mutex
        // Lista para armazenar inteiros
        list []int
    )

    // Loop com mihão de indices
    for i := 0; i < 1000000; i++ {
        semaphore <- struct{}{}
        // Adiciona ao waitGroup que existe mais uma goroutine para ser executada
        wg.Add(1)

        // Atribui a função a uma nova goroutine
        go func(i int) {
            // Quando a função finalizar, informa o semáforo e finaliza um registro do waitGroup
            defer func() {
                <-semaphore
                wg.Done()
            }()
            // Faz o bloqueio do array para outra goroutine não sobreescrever
            mu.Lock()
            // Adiciona o indice, em mais uma posição no array
            list = append(list, i)
            // Desbloqueia o array
            mu.Unlock()
        }(i)
    }
}

benchmarking_without_enhancement_test.go:

package main

import (
    "runtime"
    "sync"
    "testing"
)

// BenchmarkWithoutEnhancement Função sem a melhoria, para adicionar o indice do loop em um array de inteiro
func BenchmarkWithoutEnhancement(b *testing.B) {
    // Obtém o número de CPUs disponíveis
    numCPUs := runtime.NumCPU()
    // Define o máximo de CPUs para serem usadas pelo programa
    maxGoroutines := runtime.GOMAXPROCS(numCPUs)
    // Criação do semáforo
    semaphore := make(chan struct{}, maxGoroutines)

    var (
        // Espera para grupo de goroutines finalizar
        wg sync.WaitGroup
        // Propriade
        mu sync.Mutex
        // Lista para armazenar inteiros
        list []int
    )

    // Loop com mihão de indices
    for i := 0; i < 1000000; i++ {
        semaphore <- struct{}{}
        // Adiciona ao waitGroup que existe mais uma goroutine para ser executada
        wg.Add(1)

        // Atribui a função a uma nova goroutine
        go func(i int) {
            // Quando a função finalizar, informa o semáforo e finaliza um registro do waitGroup
            defer func() {
                <-semaphore
                wg.Done()
            }()
            // Faz o bloqueio do array para outra goroutine não sobreescrever
            mu.Lock()
            // Adiciona o indice, em mais uma posição no array
            list = append(list, i)
            // Desbloqueia o array
            mu.Unlock()
        }(i)
    }
}

A diferença entra elas, é que uma esta com a importação de biblioteca da Uber.

Ao executar o benchmark passando que seriam usados 2 CPUs, o resultado foi:

ns/op: fornece uma média em nanosegundos de quanto tempo leva para executar uma operação específica.

Percebam, que o total disponível da minha CPU são 8 núcleos, e foi o que a propriedade runtime.NumCPU() retornou. Porém, como na execução do benchmark, defini que o uso seriam de apenas duas CPUs, a o arquivo que não utilizou a automaxprocs, definiu que o limite de execução por vez, seriam de 8 goroutines, enquanto o mais eficiente seriam 2, pois dessa maneira se usa menos alocação deixa mais eficiente a execução.

Então, fica nítido a importância de observabilidade e proffiling das nossas aplicações.

Padrão de design de componentes agnósticos

Matheus — Tue, 08 Oct 2024 14:56:25 +0000

Esse padrão visa criar componentes desacoplados de bibliotecas específicas, definindo uma camada de abstração que permite a
integração com diferentes frameworks ou bibliotecas de UI, como React, Vue, ou Angular, ou mesmo diferentes bibliotecas de UI dentro de um mesmo framework, como PrimeReact, Material-UI, etc.

Requisitos

Para aplicar este padrão, não é necessário definir todos os componentes de uma vez, o processo pode ser progressivo, sendo aplicado, conforme a necessidade de utilização de novos componentes.

Organização de pastas e arquivos

Por prefêrencia pessoal, costumo disponibilizar os componentes agnósticos, na camada de UI compartilhada para aplicação,
geralmente é a camada, onde ficam os types, interfaces, styles, layouts, e utils.

Uma forma de organização de pastas, aplicando os conceitos de camadas, pode ser como a sugerida abaixo:

── src
    └── shared
        └── common
            └── ui
                └── components
                    └── Button
                        ├── Button.interface.ts
                        ├── Button.tsx
                        └── PrimeReactButton.component.tsx

É uma forma de organizar os componentes de forma que fique explícito que são compartilhados para aplicação inteira.

Implementação

Explicação sobre cada arquivo e como serem utilizados.

Button.interface.ts - Este arquivo define a interface TypeScript para o componente Button.
Ele descreve os tipos das propriedades (props) que o componente Button aceita.
A interface ajuda a garantir que o uso do componente seja seguro e consistente,
facilitando a tipagem forte no TypeScript.

export interface ButtonPropsInterface {
    label: string;
    onClick: () => void;
    disabled?: boolean;
    type?: 'button' | 'submit' | 'reset';
}

Button.tsx - Este arquivo contém a implementação genérica do componente Button em React.
Ele representa um botão "agnóstico", e atua como um wrapper que incorpora a lógica do botão e delega a renderização a um
adaptador,
que neste caso é o PrimeReactButtonComponent.

import React from "react";
import { ButtonPropsInterface } from "@/shared/common/ui/components/Button/Button.interface";
import PrimeReactButtonComponent from "@/shared/common/ui/components/Button/PrimeReactButton.component";

const Button: React.FC<ButtonPropsInterface> = ({label, onClick, disabled, type = 'button'}) => {
    return (
        <PrimeReactButtonComponent type={type} onClick={onClick} disabled={disabled}>
            {label}
        </PrimeReactButtonComponent>
    );
};

export default Button;

PrimeReactButton.component.tsx - Este arquivo contém a implementação específica do componente Button utilizando a
biblioteca PrimeReact. Ele serve como um adaptador que adapta a interface genérica do botão para usar o componente específico do PrimeReact, mantendo a mesma interface definida no arquivo Button.interface.ts. Assim, ele traduz as propriedades genéricas para a implementação específica da biblioteca.

import { ButtonProps } from './Button.interface';
import { Button as PrimeButton } from 'primereact/button';

const PrimeReactButtonComponent: React.FC<ButtonProps> = ({label, onClick, disabled, type = 'button'}) => {
    return (
        <PrimeButton label={label} onClick={onClick} disabled={disabled} type={type}/>
    );
};

export default PrimeReactButtonComponent;

Utilização

Onde for utilizar, basta realizar a importação do componente agnóstico:

import Button from "@/shared/common/ui/components/Button/Button";

E realizar o uso normalmente, passando as propriedades obrigatórias e opcionais, caso desejado:

<Button
    label="Voltar"
    icon="pi pi-angle-left"
    severity="secondary"
    onClick={() => router.push("/home")}
/>

Troca de bibliotecas

Se for necessário um dia trocar a biblioteca, basta criar um adaptador que realize a implementação especifica da biblioteca,
e trocar na implementação genérica do componente pelo adaptador novo.