zanfranceschi / rinha-de-backend-2024-q1 Goto Github PK

https://github.com/zanfranceschi/rinha-de-backend-2024-q1/blob/main/load-test/user-files/simulations/rinhabackend/RinhaBackendCrebitosSimulation.scala#L201-L242

Além do comentário 5 consultas simultâneas ao extrato para verificar consistência com apenas 4 chamadas, em uma execução dos testes, obtive o seguinte erro:

> jmesPath(ultimas_transacoes[0].descricao).find.is(danada), but      1 (50.00%)
 actually found 2uVvpSZG39

porém, nos logs (filtrados pelo client_id afetado) obtive:

api01-1  | extrato	2	=>	{"saldo":{"total":0,"limite":80000,"data_extrato":"2024-03-05T19:42:35.139Z"},"ultimas_transacoes":[]}
api01-1  | transacoes	2	{"valor": 1, "tipo": "c", "descricao": "toma"}	=>	{"saldo":1,"limite":80000}
api02-1  | transacoes	2	{"valor": 1, "tipo": "d", "descricao": "devolve"}	=>	{"saldo":0,"limite":80000}
api01-1  | extrato	2	=>	{"saldo":{"total":0,"limite":80000,"data_extrato":"2024-03-05T19:42:35.150Z"},"ultimas_transacoes":[{"valor":1,"tipo":"d","descricao":"devolve","realizada_em":"2024-03-05T19:42:35.148Z"},{"valor":1,"tipo":"c","descricao":"toma","realizada_em":"2024-03-05T19:42:35.143Z"}]}

api01-1  | transacoes	2	{"valor": 1, "tipo": "c", "descricao": "danada"}	=>	{"saldo":1,"limite":80000}
api01-1  | extrato	2	=>	{"saldo":{"total":1,"limite":80000,"data_extrato":"2024-03-05T19:42:35.166Z"},"ultimas_transacoes":[{"valor":1,"tipo":"c","descricao":"danada","realizada_em":"2024-03-05T19:42:35.155Z"},{"valor":1,"tipo":"d","descricao":"devolve","realizada_em":"2024-03-05T19:42:35.148Z"},{"valor":1,"tipo":"c","descricao":"toma","realizada_em":"2024-03-05T19:42:35.143Z"}]}
api02-1  | extrato	2	=>	{"saldo":{"total":1,"limite":80000,"data_extrato":"2024-03-05T19:42:35.168Z"},"ultimas_transacoes":[{"valor":1,"tipo":"c","descricao":"danada","realizada_em":"2024-03-05T19:42:35.155Z"},{"valor":1,"tipo":"d","descricao":"devolve","realizada_em":"2024-03-05T19:42:35.148Z"},{"valor":1,"tipo":"c","descricao":"toma","realizada_em":"2024-03-05T19:42:35.143Z"}]}
api02-1  | extrato	2	=>	{"saldo":{"total":1,"limite":80000,"data_extrato":"2024-03-05T19:42:35.170Z"},"ultimas_transacoes":[{"valor":1,"tipo":"c","descricao":"danada","realizada_em":"2024-03-05T19:42:35.155Z"},{"valor":1,"tipo":"d","descricao":"devolve","realizada_em":"2024-03-05T19:42:35.148Z"},{"valor":1,"tipo":"c","descricao":"toma","realizada_em":"2024-03-05T19:42:35.143Z"}]}
api01-1  | transacoes	2	{"valor": 5294, "tipo": "c", "descricao": "2uVvpSZG39"}	=>	{"saldo":5295,"limite":80000}
api01-1  | extrato	2	=>	{"saldo":{"total":5295,"limite":80000,"data_extrato":"2024-03-05T19:42:36.172Z"},"ultimas_transacoes":[{"valor":5294,"tipo":"c","descricao":"2uVvpSZG39","realizada_em":"2024-03-05T19:42:36.144Z"},{"valor":1,"tipo":"c","descricao":"danada","realizada_em":"2024-03-05T19:42:35.155Z"},{"valor":1,"tipo":"d","descricao":"devolve","realizada_em":"2024-03-05T19:42:35.148Z"},{"valor":1,"tipo":"c","descricao":"toma","realizada_em":"2024-03-05T19:42:35.143Z"}]}
...

