Lei de Amdahl: fórmula, exemplos e limites

A lei de Amdahl (Amdahl’s law) diz que a aceleração obtida ao executar um trabalho em paralelo é limitada pela parte que não pode rodar em paralelo. Se uma fração p do trabalho se divide entre n processadores, servidores ou threads, a aceleração é S = 1 / ((1 − p) + p/n), e por mais que n cresça ela nunca passa de 1 / (1 − p). Com 95% do trabalho em paralelo, o teto é de 20 vezes, mesmo em mil máquinas.

Os números abaixo são aritmética, sem nenhum teste executado por trás. Os artigos citados foram conferidos em 1º de novembro de 2026.

O que a lei diz em termos simples?

Um trabalho não pode terminar mais rápido do que sua parte sequencial, então workers extras só encurtam o resto. Quando a parte paralela já é pequena perto da sequencial, mais workers quase não mudam o tempo total.

Pense em um trabalho de 10 segundos em que 1 segundo é sequencial (um lock, uma escrita única) e 9 segundos se dividem por igual, ou seja, p = 0,9. Oito workers o terminam em 1 + 9/8 = 2,125 segundos (4,71 vezes mais rápido); sessenta e quatro precisam de cerca de 1,14 segundo. Nada o leva abaixo de 1 segundo, então 10 é o teto.

De onde vem a lei?

Gene Amdahl apresentou o argumento em 1967, na AFIPS Spring Joint Computer Conference, em um artigo que defendia a abordagem de processador único.

Não lemos o texto completo de Validity of the single processor approach to achieving large scale computing capabilities. Mark Hill e Michael Marty o resumem em Amdahl’s Law in the Multicore Era (IEEE Computer, 2008): uma fração paralelizável sem limite e sem custo de escalonamento, o resto totalmente sequencial, e a aceleração descrita sem apresentar uma equação (“without presenting an equation”).

O que isso significa para testes de carga e de capacidade?

A vazão para de crescer no ritmo dos servidores, threads ou pods assim que um componente compartilhado atende parte de cada requisição uma de cada vez. Um teste de carga mostra isso como uma curva de vazão que se achata enquanto você continua adicionando capacidade.

O artigo de Neil Gunther de 2008, citado abaixo, escreve a mesma lei como N / (1 + σ(N − 1)), com σ como fração sequencial, e mede a escalabilidade como a vazão com N dividida pela vazão com 1. Em um sistema web, a parte sequencial é tudo por onde cada requisição precisa passar na sua vez: um lock ou uma linha que toda requisição atualiza, um único banco de dados primário que recebe todas as escritas, um único consumidor de fila ou uma API de terceiros com limite de taxa.

Como encontrar a parte sequencial em um teste de carga?

Rode o mesmo teste em vários níveis de carga e observe qual recurso satura enquanto a vazão se achata. O componente que está no limite quando a capacidade extra deixa de compensar é a parte sequencial, ou a fila na frente dela.

Sinais típicos: a vazão estaciona enquanto a camada de aplicação ainda tem CPU livre, as esperas crescem em um único ponto compartilhado (locks, conexões com o banco, profundidade da fila), e o tempo de resposta sobe no mesmo ritmo que os usuários, que é a lei de Little diante de um teto. Uma execução com carga constante não consegue mostrar isso, então suba a carga em degraus. A configuração Ramp Up Steps da LoadFocus adiciona usuários virtuais em lotes iguais. O painel Capacity (página em inglês) agrupa uma execução terminada por usuários virtuais ativos e, nos planos pagos, lista o p95, as requisições por segundo e a taxa de erro de cada degrau nas execuções com um só gerador de carga. Só indica um nível de capacidade quando a execução passou por pelo menos três degraus e o mais alto foi pelo menos o dobro do mais baixo. Ele não ajusta nenhum modelo de escalabilidade, então o ajuste mais abaixo fica com você.

O que é a lei de Gustafson?

É o contraponto: se o problema cresce junto com a máquina, a parte sequencial continua pequena e a aceleração cresce quase de forma linear. Amdahl fixa o trabalho; Gustafson fixa o tempo de execução.

A nota de John Gustafson de 1988, Reevaluating Amdahl’s law, relatou acelerações de 1016 a 1021 em um hipercubo de 1024 processadores em Sandia, para aplicações com parte sequencial de 0,4 a 0,8%, e argumentou que os usuários aumentam o problema até preencher o tempo de que dispõem. Com s’ como a parte sequencial medida na execução paralela, a aceleração escalada, uma fórmula que a nota atribui a E. Barsis, de Sandia, é N + (1 − N)s’.