Aparentemente, esse "danada", do criteriosClientes, está ocorrendo paralelamente aos creditos/debitos...

Poderia esclarecer:

Exceto bancos de dados que têm como principal característica o armazenamento de dados em memória

Se um banco de dados armazena tudo em memoria e possui um thead pra descarregar a memória em disco de forma asincrona, seria desqualificado?

Redis tem features pra persistir dados em disco assim como outros DBs tem features pra cachear rows e outros elementos do banco de dados em memória.

É permitido usar o load balancer incluso do Docker Compose? Visto que o algoritmo dele é Round Robin. Ou é necessário ter um componente à parte?

Olá pessoal!
Sabem me dizer se está faltando algo para eu configurar no Gatling / JDK para esses erros?
Estou executando em windows.

---- Errors --------------------------------------------------------------------

j.n.BindException: Address already in use: getsockopt 9089 (42.96%)
j.n.ConnectException: Connection refused: getsockopt 8077 (38.18%)
j.i.IOException: Premature close 3990 (18.86%)
================================================================================

Obrigado

Notei no exemplo que a participante metafórica Ana adicionou em participantes um diretório ana-01..

Pessoas que quiserem realizar mais de uma versão do desafio podem mandar com esse padrão de nomes? Ex.: ana-01 para um app em PHP e ana-02 para um app em Rust

Opa @zanfranceschi, tudo joia meu caro? Dei uma olhada nos status de execução da minha submissão, vi que está marcado como falha, mas não consegui identificar nenhum erro no docker-compose. Consegue me dar uma força se é algo nos logs que não estou vendo ou o problema está aqui entre a cadeira e o teclado? rs

Tive um pouquinho de dificuldade também pra executar na minha máquina. Pra eu conseguir bater com o nginx local aqui, tive que usar um host network diferente do docker-compose que dei submissão... não sei se é isso afetando, mas como não consegui ver nada nos logs de erro 500, não identifiquei 100%

Logs: https://github.com/zanfranceschi/rinha-de-backend-2024-q1/blob/main/participantes/gabrielfmagalhaes/docker-compose.logs

Olá, não sei se mais alguém está com esse problema, mas essa validação é a única que está dando problema...

Meu projeto está aqui: https://github.com/jcrjuliano/rinha-q1

Já fiz e refiz a lógica várias vezes, inicialmente eu havia feito o código usando design patterns (strategy e factory) para ficar organizado, porém, removi tudo e joguei no controlador direto para diminuir a quantida de beans, mas mesmo assim esse erro não se resolve.

E o estranho que é meio intermitente, e as vezes há uma outra validação que também da o erro:

Obrigado.

É permitido usar outros registros de container que hospedem a imagem públicamente? Como por exemplo, Github ou AWS ECR?

Pedido nesse PR.

Fala pessoal!
Sabem me dizer se está faltando algo para eu configurar no Gatling / JDK para esses erros?

---- Errors --------------------------------------------------------------------

Request timeout to localhost/127.0.0.1:9999 after 60000 ms 8548 (61,47%)
j.i.IOException: Premature close 5345 (38,44%)
status.find.in(422), but actually found 400 5 ( 0,04%)

================================================================================

Estava achando estranho todos os testes do meu projeto estarem com muitos erros. Então rodei o projeto do Zan, zan-dotnet, e obtive esses resultados (bem diferente do que está aqui no repo)

---- Global Information --------------------------------------------------------

request count 61478 (OK=47573 KO=13905 )
min response time 1 (OK=1 KO=1 )
max response time 60089 (OK=59989 KO=60089 )
mean response time 15843 (OK=6946 KO=46280 )
std deviation 20476 (OK=9767 KO=18168 )
response time 50th percentile 5495 (OK=4393 KO=60000 )
response time 75th percentile 18146 (OK=6591 KO=60000 )
response time 95th percentile 60000 (OK=29664 KO=60001 )
response time 99th percentile 60001 (OK=56995 KO=60003 )
mean requests/sec 206.997 (OK=160.178 KO=46.818)

---- Response Time Distribution ------------------------------------------------

t < 800 ms 6376 ( 10%)
800 ms <= t < 1200 ms 586 ( 1%)
t >= 1200 ms 40611 ( 66%)
failed 13905 ( 23%)

Specs da minha máquina:

• Ubuntu 22.04.4 LTS
• Intel Core i5-6300U
• 16 GB Ram
• Docker versão 25.0.3
• Docker compose versão 2.24.6

Log:

From https://github.com/zanfranceschi/rinha-de-backend-2024-q1
 * branch            main       -> FETCH_HEAD
   cbfaccd..0cf9aa9  main       -> upstream/main
error: invalid path 'quantos-testes-faltam?.sh'
Updating 3c1d0e3..0cf9aa9

Sugiro retirar a ?.

Aqui a validação testa se a inserção mantém a ordem mas ali no teste ele valida inversamente, falhando essas requests de validação:

Está errado ou tem algo que eu não estou pegando?

Achei essas duas datas limite no README.

"A data limite para enviar sua submissão é 2024-03-10T23:59:59-03:00."
e
"A data/hora limite para fazer pull requests para sua submissão é até 2024-03-29T23:59:59.000-03:00"

Qual devemos considerar?

Att,

Vie que o projeto precisa ser composto de um Load Balance, Banco de Dados e dois serviços http

Tem problema se eu escrever uma única aplicação que faça tudo?

Um mini buffer pro banco de dados com armazenamento em fs
Um serviço http que recebe o trafego e o redireciona para duas threads usando semaforo?

Vai saber... se performance for realmente o fator determinante 🙈

O caminho para o artefato declarado no diretório participantes/nome deve ser o mesmo declarado no projeto participante?

Não ficou claro para mim se ele serviria apenas como um verificador do que foi submetido e o que está no repo ou se o mesmo path seria o utilizado.

Existe ou vai existir algum teste para avaliar a integridade do extrato durante transações?
Ex: DURANTE o registro das 10 primeiras transações, ao consultar o extrato em paralelo, a soma das transações deve bater com o saldo total do próprio extrato.

Aproveito para sugerir que aceite o HTTP STATUS 400 quando a request estiver fora do padrão esperado (valor como float, length(descricao) > 10, etc)

O teste de validação abaixo deveria retornar um status 422.

.exec(
  http("validações")
    .post("/clientes/1/transacoes")
    .header("content-type", "application/json")
    .body(StringBody(s"""{"valor": 1, "tipo": "c", "descricao": "123456789 e mais um pouco"}"""))
    .check(status.in(422))
)

Porém, ao testar localmente, ele retorna sempre um status 200.Olhando o corpo da requisição não consigo ver nada de errado na requisição. O que pode ser?

O load balancer precisa necessariamente usar uma estratégia round-robin ou alguma outra estratégia (exemplo aleatória, decidida pelo kernel) é permitida?

É permitido ter o banco de dados rodando dentro dos containers de api e gravando os dados em um volume único (diretório externo mapeado) compartilhado pelos dois containers?

@zanfranceschi et al., parabéns pela iniciativa. O README do repositório está muito bem redigido. Fiquei com apenas uma dúvida aqui: usar SQLite, gravando os dados em arquivo, vai valer?

Há casos em que o campo descrição está sendo enviado com mais de 10 caracteres ou vazio. Peguei estes dois logo no começo do teste.

e

e

A especificação no README diz que o campo é obrigatório, e que deve ter entre 1 e dez caracteres:

Seria bom esclarecer e corrigir, afinal o campo é mesmo obrigatório? Tem mesmo esse limite de dez caracteres?

Percebi que o mesmo está acontecendo para o valor. O README diz que deve ser um inteiro:

Mas nos testes vemos um decimal:

Olá, pessoal!

Gostaria de tirar uma dúvida a respeito da coluna p75 do teste

https://github.com/zanfranceschi/rinha-de-backend-2024-q1/blob/main/STATUS-TESTES.md

O meu projeto ficou com um p75 muito alto, o mais alto entre todos os outros projetos
Gostaria de entender como esse número é gerado e se ter esse número muito alto é ruim

Agradeço desde já!

Entendi de acordo com o readme que a escolha do load balancer é aberto, desde que tenha round robin para as 2 instâncias da API. Queria saber se posso(ou não) construir um próprio load balancer pras instâncias da api, como uma imagem própria.

Nas seguintes linhas:

O teste criteriosClientes acontece em paralelo com criterioClienteNaoEcontrado.