Com s’ = 0,05 e 64 processadores, isso dá 60,85, contra 15,42 segundo Amdahl, porque os dois valores de 5% são medidos em máquinas diferentes. Em um sistema web, Gustafson se aplica quando cada servidor adicionado trabalha com sua própria parte dos dados; Amdahl se aplica quando cada usuário a mais continua tocando a mesma linha compartilhada.

O que a Universal Scalability Law acrescenta?

Um segundo termo de coerência, o custo de manter dados compartilhados consistentes entre workers, que cresce com o número de pares de workers. Com ele, a vazão pode chegar a um máximo e depois cair à medida que você adiciona capacidade.

O artigo de Gunther A General Theory of Computational Scalability Based on Rational Functions (arXiv, 2008) formula a Universal Scalability Law (USL) assim:

C(N) = N / (1 + σ(N - 1) + κN(N - 1))
peak at N* = sqrt((1 - σ) / κ)

σ é a contenção (serialização ou filas) e κ é a coerência (cópias inconsistentes dos dados); com κ = 0 sobra a fórmula de Amdahl. Entre os exemplos de Gunther para o pior caso está a atualização de registros em banco de dados, e ele chama de “retrograde”, ou seja, decrescente, a vazão além de N*. Com os valores de exemplo σ = 0,05 e κ = 0,001, o máximo fica perto de 31 workers: a vazão relativa é 9,03 com 32 e 7,82 com 64, onde o termo σ sozinho prevê 15,42.

Como ajustar a USL a uma série de testes de carga?

Meça a vazão em vários níveis de concorrência, divida cada valor pela vazão com um usuário e ajuste σ e κ por mínimos quadrados.

Rearranjada, a fórmula fica N / C − 1 = σ(N − 1) + κN(N − 1), que é linear em σ e κ. Os valores abaixo foram gerados a partir de σ = 0,05 e κ = 0,001; coloque em x suas próprias requisições por segundo de cada degrau:

import numpy as np

n = np.array([1, 2, 4, 8, 16, 32])          # virtual users
x = np.array([50, 95, 172, 284, 402, 452])  # req/s per level
c = x / x[0]                                # relative capacity
A = np.column_stack([n - 1, n * (n - 1)])
(s, k), *_ = np.linalg.lstsq(A, n / c - 1, rcond=None)
print(f"sigma={s:.3f} kappa={k:.4f}")
print(f"peak near {np.sqrt((1 - s) / k):.0f} users")

O script imprime sigma=0.050, kappa=0.0010 e um máximo perto de 31 usuários. Mude só a concorrência entre os degraus e inclua um degrau com um usuário, já que cada ponto é dividido por ele.

Onde esses modelos deixam de ser úteis?

Eles resumem uma curva de vazão em uma ou duas constantes, então não conseguem apontar o lock culpado nem acompanhar um sistema que muda sob carga. Use-os para ler uma curva medida e estendê-la um pouco: um ajuste com degraus muito abaixo do joelho diz pouco sobre o máximo.

• Parâmetros constantes. Um cache que esquenta, um autoscaler ou um pool que chega ao limite mudam σ e κ no meio do teste.
• Só vazão. O p95 e o p99 podem piorar antes: confira também a latência de cauda.
• O gerador de carga. Se ele saturar primeiro, a curva plana é dele.
• Testes fechados. Um número fixo de usuários virtuais mede um sistema fechado; usuários reais chegam no próprio ritmo.

FAQ

Você pode explicar a lei de Amdahl de forma simples? Um trabalho nunca é mais rápido do que a parte que não pode ser dividida. Se um décimo do trabalho precisa rodar em série, nenhum número de workers extras o deixa mais de dez vezes mais rápido, porque esse décimo continua levando o mesmo tempo.

O que é a lei de Gustafson? A lei de Gustafson diz que, quando o problema cresce com o número de processadores, a aceleração cresce quase de forma linear, como N + (1 − N)s’, em que s’ é a parte sequencial da execução paralela. John Gustafson a publicou em 1988 (atribuindo a fórmula a seu colega de Sandia E. Barsis) como contraponto à suposição de Amdahl de um problema de tamanho fixo.

Leituras relacionadas

• Lei de Little em teste de carga: dimensionar e conferir
• Vazão vs latência: como se relacionam sob carga
• Modelo de carga aberto vs fechado: qual usar e quando
• Latência de cauda: o que é e como medir
• Teoria das filas: o que é e por que a latência dispara

As afirmações técnicas deste artigo não foram revisadas de forma independente.