Se o resultado de criterioClienteNaoEcontrado retornar antes da finalização de criteriosClientes, o teste de perfomance irá inicializar, causando falsos negativos no teste criteriosClientes, pois quando se faz o request do extrato, requisições do teste perfomance já podem ter sido iniciadas.

A solução seria adicionar um andThen para que o test de perfomance se inicie apenas após o teste, criteriosClientes.

).andThen(
  criteriosClientes.inject(
    atOnceUsers(saldosIniciaisClientes.length)
  ).andThen( // AQUI!
  criterioClienteNaoEcontrado.inject(
    atOnceUsers(1)
  ).andThen(
    debitos.inject(
      rampUsersPerSec(1).to(220).during(2.minutes),
      constantUsersPerSec(220).during(2.minutes)
    ),

Podem confirmar se eu entendi certo? Não tenho experiência com Gatling :(

Oi @zanfranceschi,

Acha que faz sentido adicionar uma validação da arquitetura minima no script executar-teste-local ?
Tinha pensado em algo bem simples, tipo validar mínimo de containers:

num_containers=$(docker ps -q | wc -l)
if [ "$num_containers" -ge 4 ]; then
    .... ok é no mínimo 4
else
    ... para o teste
fi

E talvez fazer algo com docker stats --no-stream --format ... para pegar a memória total.

A ideia é tentar ajudar/alertar quem tá fazendo errado por engano.
Se fizer sentido, posso tentar abrir um PR.

Até mais!

Atualmente, estou trabalhando em outro projeto para a rinha, utilizando o Spring Webflux. No entanto, tenho enfrentado um problema recorrente ao executá-lo no meu sistema: após aproximadamente 3000 requisições, ele apresenta o erro mencionado no título desta issue. Esse mesmo problemas acontece em alguns dos outros projetos baseados em Webflux que encontrei por aqui e executei na minha maquina.

Já tentei resolver o problema aumentando o limite NOFILE do Linux, tanto utilizando o comando prlimit quanto adicionando algumas configurações ao arquivo /etc/sysctl.conf. E mesmo se eu alterar o arquivo nginx.conf colocando um worker_connections alto, em algum momento esse problema ataca novamente.

Alguém poderia sugerir possíveis soluções para esse problema?

No documento o primeiro paragrafo de arquitetura cita o texto:

Um banco de dados relacional ou não relacional (exceto bancos de dados que têm como principal caracterísitca o armazenamento de dados em memória, tal como Redis, por exemplo).

E outra parte do texto tem:

Use o bom senso e boa fé, não adicione um banco relacional e um Redis, por exemplo, e use apenas o Redis como armazenamento – afinal, a Rinha é apenas uma brincadeira que fomenta o aprendizado e não a competição desleal.

Pode ou não usar o redis como cache ou algo do tipo?

Nas validações de quantidade de caracteres, podemos assumir que todas as strings serão ascii (sem caracteres especiais)?

Usar Unix Sockets para inter conectar o Load Balancer, banco de dados, os 2 clientes, disponibilizando apenas a port TCP 9999 no container esta de acordo com as regras e do bom senso da rinha?

https://stackoverflow.com/questions/1235958/ipc-performance-named-pipe-vs-socket

Uma das validações, é enviado o valor de 1.0 esperando o resultado 422. No js, 1.0 e 1 são funcionalmente identicos, seria possivel alterar o valor do teste para algum float "real", como 1.2?

I'm not closely following the event, but one detail that even the most experienced Go developers often forget in containerized environments is to correctly set the GOMAXPROCS, as mentioned in the article below. In certain situations, it can harm performance.

https://www.ardanlabs.com/blog/2024/02/kubernetes-cpu-limits-go.html

Fala meu mano @zanfranceschi, fui olhar os status de execução da minha submissão, mas não encontrei os erros no docker-compose.logs, talvez porque o arquivo deve estar limitado em 500 linhas talvez, ou eu que não vi algo?

Apropósito, grande iniciativa, muito show a ideia da rinha :)

eu e um colega estamos estudando rust, e nos deparamos com essa rinha, achamos a ideia bem legal, e seria nossa primeira vez fazendo algo do tipo na linguagem. Queria confirmar se poderiamos fazer em dupla, visto que em nenhum momento ficou claro sobre!

Não temos experiencia nenhum com a linguagem visto que ambos trabalhamos com node. Mas achamos que esse projeto seria uma ótima "desculpa" para focarmos mais nesse estudo que vem sendo negligenciado a tempo :)

Olá galera!

Rodei diversas vezes minha submissão localmente e o resultado foi consideravelmente melhor do que o resultado em STATUS-TESTES.

Queria uma ajuda para saber se eu estou executando o teste de maneira errado ou se tem relação com a arquitetura da máquina X a imagem gerada.

Segue o link para a submissão: https://github.com/zanfranceschi/rinha-de-backend-2024-q1/tree/main/participantes/vitor_weirich_java

Agradeço qualquer apoio :)

Resultados rodando localmente:

Olá, tenho limitados conhecimentos sobre o nginx, mas parece que está ocorrendo um erro no qual ele não consegue encontrar as APIs. É aquela situação clássica de "Na minha máquina funciona", e estou tendo dificuldades em reproduzir o erro mencionado no log. Alguém teria alguma sugestão para resolver este problema?

Os arquivos são esses:

• docker-compose.logs
• docker-compose.yml
• nginx.conf
• Dockerfile

Eu estava esperando encontrar uma lista enorme de perguntas aqui e discussões sobre soluções, vcs trocam ideia soh pelo X? Eu estou quebrando alguma regra que eu não vi postando aqui?

Problema

Assim que a api inicia os testes, ela é derrubada, rodei localmente várias vezes e não consigo identificar qual é o problema, pois em todas as execuções os testes passam com sucesso.

Em cada teste local, eu tento limpar todo o lixo do Docker rodando o comando abaixo

docker stop $(docker ps -aq) && docker rm $(docker ps -aq) && docker rmi $(docker images -q) && docker volume rm $(docker volume ls -q) && docker compose up

• Logs da execução
• Repositório

O que já tentei

• Retirar commits assíncronos e outras bruxarias do Postgres
• Diminuir o pool de conexões do ngnix
• Aumentar a memória das apis

O que observei

Vi que a aplicação está consumindo toda a memória disponível, mas não consigo encontrar onde existem vazamentos de memória ou bugs.

Se alguém passou por isso ou queira ajudar, agradeço demais!

Fala, pessoal. Estou abrindo essa issue para reportar um problema que identifiquei. Por algum motivo uma API problemática (com Race Condition) está conseguindo passar em todos os casos do teste. A minha suspeita é que como estamos saindo com as requests com ID dos clientes randômicos, não estamos contemplando os casos de N requests paralelas de débito/crédito para o mesmo usuário.

Eu rodei no meu local um projeto de um participante que suspeitei da race condition, e fiz um script (link aqui) para testar a minha suspeita (caso queira o link do repositório participante que está com a race condition, só mandar dm).

O script vai sair com 100 requisições paralelas e cada requisição vai tentar debitar 1000, no final da execução esperamos que o saldo do cliente (id: 1) esteja -100000. Porém, vejam o resultado:

{
  '200': 100,
  status_200: [
    { limite: 100000, saldo: -1000 },
    { limite: 100000, saldo: -3000 },
    { limite: 100000, saldo: -1000 },
    { limite: 100000, saldo: -1000 },
    { limite: 100000, saldo: -2000 },
    { limite: 100000, saldo: -4000 },
    { limite: 100000, saldo: -2000 },
    { limite: 100000, saldo: -2000 },
    { limite: 100000, saldo: -3000 },
    { limite: 100000, saldo: -5000 },
    { limite: 100000, saldo: -4000 },
    { limite: 100000, saldo: -3000 },
    { limite: 100000, saldo: -3000 },
    { limite: 100000, saldo: -3000 },
    { limite: 100000, saldo: -3000 },
    { limite: 100000, saldo: -4000 },
    { limite: 100000, saldo: -2000 },
    { limite: 100000, saldo: -3000 },
    { limite: 100000, saldo: -4000 },
    { limite: 100000, saldo: -8000 },
    { limite: 100000, saldo: -4000 },
    { limite: 100000, saldo: -6000 },
    { limite: 100000, saldo: -4000 },
    { limite: 100000, saldo: -5000 },
    { limite: 100000, saldo: -5000 },
    { limite: 100000, saldo: -4000 },
    { limite: 100000, saldo: -5000 },
    { limite: 100000, saldo: -5000 },
    { limite: 100000, saldo: -7000 },
    { limite: 100000, saldo: -6000 },
    { limite: 100000, saldo: -6000 },
    { limite: 100000, saldo: -6000 },
    { limite: 100000, saldo: -7000 },
    { limite: 100000, saldo: -6000 },
    { limite: 100000, saldo: -8000 },
    { limite: 100000, saldo: -7000 },
    { limite: 100000, saldo: -7000 },
    { limite: 100000, saldo: -8000 },
    { limite: 100000, saldo: -7000 },
    { limite: 100000, saldo: -7000 },
    { limite: 100000, saldo: -9000 },
    { limite: 100000, saldo: -8000 },
    { limite: 100000, saldo: -8000 },
    { limite: 100000, saldo: -8000 },
    { limite: 100000, saldo: -8000 },
    { limite: 100000, saldo: -10000 },
    { limite: 100000, saldo: -9000 },
    { limite: 100000, saldo: -9000 },
    { limite: 100000, saldo: -9000 },
    { limite: 100000, saldo: -9000 },
    { limite: 100000, saldo: -10000 },
    { limite: 100000, saldo: -10000 },
    { limite: 100000, saldo: -11000 },
    { limite: 100000, saldo: -10000 },
    { limite: 100000, saldo: -10000 },
    { limite: 100000, saldo: -11000 },
    { limite: 100000, saldo: -10000 },
    { limite: 100000, saldo: -11000 },
    { limite: 100000, saldo: -12000 },
    { limite: 100000, saldo: -12000 },
    { limite: 100000, saldo: -12000 },
    { limite: 100000, saldo: -11000 },
    { limite: 100000, saldo: -12000 },
    { limite: 100000, saldo: -15000 },
    { limite: 100000, saldo: -12000 },
    { limite: 100000, saldo: -13000 },
    { limite: 100000, saldo: -13000 },
    { limite: 100000, saldo: -13000 },
    { limite: 100000, saldo: -13000 },
    { limite: 100000, saldo: -14000 },
    { limite: 100000, saldo: -14000 },
    { limite: 100000, saldo: -13000 },
    { limite: 100000, saldo: -14000 },
    { limite: 100000, saldo: -14000 },
    { limite: 100000, saldo: -15000 },
    { limite: 100000, saldo: -14000 },
    { limite: 100000, saldo: -15000 },
    { limite: 100000, saldo: -15000 },
    { limite: 100000, saldo: -14000 },
    { limite: 100000, saldo: -15000 },
    { limite: 100000, saldo: -16000 },
    { limite: 100000, saldo: -15000 },
    { limite: 100000, saldo: -16000 },
    { limite: 100000, saldo: -16000 },
    { limite: 100000, saldo: -18000 },
    { limite: 100000, saldo: -17000 },
    { limite: 100000, saldo: -17000 },
    { limite: 100000, saldo: -17000 },
    { limite: 100000, saldo: -16000 },
    { limite: 100000, saldo: -17000 },
    { limite: 100000, saldo: -15000 },
    { limite: 100000, saldo: -19000 },
    { limite: 100000, saldo: -18000 },
    { limite: 100000, saldo: -18000 },
    { limite: 100000, saldo: -18000 },
    { limite: 100000, saldo: -18000 },
    { limite: 100000, saldo: -18000 },
    { limite: 100000, saldo: -17000 },
    { limite: 100000, saldo: -19000 },
    { limite: 100000, saldo: -17000 }
  ]
}

Reparem que a última requisição deixou o saldo do cliente como -17000. Ou seja, race condition confirmado.

Após rodar esse script, eu rodei os testes de carga para certificar que essa API seria travada, mas acabou não pegando, como vocês podem ver aqui:

Estou abrindo um Pull Request para resolver esse problema.

minha dúvida é basicamente se o load balancer é realmente um componente obrigatório já que o docker compose permite a configuração de réplicas

Nos resultados dos testes parciais da rinha, alguem pode me explicar o que é aquele dado p75 geral, como funciona aquele numero?

Os testes serão rodados com docker compose ou docker-compose?

Ótimo vc ter mencionado o $ lscpu, que mostra que a máquina onde os testes vão rodar em uma arch x86_64!

Algumas pessoas podem ter arquiteturas locais diferentes, tipo ARM (caso de quem usa Mac M1, ou quem, por algum motivo, roda num Raspberry PI).

Para estas pessoas (eu incluso), será preciso fazer o build da imagem docker cross-arquitetura. Um simples docker build vai funcionar, mas vai falhar no seu servidor na hora de rodar os testes, na hora de dar o docker run.

Pra compilar de tal forma que funcione em um x86_64, é necessário rodar o docker build da seguinte forma:

$ docker buildx build --platform linux/amd64

Por exemplo: $ docker buildx build --platform linux/amd64 -t ana/minha-api-matadora:latest .

Fica aqui a sugestão e deixo ao seu cargo decidir. Se preferir, posso abrir um PR adicionando isso ao readme.

Aparentemente foi aceito um PR que mudou os arquivos principais da rinha ao invés de adicionar um novo participante.

Queria entender porque meu arquivo participantes/asfernandes-cpp-haproxy-mongoose-firebird/config/haproxy.cfg foi apagado nesse commit: 14589b2

Olá, estou testando minha API e estou tendo o único problema de jmesPath(saldo.total).find.is(0), but actually found -25 dei uma olhada no script de testes e reparei isso aqui.

validacaoTransacoesConcorrentes("d").inject(
      atOnceUsers(validacaConcorrentesNumRequests)
    ).andThen(
      validacaoTransacoesConcorrentesSaldo(validacaConcorrentesNumRequests * -1).inject(
        atOnceUsers(1)
      )
    ).andThen(
      validacaoTransacoesConcorrentes("c").inject(
        atOnceUsers(validacaConcorrentesNumRequests)
      ).andThen(
        validacaoTransacoesConcorrentesSaldo(0).inject(
          atOnceUsers(1)
        )
      )
    )

Sendo que essas validações são sempre feitas no cliente id 1 de acordo com:

val validacaConcorrentesNumRequests = 25
  val validacaoTransacoesConcorrentes = (tipo: String) =>
    scenario(s"validação concorrência transações - ${tipo}")
    .exec(
      http("validações")
      .post(s"/clientes/1/transacoes")
          .header("content-type", "application/json")
          .body(StringBody(s"""{"valor": 1, "tipo": "${tipo}", "descricao": "validacao"}"""))
          .check(status.is(200))
    )
  
val validacaoTransacoesConcorrentesSaldo = (saldoEsperado: Int) =>
    scenario(s"validação concorrência saldo - ${saldoEsperado}")
    .exec(
      http("validações")
      .get(s"/clientes/1/extrato")
      .check(
        jmesPath("saldo.total").ofType[Int].is(saldoEsperado)
      )
    )

Logo, se eu entendi direito como é pra o crédito e débito funcionar na rinha, esse script faz com que o saldo do cliente 1 fique em -25 através das transações de débito e passando na primeira validação, porém quando é realizada a segunda validação utilizando crédito, apesar de o saldo não ser afetado pelas transações de crédito, o cliente 1 continua com -25 de saldo do teste anterior, falhando a verificação de estar com 0 de saldo no segundo teste.
A ordem não deveria ser ao contrário, crédito primeiro e débito depois? Ou eu entendi o crédito e débito errado?

Olá, ao submeter o projeto para teste a criação do container falha com o seguinte erro host not found in upstream "api01:3000", porém ao rodar o projeto localmente consigo subir o container normalmente.

• Realizei o build da imagem como manda o README, com docker buildx build --platform linux/amd64
• O nginx depende do health das apis para subir

docker-compose.logs docker-compose.yml nginx.conf

Conseguem me ajudar a entender o que acontece, por favor?

Em conversa com o nobre amigo @rochajg sobre a possibilidade de utilizaçao de um redis ou outra ferramenta tipo etcd só pra fazer lock distribuido, e usar um postgres ou um sqlite pra armazenar os dados.. isso foge a regra do desafio ?

@zanfranceschi

O teste só funciona com os limites iniciais e nenhuma transação, então eu posso considerar que o banco de dados está sempre vazio quando a aplicação inicia?

Quando a aplicação inicia ela precisa excluir as transações existentes?

Tem gente colocando o banco de dados em tmpfs.

Isso é válido?